Kako ispravno ocijeniti Test Automation Results

Regresijski test može ujutro završiti sa 98 posto uspješnih slučajeva i ipak ne biti dobra vijest. Možda je neuspjeli test upravo prijava velikog kupca. Možda je 40 testova preskočeno jer testno okruženje nije bilo dostupno. Ili je izvođenje bilo zeleno, ali je provjeravalo samo postoje li gumbi, a ne sprema li se narudžba doista, stvara li se otpremnica i ispravlja li se zaliha. Test automation results nisu izjava o kvaliteti sve dok im nedostaje kontekst.

Za voditelje QA-a, razvoj i stručne odjele stvarni posao stoga nije samo u automatiziranju testova. Odlučujuće je pripremiti rezultate tako da iz njih nastaju pouzdane odluke: može li se izdanje pustiti u rad? Treba li grešku odmah obraditi? Je li greška nova, ponovno se pojavila ili je samo problem testnog okruženja? I postoje li dokazi koje može razumjeti i stručni odjel bez testnog koda?

Što Test Automation Results doista govore

Najjednostavniji pokazatelj glasi: prošao ili pao. Koristan je, ali rijetko dovoljan. Visok udio uspjeha može stvoriti povjerenje ako testovi pokrivaju kritične procese, testni podaci su uvjerljivi, a okruženje sliči kasnijem radu. Ako nedostaje jedan od tih čimbenika, broj ostaje prije svega signal da je automatizirani tijek izveden.

Kod poslovno kritičnih aplikacija druga pitanja imaju veću težinu. U skladišnom rješenju nije svaki prikaz zaslona jednako važan. Greška prikaza u internom tekstu napomene može pričekati. Greška koja pri ulazu robe knjiži pogrešnu količinu ili stvara naljepnicu za otpremu bez adrese primatelja, ne može. Dobri rezultati testova stoga vagaju rizike umjesto da sve slučajeve tretiraju jednako.

Ni neuspjeli test nije automatski greška proizvoda. Može ga izazvati istekli pristupni podaci, blokirana testna uloga, nedostupna sučelja, promijenjeni testni podaci ili sporo okruženje. Tko te uzroke ne razdvaja, proizvodi buku. Tim tada troši vrijeme na lažne uzbune dok prave greške nestaju među crvenim statusnim porukama.

Četiri vrste statusa umjesto jedne crvene liste

U praksi se potvrđuje jasna podjela: stručna greška, tehnička greška testa, problem okruženja i očekivana promjena. Stručna greška znači da aplikacija krši definirani zahtjev. Tehnička greška testa upućuje prije na sam test, primjerice selektor koji više ne odgovara nakon namjerno promijenjenog sučelja.

Problem okruženja postoji kada je, primjerice, testni sustav ili povezano sučelje nedostupno. Očekivane promjene nastaju kada je proces namjerno prilagođen, a automatizacija još provjerava staro ciljno stanje. Te kategorije ne sprječavaju svaku raspravu. No osiguravaju da rasprava počne na pravom mjestu.

Od testnih izvođenja do izvještaja spremnih za odluku

Upotrebljiv izvještaj ne odgovara samo da je nešto palo, nego što se dogodilo, koliko je ozbiljno i čini li se da je greška reproducibilna. Za to treba više od popisa naziva testova i vremenskih oznaka.

Uz svako relevantno izvođenje pripadaju provjereni build, testno okruženje, korištena uloga, središnji testni podaci te vrijeme početka i završetka. Osobito kod Windows desktop aplikacija ili složenih web platformi te su informacije potrebne za sužavanje razlika. Greška koja se javlja samo pod ograničenom skladišnom ulogom nešto je drugo od greške koja blokira svaku prijavu.

Informativni rezultati uz to sadrže sljedive dokaze: snimke zaslona, snimljene korake, poruke o greškama i po potrebi tehničke zapisnike. Snimka zaslona sama može, međutim, zavarati. Pokazuje trenutak, ne uzrok. Kombinacija slijeda koraka, vidljivog stanja i očekivane reakcije znatno je korisnija.

Sustavi potpomognuti umjetnom inteligencijom mogu te dokaze pretvoriti u razumljive ocjene. Kod COCO-a, primjerice, testovi se izvode na vlastitom, samostalno hostiranom AI poslužitelju. Evaluacija može objasniti da je narudžba stvorena, ali očekivana promjena statusa nije uslijedila, i izravno pridružiti snimku izvođenja. Za timove osviještene o sigurnosti važno je gdje se obrađuju snimke zaslona, podaci aplikacije i testni promet. Lokalna kontrola nije automatski nužna, ali kod internih aplikacija i osjetljivih podataka može biti smisleniji put od vanjske cloud usluge.

