Automatsko dokumentiranje dokaza o testiranju

Neuspjeli regresijski test je iritantan. Prošao test bez upotrebljivog dokaza često je jedva bolji. Tko želi automatski dokumentirati dokaze o testiranju, ne rješava time čisto problem izvještavanja. Riječ je o čvrstom odgovoru na konkretna pitanja: Što je testirano? U kojoj verziji? S kojim ulaznim podacima? Što se stvarno dogodilo na zaslonu? I može li razvojni programer, voditelj QA-a, ili revizor kasnije rekonstruirati rezultat?

Upravo kod poslovno kritičnih web i Windows aplikacija ta se pitanja ne javljaju tek kod revizije. Javljaju se kada se nakon izdanja narudžba pogrešno obradi, kada kupac prijavi neuobičajenu grešku, ili kada tim mora prije izdanja razlikovati između "izgleda dobro" i "dokazivo provjereno". Ručno vođeni Excel popisi, snimke zaslona u razgovorima, i razbacane bilješke o testiranju dostatni su samo dok opseg i stopa promjena ostaju mali.

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

U mnogim timovima dokumentacija počinje s dobrim namjerama. Tester zabilježi rezultat, doda snimku zaslona, i zabilježi testiranu verziju. Pod vremenskim pritiskom to se ipak brzo pretvori u skraćenu rutinu: označi kvačicu, proslijedi grešku, sljedeći testni slučaj. To je razumljivo, posebno kod ponavljajućih regresijskih testova - ali nije čvrsto.

Problem nije u pojedinačnim zaposlenicima. Ručna dokumentacija uvijek se natječe sa stvarnim testnim radom. Čim treba provjeriti deset, pedeset, ili nekoliko stotina slučajeva po izdanju, ili nedostaje vremena za čiste dokaze, ili dokazi postanu toliko opsežni da ih nitko više ne vrednuje. Tome se pridodaju tipične praznine: snimka zaslona prikazuje stanje, ali ne i prethodni tijek. Testni zapisnik navodi slučaj, ali ne i korišteni broj gradnje. Greška je ispravljena, ali nije vidljivo kada i kako je ispravka ponovno provjerena.

Za aplikacije koje obrađuju narudžbe, kretanja zaliha, cijene, korisnička prava, ili sučelja, to je više od pitanja udobnosti. Nedokumentirani test ne može pouzdano vrijediti kao dovršena provjera rizika. To posebno vrijedi kada naizgled mala promjena na jednom mjestu izazove sporedne učinke u susjednim procesima.

Što stvarno mora sadržavati upotrebljiv dokaz o testiranju

Dokaz o testiranju nije jednostavno snimka zaslona sa zelenom kvačicom. Povezuje testni slučaj s njegovim tehničkim i poslovnim kontekstom. Barem mora kasnije biti prepoznatljivo koja aplikacija, koja verzija, i koje testno okruženje su provjereni. Jednako su važni vrijeme početka, vrijeme završetka, rezultat, i jasna dodjela odgovarajućem testnom koraku.

Kod automatiziranih UI testova dokaz bi trebao dodatno zabilježiti izvedene radnje i promatrane rezultate. Primjer: test kreira narudžbu, provjerava zbroj stavke, generira otpremnicu, i zatim provjerava status u području otpreme. Dobar zapisnik ne bilježi samo "prošao". Pokazuje na kojem je koraku provjera provedena, koju je vrijednost sustav trebao vratiti, i koju je vrijednost stvarno vratio.

Snimke zaslona ili kratke snimke ekrana vrijedne su pritom, ali nisu uvijek obavezne za svaki pojedinačni uspješan korak. Koštaju prostor za pohranu i mogu sadržavati osjetljive podatke. Obično ima smisla stupnjevita strategija: kod neuspjelih provjera automatski se sprema potpuni vizualni dokaz; kod uspješnih standardnih slučajeva dovoljni su strukturirani podaci zapisnika i odabrani dokazi. Koliko je dubine potrebno ovisi o riziku, učestalosti promjena, i regulatornom okruženju.

Dokaz mora biti čitljiv i tehnički upotrebljiv

Razvojnim programerima trebaju detalji poput poruka o greškama, očekivanih/stvarnih vrijednosti, vremenskih oznaka, i konkretnog koraka u tijeku testiranja. Poslovni odjeli i odgovorni za izdanje, s druge strane, trebaju razumljivu izjavu: koji su poslovni procesi provjereni, što je prošlo, i gdje je potrebno djelovanje?

Obje perspektive trebale bi proizaći iz istog izvršavanja testa. Ako QA tim izveze tehničke zapisničke datoteke i zatim ručno napiše sažetak za menadžment, ponovno nastaje na greške sklon prekid medija. Bolje je sustav koji strukturirano bilježi sirove podatke i iz njih generira jasnu procjenu, bez skrivanja tehničkih detalja.

Automatsko dokumentiranje dokaza o testiranju: ispravan tijek

