Mikor érdemes egy tesztesetet módosítani, elavultnak jelölni vagy kivezetni?

Egy szoftver folyamatosan változik: új funkciók jelennek meg, meglévő folyamatok alakulnak át, egyes megoldások pedig teljesen eltűnnek a rendszerből. A tesztkészletnek követnie kell azokat a változásokat, amelyek a tesztelendő működést, követelményeket vagy kockázatokat érintik. Ha ez elmarad, idővel olyan tesztesetek halmozódhatnak fel, amelyek már nem a jelenlegi működést ellenőrzik, miközben továbbra is időt és figyelmet igényelnek.

A tesztesetek karbantartása ezért nem egyszerű adminisztráció. Egy jól felépített tesztmenedzsment platform azonban abban is segíthet, hogy a tesztkészlet változásai nyomon követhetők legyenek, és egyértelmű maradjon, mely tesztek relevánsak az aktuális szoftververzió szempontjából. Ez közvetlenül befolyásolja a tesztelés hatékonyságát és azt is, mennyire lehet megbízni a teszteredményekben.

A teszteseteknek együtt kell változniuk a szoftverrel

Egy teszteset általában egy adott követelményhez, funkcióhoz vagy működési folyamathoz kapcsolódik. Amikor ezek megváltoznak, három különböző helyzet állhat fenn: a teszt továbbra is szükséges, de frissíteni kell az új változat szerint; az aktuális release-ben már nem releváns, de történeti szempontból még fontos; vagy az általa ellenőrzött működés végleg megszűnt és nem is lényeges megtartani.

A három helyzetet érdemes külön kezelni. Ha minden változásra egyszerűen új teszteset létrehozásával reagálunk, a tesztkészlet gyorsan átláthatatlan káosszá válhat. Ha viszont a régi teszteket nyom nélkül töröljük, elveszíthetjük annak lehetőségét, hogy később rekonstruáljuk, egy korábbi release-ben pontosan mit és hogyan ellenőriztünk.

Mikor érdemes módosítani egy tesztesetet?

Módosításra akkor van szükség, ha a vizsgált funkció továbbra is létezik, de a működése vagy az elvárt eredmény megváltozott.

Ilyen lehet például, ha egy rendelési folyamat új jóváhagyási lépést kap, megváltozik egy üzleti szabály, új mező kerül egy űrlapra, vagy egy API válaszstruktúrája módosul. A teszt célja ilyenkor ugyanaz marad, de a végrehajtás lépéseit, a tesztadatokat vagy az elvárt eredményt a működés szerint módosítani kell.

Itt azonban fontos kérdés, hogy mit jelent a módosítás történeti szempontból. Egy mai teszteset nem feltétlenül írja le helyesen azt, hogyan működött a rendszer három verzióval korábban. Emiatt hosszú életciklusú termékeknél értékes lehet a tesztesetek verzióinak megőrzése. Így később is visszakövethető, hogy egy adott release vagy szoftververzió esetén pontosan mely teszteset-verzió, feltételek és elvárt eredmények voltak érvényesek.

Mikor válik egy teszteset elavulttá?

Az elavult teszteset nem feltétlenül rossz vagy hibás teszt. Egyszerűen olyan állapotot vizsgál, amely az aktuális szoftververzió esetén már nem releváns.

Tegyük fel, hogy egy alkalmazás korábban két külön bejelentkezési módot támogatott, de az egyik megoldást egy új release során megszüntették. Az ahhoz tartozó teszteseteknek már nincs helyük az aktuális regressziós tesztkészletben. Ettől még korábbi release-ek tesztelési eredményeinek visszakeresésekor vagy értelmezésekor fontos információt hordozhatnak.

Ezért az elavultság kezelése jobb megoldás lehet, mint az azonnali törlés. Így az aktív tesztkészlet tisztább marad, miközben a korábbi állapot továbbra is visszakövethető. A regressziós tesztelés optimalizálásának szempontjából is fontos, hogy ne kizárólag abból induljunk ki, hogy minden korábban létrehozott tesztet minden release előtt azonos prioritással kell végrehajtani, hanem az aktuális változások és kockázatok alapján határozzuk meg a tesztelési fókuszt.

Mikor indokolt egy teszteset végleges kivezetése?

