Kako ispravno oceniti Test Automation Results

Regresioni test može ujutro da se završi sa 98 posto uspešnih slučajeva i ipak ne bude dobra vest. Možda je neuspeli test upravo prijava velikog kupca. Možda je 40 testova preskočeno jer testno okruženje nije bilo dostupno. Ili je izvršavanje bilo zeleno, ali je proveravalo samo postoje li dugmad, a ne čuva li se narudžbina zaista, stvara li se otpremnica i ispravlja li se zaliha. Test automation results nisu izjava o kvalitetu sve dok im nedostaje kontekst.

Za rukovodioce QA-a, razvoj i stručne odeljenja stvarni posao stoga nije samo u automatizovanju 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? Da li je greška nova, ponovo se pojavila ili je samo problem testnog okruženja? I postoje li dokazi koje može da razume i stručno odeljenje bez testnog koda?

Šta Test Automation Results zaista govore

Najjednostavniji pokazatelj glasi: prošao ili pao. Koristan je, ali retko dovoljan. Visok udeo uspeha može stvoriti poverenje ako testovi pokrivaju kritične procese, testni podaci su uverljivi, a okruženje liči kasnijem radu. Ako nedostaje jedan od tih činilaca, broj ostaje pre svega signal da je automatizovani tok izveden.

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

Ni neuspeli test nije automatski greška proizvoda. Može ga izazvati istekli pristupni podaci, blokirana testna uloga, nedostupni interfejsi, promenjeni testni podaci ili sporo okruženje. Ko te uzroke ne razdvaja, proizvodi buku. Tim tada troši vreme na lažne uzbune dok prave greške nestaju među crvenim statusnim porukama.

Četiri vrste statusa umesto jedne crvene liste

U praksi se potvrđuje jasna podela: stručna greška, tehnička greška testa, problem okruženja i očekivana promena. Stručna greška znači da aplikacija krši definisani zahtev. Tehnička greška testa upućuje pre na sam test, na primer selektor koji više ne odgovara nakon namerno promenjenog interfejsa.

Problem okruženja postoji kada je, na primer, testni sistem ili povezani interfejs nedostupan. Očekivane promene nastaju kada je proces namerno prilagođen, a automatizacija još proverava staro ciljno stanje. Te kategorije ne sprečavaju svaku raspravu. No obezbeđuju da rasprava počne na pravom mestu.

Od testnih izvršavanja do izveštaja spremnih za odluku

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

Uz svako relevantno izvršavanje pripadaju provereni build, testno okruženje, korišćena uloga, središnji testni podaci te vreme početka i završetka. Naročito kod Windows desktop aplikacija ili složenih veb 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 sledljive dokaze: snimke ekrana, snimljene korake, poruke o greškama i po potrebi tehničke zapisnike. Snimak ekrana sam može, međutim, da zavara. Pokazuje trenutak, ne uzrok. Kombinacija sleda koraka, vidljivog stanja i očekivane reakcije znatno je korisnija.

Sistemi potpomognuti veštačkom inteligencijom mogu te dokaze pretvoriti u razumljive ocene. Kod COCO-a, na primer, testovi se izvršavaju na sopstvenom, samostalno hostovanom AI serveru. Evaluacija može objasniti da je narudžbina kreirana, ali očekivana promena statusa nije usledila, i direktno pridružiti snimak izvršavanja. Za timove osvešćene o bezbednosti važno je gde se obrađuju snimci ekrana, podaci aplikacije i testni saobraćaj. Lokalna kontrola nije automatski neophodna, ali kod internih aplikacija i osetljivih podataka može biti smisleniji put od spoljne cloud usluge.

Pravi nivo detalja za različite primaoce

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

Dobar izveštaj stoga počinje kratkim nivoom odluke: preporučeno izdanje, izdanje uz poznata ograničenja ili zaustaviti izdanje. Ispod toga stoje kritična odstupanja sa prioritetom i dokazom. Tehnički detalji slede tek posle. To nije pojednostavljenje nauštrb tačnosti, nego čisto razdvajanje informacionih potreba.

Meriti pokrivenost bez zavaravanja lažnom sigurnošću

Pokrivenost testovima često se prikazuje kao procenat. Ta je vrednost korisna kada je jasno šta meri. Pokrivenost koda pokazuje, na primer, koji su delovi programskog koda izvršeni tokom testova. To ne dokazuje da poslovni proces ispravno funkcioniše. Test može dotaći mnogo redova koda, a da nikada ne proveri pojavljuje li se pogrešna dostavna adresa na dokumentu.

Za stručna odeljenja pokrivenost procesa često je rečitija. Opisuje koji su stvarni tokovi zaštićeni: evidentirati narudžbinu, rezervisati zalihu, knjižiti delimičnu isporuku, prihvatiti povrat ili odobriti račun. Posebno su vredni prelazi između sistema i uloga, jer tamo često nastaju greške: pri uvozu narudžbine, ispisu nalepnice ili prelasku iz kancelarije na skladišni terminal.

Ne određujte prioritete prema broju mogućih testova, nego prema težini štete i učestalosti promena. Retko korišćen proces sa visokim finansijskim ili pravnim rizikom često zaslužuje automatizaciju pre od često korišćenog, ali bezazlenog prikaza. Obrnuto, stabilan, malo kritičan tok i dalje može proći uz kratku ručnu proveru. Ne mora se svaka provera automatizovati samo zato što se može.

Nestabilni testovi su zaseban problem kvaliteta

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

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

Svaka se nestabilnost ne može sasvim izbeći. Spoljni interfejsi mogu varirati, a stvarna infrastruktura ima ispade. Tada izveštaj treba jasno naznačiti je li test zbog spoljne zavisnosti bio neprocenjiv. Ponovljeno izvršavanje može biti korisno za dijagnozu, ali ne sme prvi nalaz učiniti nevidljivim.

Smislen tok nakon svakog testnog izvršavanja

Nakon automatizovanog izvršavanja ne bi trebalo svaki rezultat odmah jednako tretirati. Prvo se proveravaju blokirajuće greške i neprocenjivi kritični testovi. Zatim sledi razvrstavanje novih odstupanja naspram poznatih, prihvaćenih problema. Tek tada je odluka o izdanju pouzdana.

Korisne su utvrđene granične vrednosti, ali moraju odgovarati procesu. Na primer, neuspeli test u toku plaćanja ili ovlašćenja može izazvati trenutno zaustavljanje. Kod čisto kozmetičkog odstupanja dokumentovani izuzetak može biti opravdan. Takva pravila ne bi trebalo da nastanu tek pod vremenskim pritiskom pre izdanja.

Jednako je važna povratna veza: svaka produkciona greška koju testovi nisu prepoznali povod je da se proveri nedostaje li scenario, varijanta testnih podataka ili kontrolna tač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 sa najzelenijim pregledom. To su oni uz koje odgovorna osoba u ponedeljak ujutro može razumeti šta je provereno, koji rizik ostaje i koja je radnja sada razumna.