Tesztbizonyítékok automatikus dokumentálása

Egy sikertelen regressziós teszt bosszantó. Egy sikeres teszt hasznosítható bizonyíték nélkül gyakran alig jobb. Aki automatikusan akarja dokumentálni a tesztbizonyítékokat, ezzel nem pusztán jelentési problémát old meg. Konkrét kérdésekre adott szilárd válaszról van szó: Mit teszteltek? Melyik verzióban? Milyen bemenetekkel? Mi történt valójában a képernyőn? És képes-e egy fejlesztő, QA-felelős, vagy auditor később rekonstruálni az eredményt?

Pontosan az üzletileg kritikus web- és Windows-alkalmazásoknál ezek a kérdések nem csak az auditnál merülnek fel. Akkor jönnek elő, amikor egy kiadás után egy rendelést hibásan dolgoznak fel, amikor egy ügyfél szokatlan hibát jelent, vagy amikor egy csapatnak a kiadás előtt különbséget kell tennie "jónak tűnik" és "bizonyítottan ellenőrzött" között. A kézzel vezetett Excel-listák, chat-beszélgetésekben lévő képernyőképek, és laza tesztjegyzetek csak addig elegendők, amíg a terjedelem és a változási ráta kicsi marad.

Miért válik a manuális tesztbizonyíték gyorsan megbízhatatlanná

Sok csapatban a dokumentálás jó szándékkal kezdődik. A tesztelő rögzíti az eredményt, hozzáad egy képernyőképet, és feljegyzi a tesztelt verziót. Időnyomás alatt azonban ez gyorsan lerövidített rutinná válik: pipa, hiba továbbadása, következő teszteset. Ez érthető, különösen az ismétlődő regressziós tesztek esetében - de nem szilárd.

A probléma nem egyes munkatársaknál van. A manuális dokumentáció mindig versenyben áll a tényleges teszteléssel. Amint kilencven, ötven, vagy több száz esetet kell ellenőrizni kiadásonként, vagy hiányzik az idő a tiszta bizonyítékokra, vagy a bizonyítékok annyira terjedelmessé válnak, hogy már senki sem értékeli ki őket. Ehhez társulnak a jellemző hiányosságok: egy képernyőkép egy állapotot mutat, de nem az azt megelőző folyamatot. Egy tesztnapló megnevezi az esetet, de nem a használt build-számot. Egy hibát kijavítottak, de nem látszik, mikor és hogyan ellenőrizték újra a javítást.

A rendeléskezelést, raktármozgásokat, árakat, felhasználói jogosultságokat, vagy interfészeket kezelő alkalmazások esetében ez több, mint kényelmi kérdés. Egy nem dokumentált teszt nem számíthat megbízhatóan elvégzett kockázatellenőrzésnek. Ez különösen igaz akkor, amikor egy látszólag kicsi módosítás egy helyen mellékhatásokat vált ki szomszédos folyamatokban.

Mit kell valójában tartalmaznia egy használható tesztbizonyítéknak

Egy tesztbizonyíték nem egyszerűen egy zöld pipával ellátott képernyőkivágás. Összeköti a teszteset a technikai és üzleti kontextusával. Legalább később felismerhetőnek kell lennie, hogy melyik alkalmazást, melyik verziót, és melyik tesztkörnyezetet ellenőrizték. Ugyanolyan fontos a kezdési idő, a befejezési idő, az eredmény, és az adott teszt lépéshez való egyértelmű hozzárendelés.

Automatizált UI-teszteknél a bizonyítéknak emellett rögzítenie kellene a végrehajtott műveleteket és a megfigyelt eredményeket. Példa: egy teszt létrehoz egy rendelést, ellenőrzi a tételösszeget, létrehoz egy szállítólevelet, majd ellenőrzi a státuszt a szállítási területen. Egy jó napló nem csak azt rögzíti, hogy "sikeres". Megmutatja, melyik lépésnél történt az ellenőrzés, milyen várt értéket kellett a rendszernek visszaadnia, és milyen értéket adott valójában vissza.

A képernyőképek vagy rövid képernyőfelvételek itt értékesek, de nem mindig kötelezőek minden egyes sikeres lépéshez. Tárhelyet igényelnek, és érzékeny adatokat tartalmazhatnak. Általában egy rétegzett stratégia van értelme: sikertelen ellenőrzéseknél automatikusan teljes vizuális bizonyítékot mentenek; sikeres standard eseteknél elég a strukturált naplóadat és a kiválasztott bizonyíték. Hogy mekkora mélység szükséges, az a kockázattól, a változási gyakoriságtól, és a szabályozási környezettől függ.

A bizonyítéknak olvashatónak és technikailag felhasználhatónak kell lennie

A fejlesztőknek olyan részletekre van szükségük, mint a hibaüzenetek, a várt/tényleges értékek, az időbélyegek, és a konkrét lépés a teszt folyamatában. Az üzleti területeknek és a kiadási felelősöknek ezzel szemben érthető nyilatkozatra van szükségük: mely üzleti folyamatokat ellenőrizték, mi sikerült, és hol van szükség beavatkozásra?

Mindkét nézőpontnak ugyanabból a tesztfutásból kellene származnia. Ha egy QA-csapat technikai naplófájlokat exportál, majd kézzel ír egy vezetői összefoglalót, ismét egy hibalehetőséggel teli médiatörés keletkezik. Jobb egy olyan rendszer, amely strukturáltan rögzíti a nyers adatokat, és ezekből világos értékelést generál a technikai részletek elrejtése nélkül.

Tesztbizonyítékok automatikus dokumentálása: a helyes folyamat

