Kako pravilno ovrednotiti Test Automation Results

Regresijski test se lahko zjutraj konča z 98 odstotki uspešnih primerov in kljub temu ni dobra novica. Morda je neuspeli test ravno prijava velikega kupca. Morda je bilo 40 testov preskočenih, ker testno okolje ni bilo dosegljivo. Ali pa je bil zagon zelen, a je preverjal le, ali gumbi obstajajo, ne pa, ali se naročilo res shrani, ustvari dobavnica in pravilno prilagodi zaloga. Test automation results niso izjava o kakovosti, dokler manjka njihov kontekst.

Za vodstvo QA, razvoj in strokovne oddelke prava naloga zato ni le v avtomatizaciji testov. Odločilno je rezultate pripraviti tako, da iz njih nastanejo zanesljive odločitve: ali je mogoče izdajo uvesti? Ali je treba napako obravnavati takoj? Ali je napaka nova, ponovljena ali le težava testnega okolja? In ali obstajajo dokazi, ki jih lahko razume tudi strokovni oddelek brez testne kode?

Kaj Test Automation Results v resnici povedo

Najpreprostejši kazalnik se glasi: uspešno ali neuspešno. Je koristen, a redko zadosten. Visok delež uspeha lahko ustvari zaupanje, če testi pokrivajo kritične procese, so testni podatki verjetni in okolje spominja na poznejše delovanje. Če manjka eden od teh dejavnikov, število ostane predvsem signal, da je bil izveden avtomatiziran potek.

Pri poslovno kritičnih aplikacijah imajo večjo težo druga vprašanja. V skladiščni rešitvi vsak zaslon ni enako pomemben. Napaka prikaza v notranjem besedilu namiga lahko počaka. Napaka, ki pri prejemu blaga knjiži napačno količino ali ustvari odpremno nalepko brez naslova prejemnika, ne more. Dobri rezultati testov zato tehtajo tveganja, namesto da bi vse primere obravnavali enako.

Tudi neuspešen test ni samodejno napaka izdelka. Lahko ga sprožijo potekli dostopni podatki, blokirana testna vloga, nedosegljivi vmesniki, spremenjeni testni podatki ali počasno okolje. Kdor teh vzrokov ne loči, proizvaja šum. Ekipa potem porablja čas za lažne alarme, medtem ko prave napake izginjajo med rdečimi statusnimi sporočili.

Štiri vrste stanja namesto enega rdečega seznama

V praksi se je izkazala jasna razdelitev: strokovna napaka, tehnična napaka testa, težava okolja in pričakovana sprememba. Strokovna napaka pomeni, da aplikacija krši določeno zahtevo. Tehnična napaka testa kaže prej na sam test, na primer na selektor, ki ne ustreza več po namerno spremenjenem vmesniku.

Težava okolja obstaja, kadar je na primer testni sistem ali povezan vmesnik nedosegljiv. Pričakovane spremembe nastanejo, ko je bil proces namerno prilagojen, avtomatizacija pa še vedno preverja staro ciljno stanje. Te kategorije ne preprečijo vsake razprave. A poskrbijo, da se razprava začne na pravem mestu.

Od testnih zagonov do poročil, pripravljenih za odločitev

Uporabno poročilo ne odgovori le, da je nekaj spodletelo, temveč kaj se je zgodilo, kako resno je in ali se napaka zdi ponovljiva. Za to je potrebno več kot seznam imen testov in časovnih žigov.

Vsakemu relevantnemu zagonu pripadajo preverjena izgradnja, testno okolje, uporabljena vloga, osrednji testni podatki ter čas začetka in konca. Zlasti pri namiznih aplikacijah Windows ali zapletenih spletnih platformah so te informacije potrebne za zožitev razlik. Napaka, ki se pojavi le pod omejeno skladiščno vlogo, je nekaj drugega kot napaka, ki blokira vsako prijavo.

Pomembni rezultati poleg tega vsebujejo sledljive dokaze: posnetke zaslona, posnete korake, sporočila o napakah in po potrebi tehnične dnevnike. Samo posnetek zaslona pa lahko zavede. Prikazuje trenutek, ne vzroka. Kombinacija zaporedja korakov, vidnega stanja in pričakovanega odziva je bistveno bolj koristna.

Sistemi, podprti z umetno inteligenco, lahko te dokaze pretvorijo v razumljive ocene. Pri COCO na primer testi tečejo na lastnem, samostojno gostovanem AI strežniku. Vrednotenje lahko pojasni, da je bilo naročilo sicer ustvarjeno, a pričakovana sprememba stanja ni nastopila, in neposredno pripiše posnetek izvedbe. Za varnostno ozaveščene ekipe je pomembno, kje se obdelujejo posnetki zaslona, podatki aplikacije in testni promet. Lokalni nadzor ni samodejno nujen, a je lahko pri notranjih aplikacijah in občutljivih podatkih smiselnejša pot kot zunanja oblačna storitev.

