Automatsko dokumentovanje dokaza o testiranju

Neuspeo regresioni test je iritantan. Prošao test bez upotrebljivog dokaza je često jedva bolji. Ko želi automatski da dokumentuje dokaze o testiranju, time ne rešava čist problem izveštavanja. Reč je o čvrstom odgovoru na konkretna pitanja: Šta je testirano? U kojoj verziji? Sa kojim ulaznim podacima? Šta se stvarno dogodilo na ekranu? I može li programer, rukovodilac QA, ili revizor kasnije da rekonstruiše rezultat?

Upravo kod poslovno kritičnih veb i Windows aplikacija ova pitanja se ne javljaju tek prilikom revizije. Javljaju se kada se nakon izdanja narudžbina pogrešno obradi, kada kupac prijavi neuobičajenu grešku, ili kada tim mora pre izdanja da razlikuje između "izgleda dobro" i "dokazivo provereno". Ručno vođeni Excel spiskovi, snimci ekrana u razgovorima, i razbacane beleške o testiranju dovoljni su samo dok obim i stopa promena ostaju mali.

Zašto ručni dokazi o testiranju brzo postaju nepouzdani

U mnogim timovima dokumentacija počinje sa dobrim namerama. Tester zabeleži rezultat, doda snimak ekrana, i zabeleži testiranu verziju. Pod vremenskim pritiskom to se ipak brzo pretvori u skraćenu rutinu: označi kvačicu, prosledi grešku, sledeći testni slučaj. To je razumljivo, posebno kod ponavljajućih regresionih testova - ali nije čvrsto.

Problem nije u pojedinačnim zaposlenima. Ručna dokumentacija se uvek takmiči sa stvarnim testnim radom. Čim treba proveriti deset, pedeset, ili nekoliko stotina slučajeva po izdanju, ili nedostaje vremena za čiste dokaze, ili dokazi postanu toliko obimni da ih niko više ne vrednuje. Tome se pridodaju tipične praznine: snimak ekrana prikazuje stanje, ali ne i prethodni tok. Testni zapisnik navodi slučaj, ali ne i korišćeni broj bilda. Greška je ispravljena, ali nije vidljivo kada i kako je ispravka ponovo proverena.

Za aplikacije koje obrađuju narudžbine, kretanja zaliha, cene, korisnička prava, ili interfejse, to je više od pitanja udobnosti. Nedokumentovani test ne može pouzdano da važi kao dovršena provera rizika. To posebno važi kada naizgled mala promena na jednom mestu izazove sporedne efekte u susednim procesima.

Šta zaista mora da sadrži upotrebljiv dokaz o testiranju

Dokaz o testiranju nije jednostavno snimak ekrana sa zelenom kvačicom. Povezuje testni slučaj sa njegovim tehničkim i poslovnim kontekstom. Barem mora kasnije biti prepoznatljivo koja aplikacija, koja verzija, i koje testno okruženje su provereni. Podjednako su važni vreme početka, vreme završetka, rezultat, i jasna dodela odgovarajućem testnom koraku.

Kod automatizovanih UI testova dokaz bi trebalo dodatno da zabeleži izvedene radnje i posmatrane rezultate. Primer: test kreira narudžbinu, proverava zbir stavke, generiše otpremnicu, i zatim proverava status u oblasti otpreme. Dobar zapisnik ne beleži samo "prošao". Pokazuje na kom koraku je izvršena provera, koju je vrednost sistem trebalo da vrati, i koju je vrednost stvarno vratio.

Snimci ekrana ili kratki snimci ekrana su vredni pri tome, ali nisu uvek obavezni za svaki pojedinačni uspešan korak. Koštaju prostor za skladištenje i mogu sadržati osetljive podatke. Obično ima smisla stepenasta strategija: kod neuspešnih provera automatski se čuva potpuni vizuelni dokaz; kod uspešnih standardnih slučajeva dovoljni su strukturirani podaci zapisnika i odabrani dokazi. Koliko je dubine potrebno zavisi od rizika, učestalosti promena, i regulatornog okruženja.

Dokaz mora biti čitljiv i tehnički upotrebljiv

Programerima su potrebni detalji poput poruka o greškama, očekivanih/stvarnih vrednosti, vremenskih oznaka, i konkretnog koraka u toku testiranja. Poslovni odseci i odgovorni za izdanje, s druge strane, trebaju razumljivu izjavu: koji su poslovni procesi provereni, šta je prošlo, i gde je potrebno delovanje?

Obe perspektive trebalo bi da proizađu iz istog izvršavanja testa. Ako QA tim izveze tehničke fajlove zapisnika i zatim ručno napiše rezime za menadžment, ponovo nastaje na greške sklon prekid medija. Bolje je sistem koji strukturirano beleži sirove podatke i iz njih generiše jasnu procenu, bez skrivanja tehničkih detalja.

Automatsko dokumentovanje dokaza o testiranju: ispravan tok