Kivezetés akkor válhat indokolttá, amikor megvizsgálható, hogy a duplikált tesztek közül melyek vonhatók össze úgy, hogy közben ne vesszen el releváns tesztelési lefedettség. Gyakori példa a duplikáció. Egy hosszabb ideje fejlesztett rendszerben előfordulhat, hogy több teszt ugyanazt a működést ellenőrzi, mert különböző időpontokban vagy különböző csapatok hozták létre őket. Ilyenkor érdemes megvizsgálni, hogy szükség van-e mindegyikre, vagy egy jól megtervezett teszteset átveheti több, korábbi teszteset szerepét.

Hasonló döntés indokolt lehet akkor is, ha az ellenőrzött funkció végleg kikerült a termékből, és a teszt megőrzését már auditálási vagy visszakövethetőségi szempont sem indokolja. A végleges kivezetés előtt azonban célszerű meggyőződni arról, hogy a teszthez kapcsolódó korábbi eredmények és egyéb szükséges információk továbbra is elérhetők maradnak.

A túl nagy tesztkészlet sem feltétlenül előny

Könnyű abból kiindulni, hogy minél több tesztesettel rendelkezik egy projekt, annál alaposabb a tesztelés. A tesztesetek száma azonban önmagában keveset mond el a minőségről.

Egy több ezer elemből álló tesztkészletben lehetnek duplikált, elavult vagy alacsony értékű tesztek, miközben egy frissen módosított, üzletileg kritikus kódrészlet kevés figyelmet kap. Ebben az esetben a tesztek mennyisége önmagában nem mutatja meg, hogy az aktuális változásokat megfelelően ellenőriztük-e.

Érdemes ezért külön vizsgálni, hogy az aktív tesztek mely funkciókat és követelményeket fedik le, illetve automatizált tesztek esetén milyen kódlefedettségi információk állnak rendelkezésre. Míg a követelménylefedettség azt mutatja meg, hogy a meghatározott követelményekhez tartoznak-e megfelelő tesztesetek, a kódlefedettség arról ad információt, hogy a tesztfuttatás során a forráskód mely részei kerültek ténylegesen végrehajtásra.

A kockázatalapú teszteset priorizálás ezek mellett abban segít, hogy a tesztelési fókusz kialakításakor az adott funkció üzleti jelentőségét, az aktuális változásokat, a korábbi hibákat és más releváns kockázati tényezőket is figyelembe vegyük.

A release-ek adják meg a tesztek valódi kontextusát

Ahogy a szoftver változik, a hozzá tartozó tesztesetek is folyamatosan módosulnak. Ezért fontos visszakövetni, hogy egy adott release-ben az egyes tesztesetek mely verziói voltak érvényesek, mely tesztek jelentek meg újonnan, melyek változtak meg, és melyek váltak irrelevánssá. Egy új release esetén nem egy statikus tesztkészletből érdemes kiindulni, hanem abból, hogy mi változott a termékben, és ehhez hogyan változott a tesztelési igény.

A TestNavigator támogatja a tesztesetek verziókezelését és a release baseline-ok használatát, vagyis annak rögzítését, hogy egy adott release-ben mely tesztesetek és azok mely verziói számítottak relevánsnak. A lefedettség- és változásalapú információk pedig hozzájárulnak ahhoz, hogy a release készültség megítélése ne pusztán a tesztvégrehajtási státuszokra épüljön, hanem az aktuális változások teszteléséről is pontosabb kép álljon rendelkezésre.

A jól karbantartott tesztkészlet a release-döntést is segíti

A tesztkészlet értéke nem attól nő, hogy folyamatosan egyre nagyobb lesz. Sokkal fontosabb, hogy tükrözze a termék aktuális állapotát, megőrizze a szükséges történeti információkat, és segítsen azonosítani, hogy egy változás után hol van valóban szükség tesztelésre.

Ezért a tesztesetek életciklusának kezelése nem csupán arról szól, hogy rendet tartunk a tesztmenedzsment rendszerben. A megfelelően verziózott, aktualizált és karbantartott tesztkészlet pontosabb képet ad arról, hogy mit ellenőriztünk, mi változott, és mennyire áll készen az adott release a kiadásra.