Programų testavimas buvo techniškai sudėtinga, laiko trunkanti veikla, planuota kelias dienas ar savaites iki programos išleidimo. Kūrėjų komandoms buvo suteikta laisvė koduoti iki vienuoliktos valandos, o testuotojai, kurie daug savo darbo atliko rankiniu būdu, neturėjo kito pasirinkimo, kaip susitvarkyti su jiems skirtu trupučiu laiko. Rezultatas buvo tas, kad daugeliui programų buvo atlikti neatitinkantys bandymai, o technologijų grupės buvo priverstos reaguoti į gamybos problemas ir defektus, kuriuos padidino galutiniai vartotojai ir programų stebėjimo sistemos.
Nenutrūkstamos integracijos praktikos, vienetų testavimo sistemos ir bandymų automatizavimo praktikos patvirtino šią paradigmą. Užuot atlikę kokybės užtikrinimą kūrimo proceso pabaigoje, daugelis testavimo metodų dabar pradedami ir visiškai vykdomi kodavimo, integravimo ir diegimo metu. „Devops“ ir „Agile“ komandos automatizuoja testavimo scenarijus, o CI / CD vamzdynai kviečiami atlikti bandymus per kodų integravimo ar pristatymo etapus. Bendras rezultatas yra tai, kad kūrėjai įspėjami, kai jų kodo pakeitimai sulaužo kūrimą ir gali nedelsdami imtis veiksmų, kad išspręstų nurodytą problemą.
Testavimo automatizavimas ir testavimo scenarijų integravimas į CI / CD vamzdynus yra žinomas kaip „kairės pusės“ testavimas. Tai reiškia, kad kūrimo etape galima atlikti daugiau kokybės užtikrinimo praktikos, kad problemos būtų išspręstos anksčiau išleidimo laiko juostoje. Testavimo automatizavimas yra vienas iš pasirengimo prioritetų judrioms ir išsivysčiusioms komandoms, kurios nori padidinti dislokavimo dažnį.
Pristatant naują funkcionalumą, sukonstruoti testo scenarijai patvirtina naujas galimybes. Tada šiuos bandymus galima automatizuoti ir įtraukti į kūrimo arba diegimo veiksmus. Užuot verčiant kokybės užtikrinimo inžinierius vykdyti regresijos testus išleidimo proceso pabaigoje, galite atlikti ir patvirtinti daugelį šių testų kaip kūrimo dalį. Šie bandymai pereina kairėn nuo leidimo proceso pabaigos į ankstesnes kūrimo ir kodavimo fazes.
„Shift“ kairėn testavimas leidžia judrioms komandoms atsiduoti kokybei
„Shift-left“ bandymai ne tik skatina efektyvumą ir gerina kokybę, bet ir sukuria reikšmingą kultūros pokyčius judrioje kūrimo procese.
Kai kurios kūrėjų komandos kokybės užtikrinimą ir testavimą laiko kliūtimi, kad jų kodas būtų pristatytas gamybai. Po sunkaus darbo patenkindami judrių produktų savininkus ir užpildydami kodą, kokybės užtikrinimo komandos draugai nustato klaidų, kurias reikia ištaisyti, sąrašą. Jei QA randa daug klaidų, tai gali turėti įtakos išleidimo laiko juostai jas pašalinti. Dar blogiau yra tada, kai reikšmingoms kodo skiltims reikia pertvarkyti, nes dėl trūkumų iškyla logikos, saugumo ar našumo problemų. Tokiu atveju kūrėjai ir kokybės užtikrinimo inžinieriai gali būti toje pačioje judrioje komandoje, tačiau neveikia kaip komanda.
„Shift-left“ testavimas leidžia judrioms komandoms perkelti kokybės atsakomybę visai kūrėjų ir testuotojų komandai. Kai bandymai vykdomi kaip CI / CD vamzdyno dalis, tai suteikia geresnę galimybę kūrėjams spręsti kokybės problemas tuo metu, kai jie dirba su atitinkamu kodu. CI / CD dujotiekis įspėja nesėkmingo kūrimo kūrėją ir daugumai savarankiškai organizuojančių kūrėjų komandų reikia nedelsiant išspręsti šias problemas.
„Shift-left“ testavimas taip pat suteikia kūrėjams ir kokybės užtikrinimo inžinieriams galimybes automatizuoti daugiau bandymų. Geriausia praktika yra tai, kad komandos nusprendžia, kas įgyvendina automatiką, atsižvelgiant į sukurtų funkcijų reikalingų bandymų tipus. Pavyzdžiui, kūrėjai dažnai yra atsakingi už vienetų ir API testų automatizavimą, tačiau kokybės užtikrinimo automatikos inžinieriai dažnai kuria galutinio vartotojo patirties ir operacijų testus, kurie imituoja kelių pakopų API iškvietimus kelioms tarnyboms.
Kada taikyti „kairės“ kairės pusės testavimą
„Shift“ kairėn bandymai geriausiai tinka atliekant vieneto lygio atominius bandymus, kurių vykdymo laikas yra trumpas. Labai svarbu, kad testai būtų automatizuoti CI / CD vamzdynuose ir būtų vykdomi, kai kūrėjai suaktyvina kūrimą, greitai vykdomi ir ne sulėtinami kūrimo procesai.
Sudėtingesni ir daug laiko reikalaujantys testai, tokie kaip galutinio vartotojo patirties testai, operacijų testavimas, statinio kodo analizė ir saugumo testavimas, dažnai veikia geriau už KI / CD vamzdynus ir kasdien ar dažniau. Šie testai vis dar teikia ankstyvą grįžtamąjį ryšį kūrėjams kokybės klausimais, tačiau jie yra automatizuoti už CI / CD ribų, kad būtų išvengta sulėtinimo ar kliūčių.
Thomas J. Sweetas, „GM Financial“ IT paslaugų viceprezidentas, pasidalijo su manimi savo asmeninėmis įžvalgomis apie „kairės“ kairės pusės testavimo strategijų ribas. Jis siūlo: „„ Shift “kairėn visada yra strategija, išskyrus tuos atvejus, kai atliekate trečiųjų šalių tiekėjų pristatymų integravimo bandymus, nes dažnai neturite prieigos prie jų šaltinio kodo. Net jei turite vidines programas su senomis monolitinėmis architektūromis, galite pradėti vykdydami pagrindines registracijos strategijas, kurioms reikalingas kodo peržiūra ir saugos nuskaitymas. Registracija turėtų būti atmesta, jei nuskaitymas apima esminius įspėjimus ir gedimus “.
Vienas iš galimų tolesnių bandymų su integracijos partneriais sprendimų yra paslaugų virtualizavimo diegimas. Šis metodas leidžia kūrimo komandoms imituoti tolesnės sistemos reakciją į skirtingus įnašus. Tai gerai veikia, kai pasrovio sistemos yra gerai apibrėžtos. „Micro Focus“, „Tricentis“ ir kitų įrankiai įgalina šią galimybę.
Robas Pocilukas, labai patyręs kokybės užtikrinimo vadybininkas, yra tvirtas judriojo vystymosi bandymų kairės pusės kairiųjų šalininkas. „Būdamas pasirengęs ir galėdamas išbandyti mažas kodo dalis, QA lieka lankstus ir nepertraukiamas sprinto progreso metu. Komandos vis tiek turėtų apsisaugoti, kad per daug nesinaudotų „Shift“ kairėn, nes galite prarasti paties kodo paskirtį “.
Taigi, net kai komandos visiškai taiko „kairės“ kairės pusės testavimą, yra rimtų priežasčių vis tiek suplanuoti testavimo langą visiško kodo versijoje, skirtoje išleisti. Tai užtikrina, kad visi automatiniai bandymai bus atlikti su galutiniu komponavimu, bet taip pat leidžia planuoti papildomus bandymus, kuriems reikalinga visiškai veikianti sistema.
Vienas iš šių testų yra UAT (vartotojų priėmimo testavimas), kai atrinkti galutiniai vartotojai ir dalyko ekspertai patvirtina ir teikia grįžtamąjį ryšį. Kai kuriuos UAT galima atlikti kūrimo metu, tačiau gali būti nelengva priversti žmones dažnai atlikti šį bandymą arba kai funkcijos nėra visiškai paruoštos.
Privalomos perėjimo į kairę testavimo strategijos
„Shift-left“ testavimas yra vis didesnė praktika, tačiau ji turi savo prielaidas ir išankstines investicijas. Reikalingi kai kurie esminiai gebėjimai ir praktika.
- Norint palaikyti vienu metu vykdomų versijų ir bandymų skaičių, reikalingi pakankami bandymų pajėgumai ir aplinka.
- Judrioms komandoms reikalingas produktų testavimo įrankių rinkinys, kuris lengvai integruojamas į CI / CD vamzdynus ir darbo planavimo įrankius, ir kuris gali patvirtinti funkcionalumą, kodo kokybę, saugumą ir našumą.
- Architektai, „infosec“ specialistai, kokybės užtikrinimo vadovai ir kiti vyresni organizacijos nariai turėtų nustatyti testavimo standartus ir paslaugų lygio tikslus, kurie yra numatytieji priėmimo kriterijai.
- Kai programoms reikia vartotojo įvesties, bandymų grupėms reikia pakankamai bandymų duomenų ir modelių, kad būtų galima patvirtinti pakankamai asmenybių, naudojimo atvejų ir įvesties modelių.
- Įsipareigodami sprintui ar anksčiau, „scrum“ komandos, įskaitant kokybės užtikrinimo testų automatikos inžinierius, turėtų nustatyti testavimo strategiją, kokias galimybes išbandyti, kokie bandymų tipai įgyvendinami, kokie automatizavimo procesai atnaujinami ir kas kuria testus.
- „Devops“ komandos turėtų matuoti KI / CD vamzdynų eigos trukmę ir pažymėti, kai automatizuoti bandymo veiksmai turi įtakos produktyvumui. „Devops“ komandoms dažnai reikalingi papildomi bandymų tvarkaraščiai už CI / CD vamzdynų, kad būtų galima atlikti ilgesnius bandymus.
- Komandos turėtų reguliariai aptarti automatinių testų spragas, ypač patvirtinimus, kuriems reikalingi dalyko ekspertai, UAT arba testai su partneriais. Jei judrios komandos negali pašalinti šių spragų automatizuotai, tada išleidimo ciklai turėtų turėti įtakos pridėtinėms išlaidoms, kad sumažintų riziką ir atliktų šiuos bandymus.
Galiausiai, judrios komandos ir „devops“ organizacijos turėtų reguliariai matuoti ir aptarti jų testų aprėptį. Testavimo strategijos taikymas „kairės“ kairės pusės neveikia, jei kūrėjų komandos ir kokybės automatikos inžinieriai faktiškai neįgyvendina, automatizuoja ir neintegruoja pakankamai testų, kad būtų galima išspręsti problemas ir pašalinti riziką.
Paspartinus išleidimo ciklus arba įgalinant nuolatinį pristatymą be pakankamos bandymų automatikos, gali kilti didelių kokybės problemų, kurios pablogina galutinių vartotojų patirtį. Vikros kūrėjų komandos, dažnai spaudžiančios leidimus, sprendžia gamybos problemas ir trūkumus, užuot investavusios į daugiau ir geresnę automatiką.