Prava razina detalja za različite primatelje

Razvojni timovi trebaju poruke o greškama, tehničke korake i što preciznije naznake za reprodukciju. Voditelj operacija pak prvo treba pogođenu funkciju, poslovni rizik i jasnu izjavu o operativnoj sposobnosti. Obje perspektive moraju moći nastati iz istog izvođenja, bez da netko mora ručno prenositi rezultate u prezentacije.

Dobar izvještaj stoga počinje kratkom razinom odluke: preporučeno izdanje, izdanje uz poznata ograničenja ili zaustaviti izdanje. Ispod toga stoje kritična odstupanja s prioritetom i dokazom. Tehnički detalji slijede tek poslije. To nije pojednostavljenje nauštrb točnosti, nego čisto razdvajanje informacijskih potreba.

Mjeriti pokrivenost bez zavaravanja lažnom sigurnošću

Pokrivenost testovima često se prikazuje kao postotak. Ta je vrijednost korisna kada je jasno što mjeri. Pokrivenost koda pokazuje, primjerice, koji su dijelovi programskog koda izvedeni tijekom testova. To ne dokazuje da poslovni proces ispravno funkcionira. Test može dotaknuti mnogo redaka koda, a da nikada ne provjeri pojavljuje li se pogrešna dostavna adresa na dokumentu.

Za stručne odjele pokrivenost procesa često je rječitija. Opisuje koji su stvarni tijekovi zaštićeni: evidentirati narudžbu, rezervirati zalihu, knjižiti djelomičnu isporuku, prihvatiti povrat ili odobriti račun. Posebno su vrijedni prijelazi između sustava i uloga, jer tamo često nastaju greške: pri uvozu narudžbe, ispisu naljepnice ili prelasku iz ureda na skladišni terminal.

Ne određujte prioritete prema broju mogućih testova, nego prema težini štete i učestalosti promjena. Rijetko korišten proces s visokim financijskim ili pravnim rizikom često zaslužuje automatizaciju prije od često korištenog, ali bezazlenog prikaza. Obrnuto, stabilan, malo kritičan tijek i dalje može proći uz kratku ručnu provjeru. Ne mora se svaka provjera automatizirati samo zato što se može.

Nestabilni testovi su zaseban problem kvalitete

Testovi koji bez prepoznatljive promjene proizvoda čas prolaze, čas padaju, često se nazivaju flaky. Oni narušavaju povjerenje brže od trajno crvenog testa. Čim timovi refleksno ponovno pokreću crvene rezultate, automatizacija gubi svoju funkciju upozorenja.

Uzroci su najčešće konkretni: fiksna čekanja, zajednički korišteni testni podaci, paralelni pristupi, asinkrona obrada ili okruženje koje se ne vraća u početno stanje. Kratka stanka od tri sekunde u testu može slučajno pomoći, ali nije rješenje. Bolje je čekati dokazivo stanje, učiniti testne podatke jedinstvenima i međusobno izolirati tijekove.

Svaka se nestabilnost ne može posve izbjeći. Vanjska sučelja mogu varirati, a stvarna infrastruktura ima ispade. Tada izvještaj treba jasno naznačiti je li test zbog vanjske ovisnosti bio neprocjenjiv. Ponovljeno izvođenje može biti korisno za dijagnozu, ali ne smije prvi nalaz učiniti nevidljivim.

Smislen tijek nakon svakog testnog izvođenja

Nakon automatiziranog izvođenja ne bi trebalo svaki rezultat odmah jednako tretirati. Prvo se provjeravaju blokirajuće greške i neprocjenjivi kritični testovi. Zatim slijedi razvrstavanje novih odstupanja naspram poznatih, prihvaćenih problema. Tek tada je odluka o izdanju pouzdana.

Korisne su utvrđene granične vrijednosti, ali moraju odgovarati procesu. Primjerice, neuspjeli test u toku plaćanja ili ovlaštenja može izazvati trenutačno zaustavljanje. Kod čisto kozmetičkog odstupanja dokumentirana iznimka može biti opravdana. Takva pravila ne bi trebala nastati tek pod vremenskim pritiskom prije izdanja.

Jednako je važna povratna veza: svaka produkcijska greška koju testovi nisu prepoznali povod je da se provjeri nedostaje li scenarij, varijanta testnih podataka ili kontrolna točka. Cilj nije nagomilati što više testova. Cilj je iz stvarnih grešaka ciljano izgraditi bolju zaštitu.

Najkorisniji rezultati testova na kraju nisu oni s najzelenijim pregledom. To su oni uz koje odgovorna osoba u ponedjeljak ujutro može razumjeti što je provjereno, koji rizik ostaje i koja je radnja sada razumna.