Az automatizálás akkor működik a legjobban, ha egyértelműen meghatározott kockázatokhoz kapcsolódik. Nem minden kattintást kell minden alkalmazásban azonnal automatizálni és teljesen dokumentálni. A kiindulópont általában stabil, gyakran ismétlődő, és üzletileg kritikus munkafolyamatok: bejelentkezés és jogosultság-ellenőrzés, rendelésrögzítés, árszámítás, dokumentumgenerálás, raktárkönyvelés, vagy adatátadás egy interfésznek.

Minden munkafolyamathoz először meghatározzák, mi számít sikeres tesztnek. "A képernyő helyesnek tűnik" túl homályos ehhez. Jobbak a konkrét ellenőrzési feltételek: a raktár szerepkörű felhasználó nem módosíthat árakat. A szállítólevél száma generálódik. A mennyiség csökkenti a rendelkezésre álló készletet. Öt sikertelen kísérlet után aktiválódik a fiókzárolás. Az ilyen kritériumok ismételhetővé teszik a teszteseteket, és összehasonlíthatóvá a bizonyítékokat.

A tesztfutásnak ezután automatikusan kellene indulnia kontextusadatokkal. Ide tartozik a build- vagy verziószám, a célkörnyezet, a böngésző vagy operációs rendszer, a tesztadat állapota, és az időbélyeg. A végrehajtás során a rendszer naplózza az egyes lépéseket, a várt és tényleges eredményeket, valamint a technikai rendellenességeket. Eltérések esetén bizonyítékokat generál, például képernyőképeket, hibaüzeneteket, vagy a releváns folyamat felvételét.

A végén nem strukturálatlan fájlmappa áll, hanem egy státusszal rendelkező tesztfutás. Ideális esetben visszakövethető egy kiadási döntéstől az egyes lépésig, hogy miért minősítettek egy tesztet sikeresnek vagy sikertelennek. Éppen ez a kapcsolat jelentősen csökkenti a vitákat egy incidens után.

Hol segít igazán a mesterséges intelligencia - és hol nem

A mesterséges intelligencia érezhetően felgyorsíthatja a dokumentálást és az értékelést. Képes értékelni képernyőállapotokat, megjelölni feltűnő eltéréseket, és összefoglalni tesztfutásokat érthető nyelven. Nagy tesztmennyiségeknél ez segít a QA-csapatoknak, hogy ne kelljen kézzel olvasniuk minden sikeres futást. Egy konfidenciahatárral rendelkező értékelés emellett kiemelheti azokat az eseteket, ahol a felismerés bizonytalan, és emberi ellenőrzés marad szükséges.

Mindazonáltal a mesterséges intelligencia nem dönthet egyedül kritikus kiadásokról. Olyan területeken, mint a fizetési jóváhagyás, jogosultságok, árazási logika, vagy jogilag releváns dokumentumok, determinisztikus ellenőrzési kritériumokra van szükség. Egy várt összeg vagy helyesen van kiszámítva, vagy nem. Egy szerepkörnek van hozzáférése, vagy nincs. A mesterséges intelligencia itt kiegészíti a vizuális és nyelvi tartalom elemzését, de nem helyettesíti a tisztán definiált üzleti szabályt.

Az adatok kezelése is architektúrai döntés. A belső alkalmazásokból származó képernyőképek megjeleníthetnek ügyféladatokat, árakat, címeket, vagy gyártási információkat. Aki automatikusan dokumentálja a tesztbizonyítékokat, annak ezért előre el kell döntenie, hol tárolják ezeket a bizonyítékokat, ki tekintheti meg őket, és meddig őrzik meg. Biztonságtudatos csapatok számára egy önállóan üzemeltetett teszt-infrastruktúra, mint a COCO, hasznos lehet, mert a tesztforgalom, a felvételek, és az értékelés a saját ellenőrzött környezetben marad.

Megőrzési idők, hozzáférések, és a bizonyíték minősége

Több bizonyíték nem automatikusan jobb bizonyíték. Egy évek óta növekvő, szerepmodell és megőrzési koncepció nélküli képernyőkép-archívum új kockázatot teremt. Ésszerűek a rétegzett megőrzési idők: a sikertelen vagy kiadás szempontjából releváns tesztfutásokat tovább megőrizni, a sikeres rutin teszteket egy meghatározott időszak után sűríteni vagy törölni, és az érzékeny tesztadatokat korán anonimizálni.

Ugyanolyan meghatározó a változtathatatlanság. Ha a teszteredmények utólag nyom nélkül szerkeszthetők, elveszítik értéküket mint bizonyíték. A teszteseteken, eredményeken, vagy kiadási státuszon végzett módosításokat ezért naplózni kell. Ez nem jelenti azt, hogy minden tesztjelentéshez bonyolult auditszoftver kellene. De a felelősségek, időbélyegek, és visszakövethető előzmények az alapfelszereltséghez tartoznak.

Kezdjen egy folyamattal, amely tényleg fáj

A legésszerűbb első automatizálási lépés ritkán a legnagyobb. Válasszon olyan munkafolyamatot, amelyet minden kiadásnál ellenőriznek, sok manuális percet igényel, és hiba esetén érezhető következményei vannak. Ez lehet a rendelésrögzítés a webportálon, egy szállítási dokumentum generálása, vagy egy jogosultsági koncepció egy Windows-alkalmazásban.

Határozzon meg világos sikerkritériumokat ehhez a munkafolyamathoz, a szükséges bizonyítékokat, és egy felelős fogadót a sikertelen tesztekhez. Néhány kiadás után gyorsan kiderül, hogy a bizonyítékok elég érthetők-e, hogy nem keletkezik-e túl sok adat, és hogy mely tesztek kövessék ezt. Így nem önmagáért növekvő dokumentációs gépezet jön létre, hanem egy ellenőrzési lánc, amely gyorsabban biztosítja a kiadásokat, és probléma esetén szilárd válaszokat nyújt.