Samodejno dokumentiranje testnih dokazov

Neuspešen regresijski test je moteč. Uspešen test brez uporabnega dokaza je pogosto komaj boljši. Kdor želi samodejno dokumentirati testne dokaze, s tem ne rešuje zgolj problema poročanja. Gre za trden odgovor na konkretna vprašanja: Kaj je bilo testirano? V kateri različici? S katerimi vhodnimi podatki? Kaj se je dejansko zgodilo na zaslonu? In ali lahko razvijalec, vodja QA, ali revizor pozneje rekonstruira rezultat?

Prav pri poslovno kritičnih spletnih in Windows aplikacijah se ta vprašanja ne pojavijo šele pri reviziji. Pojavijo se, ko je po izdaji naročilo napačno obdelano, ko stranka prijavi neobičajno napako, ali ko mora ekipa pred izdajo razlikovati med "izgleda v redu" in "dokazano preverjeno". Ročno vodeni Excel seznami, zaslonske slike v pogovorih klepeta, in razpršene testne opombe zadostujejo le, dokler obseg in stopnja sprememb ostajata majhna.

Zakaj ročni testni dokazi hitro postanejo nezanesljivi

V mnogih ekipah dokumentacija začne z dobrimi nameni. Tester zabeleži rezultat, doda zaslonsko sliko, in zabeleži testirano različico. Pod časovnim pritiskom pa se to hitro spremeni v skrajšano rutino: obkljukaj, posreduj napako, naslednji testni primer. To je razumljivo, zlasti pri ponavljajočih se regresijskih testih - a ni trdno.

Problem ni pri posameznih zaposlenih. Ročna dokumentacija je vedno v konkurenci z dejanskim testnim delom. Takoj ko je treba preveriti deset, petdeset, ali več sto primerov na izdajo, bodisi zmanjka časa za čiste dokaze, bodisi dokazi postanejo tako obsežni, da jih nihče več ne vrednoti. Temu se pridružijo tipične vrzeli: zaslonska slika prikazuje stanje, a ne predhodnega poteka. Testni dnevnik navaja primer, a ne uporabljene številke gradnje. Napaka je bila popravljena, a ni razvidno, kdaj in kako je bil popravek ponovno preverjen.

Za aplikacije, ki obravnavajo obdelavo naročil, skladiščne premike, cene, uporabniške pravice, ali vmesnike, je to več kot vprašanje udobja. Nedokumentiran test ne more zanesljivo veljati kot opravljena preverba tveganja. To še posebej velja, kadar navidez majhna sprememba na enem mestu sproži stranske učinke v sosednjih procesih.

Kaj mora resnično vsebovati uporaben testni dokaz

Testni dokaz ni preprosto posnetek zaslona z zeleno kljukico. Povezuje testni primer z njegovim tehničnim in poslovnim kontekstom. Vsaj mora biti pozneje razpoznavno, katera aplikacija, katera različica, in katero testno okolje so bili preverjeni. Enako pomembni so čas začetka, čas konca, rezultat, in jasna dodelitev ustreznemu testnemu koraku.

Pri avtomatiziranih UI testih bi moral dokaz dodatno zajeti izvedena dejanja in opažene rezultate. Primer: test ustvari naročilo, preveri vsoto postavke, ustvari dobavnico, in nato preveri status v območju odpreme. Dober dnevnik ne beleži le "uspešno". Pokaže, na katerem koraku je potekala preverba, kakšno pričakovano vrednost naj bi sistem vrnil, in kakšno vrednost je dejansko vrnil.

Zaslonske slike ali kratki posnetki zaslona so pri tem dragoceni, a niso vedno obvezni za vsak posamezen uspešen korak. Zahtevajo prostor za shranjevanje in lahko vsebujejo občutljive podatke. Običajno je smiselna stopenjska strategija: pri neuspešnih preverbah se samodejno shrani popoln vizualni dokaz; pri uspešnih standardnih primerih zadostujejo strukturirani podatki dnevnika in izbrani dokazi. Koliko globine je potrebno, je odvisno od tveganja, pogostosti sprememb, in regulativnega okolja.

Dokaz mora biti berljiv in tehnično uporaben

Razvijalci potrebujejo podrobnosti, kot so sporočila o napakah, pričakovane/dejanske vrednosti, časovne oznake, in konkreten korak v poteku testa. Poslovni oddelki in odgovorni za izdajo pa potrebujejo razumljivo izjavo: kateri poslovni procesi so bili preverjeni, kaj je uspelo, in kje je potrebno ukrepanje?

Obe perspektivi bi morali izhajati iz istega izvajanja testa. Če ekipa QA izvozi tehnične dnevniške datoteke in nato ročno napiše povzetek za vodstvo, ponovno nastane na napake nagnjen prelom medija. Boljši je sistem, ki strukturirano zajame surove podatke in iz njih ustvari jasno oceno, ne da bi skrival tehnične podrobnosti.

Samodejno dokumentiranje testnih dokazov: pravilen potek