Automatizacija najbolje funkcionira kada je vezana uz jasno definirane rizike. Ne mora se svaki klik u svakoj aplikaciji odmah automatizirati i potpuno dokumentirati. Polazna točka obično su stabilni, često ponavljani, i poslovno kritični tijekovi rada: prijava i provjera prava, unos narudžbe, izračun cijene, generiranje dokumenata, skladišno knjiženje, ili predaja podataka sučelju.

Za svaki tijek rada prvo se definira što vrijedi kao prošli test. "Zaslon izgleda ispravno" je za to preneprecizno. Bolji su konkretni uvjeti provjere: korisnik s ulogom skladišta ne smije moći mijenjati cijene. Broj otpremnice se generira. Količina smanjuje dostupnu zalihu. Nakon pet neuspjelih pokušaja aktivira se blokada računa. Takvi kriteriji čine testne slučajeve ponovljivima, a dokaze usporedivima.

Izvršavanje testa tada bi trebalo automatski započeti s kontekstnim podacima. To uključuje broj gradnje ili verzije, ciljano okruženje, preglednik ili operativni sustav, stanje testnih podataka, i vremensku oznaku. Tijekom izvršavanja sustav bilježi pojedinačne korake, očekivane i stvarne rezultate, te tehničke nepravilnosti. Kod odstupanja generira dokaze, poput snimaka zaslona, poruka o greškama, ili snimke relevantnog tijeka.

Na kraju ne stoji nestrukturirana mapa datoteka, već testno izvršavanje sa statusom. U idealnom slučaju može se pratiti unatrag od odluke o izdanju do pojedinačnog koraka zašto je test procijenjen kao prošao ili neuspio. Upravo ta povezanost znatno smanjuje rasprave nakon incidenta.

Gdje AI zaista pomaže - a gdje ne

AI može znatno ubrzati dokumentaciju i procjenu. Može procijeniti stanja zaslona, označiti upadljiva odstupanja, i sažeti testna izvršavanja na razumljivom jeziku. Kod velikih količina testova to pomaže QA timovima da ne moraju ručno čitati svako uspješno izvršavanje. Procjena s pragom pouzdanosti može dodatno istaknuti slučajeve u kojima je prepoznavanje nesigurno i ljudska provjera ostaje potrebna.

Ipak, AI ne bi trebao sam odlučivati o kritičnim izdanjima. Kod područja poput odobrenja plaćanja, prava, logike cijena, ili pravno relevantnih dokumenata potrebni su deterministički kriteriji provjere. Očekivani iznos je ili točno izračunat ili nije. Uloga ima pristup ili ga nema. AI ovdje nadopunjuje analizu vizualnog i jezičnog sadržaja, ali ne zamjenjuje čisto definirano poslovno pravilo.

Rukovanje podacima također je arhitektonska odluka. Snimke zaslona iz internih aplikacija mogu prikazati podatke o kupcima, cijene, adrese, ili proizvodne informacije. Tko automatski dokumentira dokaze o testiranju, trebao bi stoga unaprijed odrediti gdje se ti dokazi pohranjuju, tko ih smije pregledavati, i koliko dugo se čuvaju. Za sigurnosno svjesne timove, samostalno hostirana testna infrastruktura poput COCO može imati smisla, jer testni promet, snimke, i procjena ostaju u vlastitom kontroliranom okruženju.

Rokovi čuvanja, pristupi, i kvaliteta dokaza

Više dokaza nije automatski bolji dokaz. Godinama rastuća zbirka snimaka zaslona bez modela uloga i koncepta čuvanja stvara novi rizik. Smisleni su stupnjeviti rokovi: neuspjela ili za izdanje relevantna testna izvršavanja čuvati dulje, uspješne rutinske testove nakon definiranog razdoblja zgusnuti ili obrisati, i osjetljive testne podatke rano anonimizirati.

Jednako je odlučujuća nepromjenjivost. Ako se rezultati testova naknadno mogu uređivati bez traga, gube vrijednost kao dokaz. Promjene testnih slučajeva, rezultata, ili statusa izdanja stoga bi trebale biti zabilježene. To ne znači da svakom testnom izvještaju treba kompliciran revizijski softver. No odgovornosti, vremenske oznake, i sljedljive povijesti pripadaju osnovnoj opremi.

Počnite s procesom koji zaista boli

Najsmisleniji prvi korak automatizacije rijetko je najveći. Odaberite tijek rada koji se provjerava kod svakog izdanja, košta mnogo ručnih minuta, i ima primjetne posljedice u slučaju greške. To može biti unos narudžbe na web portalu, generiranje otpremnog dokumenta, ili koncept prava u Windows aplikaciji.

Definirajte za taj tijek rada jasne kriterije uspjeha, potrebne dokaze, i odgovornog primatelja za neuspjele testove. Nakon nekoliko izdanja brzo se pokaže jesu li dokazi dovoljno razumljivi, nastaje li previše podataka, i koji bi testovi trebali slijediti sljedeće. Tako ne raste stroj za dokumentaciju radi same dokumentacije, već lanac provjere koji brže osigurava izdanja i pruža čvrste odgovore u slučaju problema.