Automatizacija najbolje funkcioniše kada je vezana za jasno definisane rizike. Ne mora svaki klik u svakoj aplikaciji odmah da se automatizuje i potpuno dokumentuje. Polazna tačka obično su stabilni, često ponavljani, i poslovno kritični tokovi rada: prijava i provera prava, unos narudžbine, izračunavanje cene, generisanje dokumenata, skladišno knjiženje, ili predaja podataka interfejsu.

Za svaki tok rada prvo se definiše šta važi kao prošao test. "Ekran izgleda ispravno" je za to previše neprecizno. Bolji su konkretni uslovi provere: korisnik sa ulogom skladišta ne sme moći da menja cene. Broj otpremnice se generiše. Količina smanjuje dostupnu zalihu. Nakon pet neuspešnih pokušaja aktivira se blokada naloga. Takvi kriterijumi čine testne slučajeve ponovljivim, a dokaze uporedivim.

Izvršavanje testa tada bi trebalo automatski da počne sa kontekstnim podacima. Tome pripadaju broj bilda ili verzije, ciljano okruženje, pregledač ili operativni sistem, stanje testnih podataka, i vremenska oznaka. Tokom izvršavanja sistem beleži pojedinačne korake, očekivane i stvarne rezultate, kao i tehničke nepravilnosti. Kod odstupanja generiše dokaze, poput snimaka ekrana, poruka o greškama, ili snimka relevantnog toka.

Na kraju ne stoji nestrukturiran folder fajlova, već testno izvršavanje sa statusom. U idealnom slučaju može se pratiti unazad od odluke o izdanju do pojedinačnog koraka zašto je test procenjen kao prošao ili neuspešan. Upravo ta povezanost znatno smanjuje rasprave nakon incidenta.

Gde AI zaista pomaže - a gde ne

AI može znatno da ubrza dokumentaciju i procenu. Može da proceni stanja ekrana, označi upadljiva odstupanja, i sažme testna izvršavanja na razumljivom jeziku. Kod velikih količina testova to pomaže QA timovima da ne moraju ručno da čitaju svako uspešno izvršavanje. Procena sa pragom pouzdanosti može dodatno da istakne slučajeve u kojima je prepoznavanje nesigurno i ljudska provera ostaje potrebna.

Ipak, AI ne bi trebalo sama da odlučuje o kritičnim izdanjima. Kod oblasti poput odobrenja plaćanja, prava, logike cena, ili pravno relevantnih dokumenata potrebni su deterministički kriterijumi provere. Očekivani iznos je ili tačno izračunat ili nije. Uloga ima pristup ili ga nema. AI ovde dopunjuje analizu vizuelnog i jezičkog sadržaja, ali ne zamenjuje čisto definisano poslovno pravilo.

Rukovanje podacima je takođe arhitektonska odluka. Snimci ekrana iz internih aplikacija mogu prikazati podatke o kupcima, cene, adrese, ili proizvodne informacije. Ko automatski dokumentuje dokaze o testiranju, trebalo bi stoga unapred da odredi gde se ti dokazi čuvaju, ko sme da ih pregleda, i koliko dugo se čuvaju. Za bezbednosno svesne timove, samostalno hostovana testna infrastruktura poput COCO može imati smisla, jer testni saobraćaj, snimci, i procena ostaju u sopstvenom kontrolisanom okruženju.

Rokovi čuvanja, pristupi, i kvalitet dokaza

Više dokaza nije automatski bolji dokaz. Godinama rastuća zbirka snimaka ekrana bez modela uloga i koncepta čuvanja stvara novi rizik. Smisleni su stepenasti rokovi: neuspešna ili za izdanje relevantna testna izvršavanja čuvati duže, uspešne rutinske testove nakon definisanog perioda zgusnuti ili obrisati, i osetljive testne podatke rano anonimizovati.

Podjednako je odlučujuća nepromenljivost. Ako se rezultati testova naknadno mogu uređivati bez traga, gube vrednost kao dokaz. Promene testnih slučajeva, rezultata, ili statusa izdanja stoga bi trebalo da budu zabeležene. To ne znači da svaki testni izveštaj treba komplikovan revizorski softver. Ali odgovornosti, vremenske oznake, i sledljive istorije pripadaju osnovnoj opremi.

Počnite sa procesom koji zaista boli

Najsmisleniji prvi korak automatizacije retko je najveći. Izaberite tok rada koji se proverava kod svakog izdanja, košta mnogo ručnih minuta, i ima primetne posledice u slučaju greške. To može biti unos narudžbine na veb portalu, generisanje otpremnog dokumenta, ili koncept prava u Windows aplikaciji.

Definišite za taj tok rada jasne kriterijume uspeha, potrebne dokaze, i odgovornog primaoca za neuspešne testove. Nakon nekoliko izdanja brzo se pokaže da li su dokazi dovoljno razumljivi, da li nastaje previše podataka, i koji testovi bi trebalo da slede dalje. Tako ne raste mašina za dokumentaciju radi same dokumentacije, već lanac provere koji brže obezbeđuje izdanja i pruža čvrste odgovore u slučaju problema.