Avtomatizacija najbolje deluje, kadar je vezana na jasno opredeljena tveganja. Ni treba vsakega klika v vsaki aplikaciji takoj avtomatizirati in popolnoma dokumentirati. Izhodišče so običajno stabilni, pogosto ponavljajoči se, in poslovno kritični delovni tokovi: prijava in preverjanje pravic, vnos naročila, izračun cene, ustvarjanje dokumentov, skladiščno knjiženje, ali predaja podatkov vmesniku.

Za vsak delovni tok se najprej določi, kaj velja za uspešen test. "Zaslon izgleda pravilno" je za to preveč nenatančno. Boljši so konkretni pogoji preverjanja: uporabnik z vlogo skladišča ne sme moči spreminjati cen. Številka dobavnice se ustvari. Količina zmanjša razpoložljivo zalogo. Po petih neuspešnih poskusih se aktivira blokada računa. Taki kriteriji naredijo testne primere ponovljive in dokaze primerljive.

Izvajanje testa bi se moralo nato samodejno začeti s kontekstnimi podatki. Sem sodijo številka gradnje ali različice, ciljno okolje, brskalnik ali operacijski sistem, stanje testnih podatkov, in časovna oznaka. Med izvajanjem sistem beleži posamezne korake, pričakovane in dejanske rezultate, ter tehnične nepravilnosti. Pri odstopanjih ustvari dokaze, kot so zaslonske slike, sporočila o napakah, ali posnetek relevantnega poteka.

Na koncu ni nestrukturirane mape datotek, temveč izvajanje testa s statusom. V idealnem primeru je mogoče slediti nazaj od odločitve o izdaji do posameznega koraka, zakaj je bil test ocenjen kot uspešen ali neuspešen. Prav ta povezava znatno zmanjša razprave po incidentu.

Kje umetna inteligenca resnično pomaga - in kje ne

Umetna inteligenca lahko občutno pospeši dokumentacijo in oceno. Zna oceniti stanja zaslona, označiti opazna odstopanja, in povzeti izvajanja testov v razumljivem jeziku. Pri velikih količinah testov to pomaga ekipam QA, da jim ni treba ročno brati vsakega uspešnega izvajanja. Ocena s pragom zaupanja lahko dodatno izpostavi primere, kjer je zaznavanje negotovo in človeška preverba ostaja potrebna.

Kljub temu umetna inteligenca ne bi smela sama odločati o kritičnih izdajah. Pri področjih, kot so odobritev plačila, pravice, logika cen, ali pravno pomembni dokumenti, so potrebni deterministični kriteriji preverjanja. Pričakovan znesek je bodisi pravilno izračunan bodisi ni. Vloga ima dostop ali ga nima. Umetna inteligenca tu dopolnjuje analizo vizualne in jezikovne vsebine, a ne nadomešča čisto opredeljenega poslovnega pravila.

Tudi ravnanje s podatki je arhitekturna odločitev. Zaslonske slike iz internih aplikacij lahko prikazujejo podatke o strankah, cene, naslove, ali proizvodne informacije. Kdor samodejno dokumentira testne dokaze, bi zato moral vnaprej določiti, kje se ti dokazi shranjujejo, kdo jih sme pregledovati, in kako dolgo se hranijo. Za varnostno ozaveščene ekipe je lahko samostojno gostovana testna infrastruktura, kot je COCO, smiselna, ker testni promet, posnetki, in ocena ostanejo v lastnem nadzorovanem okolju.

Roki hrambe, dostopi, in kakovost dokazov

Več dokazov ni samodejno boljših dokazov. Leta rastoč arhiv zaslonskih slik brez modela vlog in koncepta hrambe ustvari novo tveganje. Smiselni so stopenjski roki hrambe: neuspešna ali za izdajo relevantna izvajanja testov hraniti dlje, uspešne rutinske teste po določenem obdobju strniti ali izbrisati, in občutljive testne podatke zgodaj anonimizirati.

Enako odločilna je nespremenljivost. Če je mogoče rezultate testov naknadno urejati brez sledi, izgubijo vrednost kot dokaz. Spremembe testnih primerov, rezultatov, ali statusa izdaje bi zato morale biti beležene. To ne pomeni, da vsako testno poročilo potrebuje zapleteno revizijsko programsko opremo. A odgovornosti, časovne oznake, in sledljive zgodovine spadajo v osnovno opremo.

Začnite s procesom, ki resnično boli

Najsmiselnejši prvi korak avtomatizacije je redko največji. Izberite delovni tok, ki se preverja pri vsaki izdaji, stane veliko ročnih minut, in ima opazne posledice v primeru napake. To je lahko vnos naročila na spletnem portalu, ustvarjanje odpremnega dokumenta, ali koncept pravic v Windows aplikaciji.

Za ta delovni tok opredelite jasne kriterije uspeha, potrebne dokaze, in odgovornega prejemnika za neuspele teste. Po nekaj izdajah se hitro pokaže, ali so dokazi dovolj razumljivi, ali nastaja preveč podatkov, in kateri testi naj sledijo naslednji. Tako ne raste dokumentacijski stroj sam sebi v namen, temveč veriga preverjanja, ki hitreje zavaruje izdaje in v primeru težav ponudi trdne odgovore.