Miért nem elég a sikeresen lefutott tesztek aránya egy Go/No-Go döntéshez?

Release előtt megnyugtatóan hangzik, ha a tesztek 95 vagy akár 100 százaléka sikeresen lefutott. Ez azonban önmagában még nem jelenti azt, hogy a szoftver biztonsággal kiadható. A sikeres tesztek aránya csak azt mutatja meg, hogy a végrehajtott tesztek közül mennyi zárult megfelelő eredménnyel. Arra viszont nem ad választ, hogy valóban a megfelelő területeket ellenőriztük-e.

A Go/No-Go döntéshez ezért nem egyetlen mutatóra, hanem több, egymást kiegészítő információra van szükség.

Nem mindegy, mit teszteltünk

Tegyük fel, hogy egy release előtt 1000 tesztesetből 900-at végrehajtottunk, és ezek 98 százaléka sikeresen lefutott. Első látásra ez jó eredménynek tűnik, nem?

De mi történik akkor, ha a kimaradt 100 teszt éppen azokat a funkciókat ellenőrzi, amelyek a legutóbbi fejlesztések során jelentősen megváltoztak? Vagy ha a sikeresen lefutott tesztek nagyrészt olyan kódrészeket érintettek, amelyekhez a release-ben senki nem nyúlt? Ilyenkor a magas sikerességi arány valós adat, mégsem ad teljes képet a release kockázatáról.

A kódlefedettség megmutatja, hogy a tesztek a kód mely részeit érintették

A teszteredmények mellé ezért érdemes azt is megvizsgálni, hogy a tesztelés a kód mely részeit érintette. A kódlefedettség mérése abban segít, hogy ne csak azt lássuk, hány teszt futott le sikeresen, hanem azt is, hogy a tesztek végrehajtása során a kód mely részei futottak le.

Különösen fontos lehet a teljes kódlefedettség mellett a megváltozott kód lefedettségének vizsgálata. Egy release során ugyanis elsősorban az új vagy módosított részek jelentenek új bizonytalanságot.

Előfordulhat például, hogy a teljes alkalmazás kódlefedettsége magas, miközben az adott release-ben módosított kód jelentős része nem került lefedésre a tesztfuttatások során. Egy egyszerű pass rate ezt nem mutatná meg.

A végrehajtási arány is számít

A sikerességi arányt mindig érdemes együtt vizsgálni azzal is, hogy az elvárt tesztek mekkora részét hajtottuk végre. Ha 50 végrehajtott tesztből mind az 50 sikeres, akkor a pass rate 100 százalék. Ez azonban teljesen mást jelent, ha összesen 55 tesztet kellett volna lefuttatni, és mást, ha 500-at.

A Go/No-Go döntés szempontjából ezért legalább három kérdést érdemes egyszerre feltenni:

• A tervezett tesztek mekkora része futott le?
• A végrehajtott tesztek milyen eredménnyel zárultak?
• A release-ben érintett kódterületeket megfelelő mértékben lefedték-e a tesztek?

A Go/No-Go döntéshez kontextus kell

A release döntéstámogatás lényege nem az, hogy egyetlen szám alapján automatikusan eldöntsük, kiadható-e a szoftver. Sokkal inkább az, hogy a döntéshozók ugyanabban a kontextusban lássák a legfontosabb QA-adatokat.

Ide tartozhat a sikeresen és sikertelenül lefutott tesztek aránya, a végrehajtott tesztek száma, a teljes kódlefedettség, a megváltozott kód lefedettsége, illetve az előre meghatározott Exit Criteria teljesülése.

Így egy magas pass rate nem önmagában kerül értelmezésre, hanem a release tényleges tesztelési állapotának részeként.

Az előre meghatározott kritériumok csökkentik a bizonytalanságot

A release vége gyakran időnyomással jár. Ilyenkor a döntés könnyen benyomásokra és részleges információkra épülhet, például arra, hogy összességében megfelelőnek tűnik-e a tesztelés állapota, illetve maradt-e még olyan kritikus hiba, amely akadályozhatja a kiadást.

Az előre rögzített Exit Criteria ezt objektívebbé teheti. Meghatározható például egy minimum teljes kódlefedettség, külön küszöbérték a megváltozott kód lefedettségére, valamint az elvárt tesztek végrehajtási aránya.

A Go/No-Go riportálás ezeket a mutatókat egységesen tudja megjeleníteni, így a döntés mögött nem csupán egy státusz vagy százalék, hanem ellenőrizhető QA-információ áll.

Hogyan támogatja mindezt a TestNavigator?

A TestNavigator tesztmenedzsment platform segítségével a tesztfuttatások eredményei, a kódlefedettségi adatok és a release-hez tartozó változások közös nézetben vizsgálhatók. Így nemcsak az látható, hogy mely tesztek futottak le sikeresen vagy sikertelenül, hanem az is, hogy a tesztfuttatások milyen mértékben érintették a teljes kódbázist, illetve külön a release során módosított kódrészeket.

Az Exit Criteria segítségével előre meghatározhatók azok a küszöbértékek, amelyek teljesülése szükséges a release megfelelő tesztelési állapotához. Külön feltétel állítható be például a teljes kódlefedettségre, a változott kód lefedettségére és a végrehajtott tesztek arányára.

A TestNavigator így több, egymást kiegészítő QA-mutatót helyez közös kontextusba, és segít gyorsan azonosítani, hogy mely feltételek teljesültek, illetve hol maradt még olyan terület, amely további ellenőrzést igényel. A release állapota ezért nem kizárólag a zöld vagy piros teszteredményekből ítélhető meg, hanem a tesztvégrehajtás, a kódlefedettség és a változások együttes értékelésére épülhet. Ez átláthatóbb és következetesebb alapot ad a Go/No-Go döntés előkészítéséhez.

A zöld teszt még nem jelent automatikusan zöld utat

A sikeresen lefutott tesztek aránya fontos QA-mutató, de csak egy része a release-ről kialakított képnek. A valódi kérdés nem az, hogy a lefuttatott tesztek sikeresek voltak-e, hanem az, hogy a szükséges teszteket hajtottuk-e végre, és azok megfelelően lefedték-e a release szempontjából releváns kódrészeket.