Prava raven podrobnosti za različne prejemnike

Razvojne ekipe potrebujejo sporočila o napakah, tehnične korake in čim natančnejše napotke za reprodukcijo. Operativni vodja pa najprej potrebuje prizadeto funkcijo, poslovno tveganje in jasno izjavo o operativni sposobnosti. Obe perspektivi morata lahko nastati iz iste izvedbe, ne da bi moral kdo rezultate ročno prenašati v predstavitve.

Dobro poročilo se zato začne s kratko odločitveno ravnjo: izdaja priporočena, izdaja z znanimi omejitvami ali ustavitev izdaje. Pod tem stojijo kritična odstopanja s prioriteto in dokazom. Tehnične podrobnosti sledijo šele zatem. To ni poenostavitev na račun natančnosti, temveč čista ločitev informacijskih potreb.

Meriti pokritost brez zavajanja z navidezno varnostjo

Pokritost s testi se pogosto prikazuje kot odstotek. Ta vrednost je koristna, kadar je jasno, kaj meri. Pokritost kode na primer kaže, kateri deli programske kode so bili izvedeni med testi. To ne dokazuje, da poslovni proces deluje pravilno. Test se lahko dotakne mnogih vrstic kode, pa vendar nikoli ne preveri, ali se na dokumentu pojavi napačen dostavni naslov.

Za strokovne oddelke je pokritost procesov pogosto izpovednejša. Opisuje, kateri resnični poteki so zaščiteni: evidentirati naročilo, rezervirati zalogo, knjižiti delno dobavo, sprejeti vračilo ali odobriti račun. Posebej dragoceni so prehodi med sistemi in vlogami, ker tam pogosto nastanejo napake: pri uvozu naročila, tiskanju nalepke ali prehodu iz pisarne na skladiščni terminal.

Ne določajte prioritet glede na število možnih testov, temveč glede na učinek škode in pogostost sprememb. Redko uporabljen proces z visokim finančnim ali pravnim tveganjem si pogosto zasluži avtomatizacijo prej kot pogosto uporabljen, a nenevaren pogled. Obratno lahko stabilen, malo kritičen potek še vedno shaja s kratkim ročnim preverjanjem. Ni treba avtomatizirati vsakega preverjanja le zato, ker se ga da avtomatizirati.

Nestabilni testi so samostojen problem kakovosti

Testi, ki brez prepoznavne spremembe izdelka enkrat uspejo, drugič spodletijo, se pogosto imenujejo flaky. Zaupanje poškodujejo hitreje kot trajno rdeč test. Takoj ko ekipe refleksno znova zaženejo rdeče rezultate, avtomatizacija izgubi svojo opozorilno funkcijo.

Vzroki so običajno konkretni: trdi čakalni časi, skupaj uporabljeni testni podatki, vzporedni dostopi, asinhrona obdelava ali okolje, ki se ne ponastavi. Kratek premor treh sekund v testu lahko po naključju pomaga, a ni rešitev. Bolje je počakati na dokazljivo stanje, narediti testne podatke enolične in poteke med seboj izolirati.

Vse nestabilnosti ni mogoče povsem preprečiti. Zunanji vmesniki lahko nihajo, prava infrastruktura ima izpade. Poročilo naj potem jasno označi, ali testa zaradi zunanje odvisnosti ni bilo mogoče oceniti. Ponovljen zagon je lahko smiseln za diagnozo, a ne sme narediti prve ugotovitve nevidne.

Smiseln potek po vsakem testnem zagonu

Po avtomatiziranem zagonu ne bi smeli vsakega rezultata takoj obravnavati enako. Najprej se preverijo blokirajoče napake in kritični testi, ki jih ni bilo mogoče oceniti. Nato sledi razvrstitev novih odstopanj glede na znane, sprejete težave. Šele potem je odločitev o izdaji trdna.

Koristne so določene mejne vrednosti, a se morajo prilegati procesu. Na primer, neuspešen test v poteku plačil ali pooblastil lahko sproži takojšnjo ustavitev. Pri čisto kozmetičnem odstopanju je lahko dokumentirana izjema upravičena. Taka pravila ne bi smela nastati šele pod časovnim pritiskom pred izdajo.

Enako pomembna je povratna zanka: vsaka produkcijska napaka, ki je testi niso zaznali, je razlog za preverjanje, ali manjka scenarij, različica testnih podatkov ali kontrolna točka. Cilj ni nakopičiti čim več testov. Cilj je iz resničnih napak ciljno zgraditi boljšo zaščito.

Najkoristnejši rezultati testov na koncu niso tisti z najzelenejšim pregledom. So tisti, pri katerih lahko odgovorna oseba v ponedeljek zjutraj razume, kaj je bilo preverjeno, katero tveganje ostaja in katero dejanje je zdaj smiselno.