Hogyan mérhetjük a tesztelés folyamatát?

A vezetőség részéről érkező kérdések megválaszolása sokszor nem is olyan egyszerű. Még akkor sem, ha megfelelő teszteszközökkel és tesztmódszertannal van felfegyverezve a csapat. Ahhoz hogy számos kérdésre válaszolni tudjunk, előtte mérni kell! Mérni kell, de mit és hogyan? Elég ha csak a hibák eloszlását nézzük?

Minden tesztvezetőnek két fő kérdésre mindig tudnia kell a választ: „Hogy áll a tesztelési folyamat?”, és „Még mennyi tesztelési feladat van hátra?” A grafikonokat és kimutatásokat alkalmazó Dashboard-dal, könnyedén meghatározható a helyes válasz. A menedzsmentnek is azonnali információkkal tudunk szolgálni, amikor érdeklődnek a jelenlegi állapotról.

Tapasztalataim alapján a tesztvezetők túlságosan támaszkodnak a hibák arányára a tesztelés nyomon követésekor. A hibák száma valóban fontos, de közel sem elegendő. A teljes folyamat átlátásához szükséges mérni és jegyzőkönyvezni a következőket:

• A szoftver bizonyos funkciói hogyan teljesítenek a tesztelés alatt;
• A teszttervek száma hogyan viszonyul a tesztfuttatások számához, és a sikeres tesztekhez;
• A „hibás javítási arány”-t (továbbiakban HJA) – a rossz javítások aránya az összes javításhoz képest – a lezárt hibák esetén;
• A halmozott hiba tendenciákat az újonnan megtalált és a lezárt hibák esetében.

Mikor lesz kész a tesztelés?

Ebben a cikkben megmutatok néhány kimutatás- és grafikonmintát, amit fel lehet használni a dashboard-nál. Elmagyarázom, hogy miért fontosak ezek a mérések, és hogyan adják ki együttesen a tesztelési folyamat állapotát.
Mikor lesz kész a tesztelés? Erre a kérdésre az egyes ábra adja meg a választ. (1. ábra) Listázza a termékfunkciókat és a teljesítmény-forgatókönyvet, megmutatja a jelenlegi állapotot, és az esetleges változásokat is követhetjük. Ez a dashboard a projekt különböző funkciói köré szerveződik, de szükség esetén modulokkal vagy területekkel is megoldható. Én mégis inkább a funkciókat javaslom, mert pontosabban meghatározza, hogy az ügyfél valójában mit használ vagy vesz. Verzió- vagy release-kritériumok esetén – mint pl. a teljesítmény-forgatókönyvek – a baloldali oszlopban követhetjük a folyamatot. Ezáltal a dashboard-on nyomon követhető hogy mit használnak az ügyfelek és mire fordíts figyelmet.

Hogyan haladnak a tesztelők?

A másik fontos kérdés, hogy a tesztelők hogyan haladnak a munkával? Ez nem mérhető csupán a befejezett tesztesetek számával, mivel az egydimenziós mérés sosem lehet pontos. Ha több változót is figyelembe veszünk – tervezett tesztesetek, tesztfuttatások, sikeres tesztek száma, – már jobban átláthatóvá válik a kérdés; ahogy ezt grafikon is jól mutatja. (2. ábra)

Az ábrán látszik, hogy a tervezett tesztesetek mennyisége a projekt késői szakaszában jelentősen nő, mivel a követelmények is ott szaporodnak meg. A sikeres tesztek száma az első időben azért olyan alacsony, mert a fejlesztők nem fordítottak kellő figyelmet a jelentett hibák javítására. A tesztfuttatásokban sok a stagnálás, köszönhetően annak, hogy a tesztelők olyan gyors ütemben fedeztek fel hibákat, mint amilyen ütemben a fejlesztők megtalálták és javították a korábbi problémákat. Más szóval, olyan ütemben zárjuk a hibákat, amilyenben újakat találunk. Ha csak az egyik mérést ábrázolnánk a grafikonon, ezek az összefüggések nem látszódnának.

Milyen ütemben haladnak a fejlesztők?

A tesztelők méréséhez a fejlesztést is figyelnünk kell. Ennek az információnak a megszerzéséhez lehet, hogy együtt kell dolgozni a projekt vezetőjével. Személy szerint leginkább a „hibás javítási arányt” (HJA) szeretem mérni a követelmény változásával együtt, hogy lássam a fejlesztők hogyan haladnak. Tapasztalataim alapján érdemes ezt a számot 8% alatt tartani, mert fölötte a HJA exponenciálisan növekszik, és a fejlesztők stressz-szintje annyira megnő, hogy az már a hatékonyság rovására megy. A HJA alacsonyan tartásával viszont elfogadhatóan képesek haladni, és a folyamat a tervek szerint alakul, ahogy ez a grafikonon is látszik. (3. ábra)

Hibák időbeli eloszlása

Volt részem már olyan helyzetben is, amikor a vezetőség visszaélt a fenti grafikonnal, és a fejlesztőket hibáztatta a tesztfolyamat lassúságáért. Amennyiben ez a ti cégeteknél is előfordul, inkább ne jelenítsd meg a dashboard-on!

A negyedik ábra a hibák összesített, pillanatnyi állapotát mutatja. Nem hiszek a hibák kategorizálásában – kritikus vagy sürgős – megjelölésében, mert minden ügyfél az általa felfedezett hibát tartja a legkritikusabbnak. Továbbá, ha ezt a metódust használod, a hibaosztályozási megbeszélések sosem érnek véget. Csakis a hibák száma fontos. Azt is tartsd szem előtt, ha csak azt a számot jegyzed meg, hogy hány hibával nyitottál vagy hány hibát zártál, nem fogod látni a teljes képet!

Figyeld meg, hogy az ábrában szereplő terméknél ritkán találtunk 20-nál több hibát egy  héten! Általában kevesebb került elő, és legalább annyit ki is javítottunk. Amikor a felső vezetők észrevették, hogy több mint 100 nyitott hiba van, igencsak meglepődtek. A még lezáratlan hibák összesített száma sokkolta őket. Gondold el, akkor mennyire meg lennének lepődve, ha nem javítottunk volna ki legalább annyi hibát hetente, mint amennyit felfedeztünk!

Ahhoz, hogy a tesztelés befejezésének időpontját meg tudd határozni, el kell döntened,  mely egyéb – a követelmények változásához kapcsolódó – adatot követsz! Ha a követelmények folyamatosan változnak, a tesztelésnek sosem lesz vége.

Döntsd el, milyen adatok szükségesek ahhoz, hogy valós képet kapj az egészről!

Forrás: https://searchsoftwarequality.techtarget.com/tip/How-to-measure-test-progress-Every-picture-tells-a-story
Szerző: Johanna Rothman