Jei dirbote judrioje aplinkoje kaip kokybės užtikrinimo priemonė, greičiausiai būtumėte susidūrę su tam tikra bandymų automatika. Turiu omenyje ne vieneto testavimo automatizavimą, kuris paprastai yra kūrėjo orientuota veikla, bet funkcinio priėmimo testavimo automatizavimą, kurį paprastai atlieka kokybės užtikrinimas arba naujas išgalvotas programinės įrangos kūrėjo vaidmuo bandyme.
Pirmiausia apžvelkime keletą bandymų automatizavimo kriterijų ir priežasčių, kurios turėtų atsakyti į klausimą „Kodėl bandymai turėtų būti / neturėtų būti automatizuoti“
Automatizuoti testai turėtų būti kartojami, o išvestis turėtų būti nuosekli kiekviename bandyme, kad kūrėjai galėtų pasikliauti testų rezultatais. Tai taip pat reiškia, kad mes paprastai neautomatizuotume testo, jei jis bus vykdomas tik vieną kartą; vienintelė išimtis - jei atliekate bandymą su labai daug duomenų, pavyzdžiui, patikrinate nuorodų peradresavimo scenarijų su daugeliu nuorodų.
Automatiniai testai iš tikrųjų turėtų teisingai tikrinti patikras ir sugebėti nustatyti tikrus rezultatus pagal galiojančius numatomus rezultatus. Tai taip pat reiškia, kad jei rezultatų nustatyti negalima lengvai arba jei dėl automatinių testų kyla aplinkos problemų, dėl kurių bandymo rezultatai gali būti klaidingi, bandymai negali būti patikimi.
Automatiniai testai taip pat turėtų mums sutaupyti laiko. Jei paprastam testui atlikti reikia 10 minučių, tačiau tą patį rezultatą galima nustatyti per 1 minutę rankiniu būdu, geriausia tokių bandymų neautomatizuoti.
Automatizuoti bandymai turėtų suteikti apsaugą kūrėjams, kad bet koks nukrypimas nuo gero veikiančio kodo, pasikeitus kodo bazei, būtų greitai paryškintas ir pranešta kūrėjams.
Paprastame sprinte pasakykite, kad yra 7 istorijos, kurios yra skirtos sprintui, iš kurių 5 yra geri kandidatai, kuriuos reikia automatizuoti pagal pirmiau nurodytus kriterijus. Bet kada geriausia automatizuoti šias istorijas? Ar turėtume rašyti automatinius testus, kai funkcijos tobulinamos? Ar turėtume palaukti, kol bus sukurta funkcija, ir tada parašyti automatinius testus? Ar palaukime iki sprinto pabaigos ir tada automatizuosime istorijas?
Kai kuriais atvejais, kai istorijos yra klaidų taisymai arba nedidelis esamos funkcijos pakeitimas ar patobulinimas, prasminga rašyti automatinius testus, kai kūrėjai keičia šią funkciją. Gali būti net esamas automatizuojamas funkcijos modifikavimas, kurio metu jums tereikia patobulinti scenarijų, kad būtų pritaikyti nauji pakeitimai.
Kitais atvejais, kai pasakojama apie naujos funkcijos pritaikymą programoje, kaip mes žinome, koks bus galutinis produktas, kad galėtume iš anksto parašyti testus? Čia aš kalbu ne apie funkcijų failus, kuriuose iš anksto aprašomi priėmimo testai, bet tikruosius armatūros ar seleno testus (testų įgyvendinimą), kurie veikia pagal pateiktą kodą.
Esmė yra ta, kad visi bandymai, kurie bus atliekami daugiau nei vieną kartą, turėtų būti automatizuoti. Ir kuriuos bandymus atliksime daugiau nei vieną kartą? Regresijos testai. O kas yra regresijos testai? Testai, kuriais nustatoma, ar dėl naujų modifikacijų ir funkcijų taikomoji programa regresavo.
Bet jūs galite parašyti gerus automatizuotus regresijos testus tik sistemoje, kuri yra stabili, gerai suprantama ir determinuojanti elgseną su žinomais įėjimais ir išvestimis.
Problema bandant rašyti automatinius testus pagal kuriamą funkciją yra ta, kad jūs galėtumėte sugaišti daug laiko ir daug pastangų, rašydami automatinius scenarijus prieš tai, kas yra nepastovi ir gali būti nuolat keičiama sprinto metu. Be to, kiek kartų matėme istoriją, kuri buvo skirta sprintui, o vėliau buvo ištraukta iš sprinto? Tada sugaišome laiką scenarijaus kūrimui, kuris nepateko į sistemą.
Kai kurios organizacijos net nustato griežtą taisyklę, kad istorija nėra „daroma“, kol ji nėra visiškai automatizuota! Ar nutrauksime išleisti svarbią funkciją, nes kokybės užtikrinimas dėl įvairių priežasčių laiku nepateikė ar negalėjo pateikti automatikos? Arba istorija nėra „padaryta“, nes mes neturime automatinio scenarijaus, leidžiančio patikrinti, ar puslapyje yra mygtukas. Rimtai?
Geriausias automatizavimo bandymų tikslas yra regresijos bandymai, o regresijos testai visada atliekami pagal žinomą būseną ir deterministinę sistemą, kad būtų galima aptikti pradinės padėties pokyčius ir gauti prasmingą automatizuoto testo rezultatą, tik tada, kai testas yra paleistas. ir bent kartą perduota rankiniu būdu, todėl galite palyginti automatinio vykdymo rezultatus su rankiniu vykdymu.
Pagal šį apibrėžimą pasakojimai turėtų būti automatizuoti (įgyvendinimas) sprinto metu ir tik tada, kai funkcija yra visiškai patikrinta rankiniu būdu. Kai istorija bus baigta ir ji pirmiausia bus patikrinta rankiniu būdu, tai bus patikima funkcija ir stabili sistema, pagal kurią galėsite susikurti ir parašyti automatinius testus. Įdiegus automatizuotą testą, jis pridedamas prie regresijos testų rinkinio, kad būtų galima stebėti ir aptikti regresijos defektus, nes yra kuriamos kitos funkcijos.