Hogyan mérhető a szoftvertesztelés minősége, előrehaladása, és mik azok a KPI-ok?

Ahhoz, hogy megbizonyosodhassunk arról, hogy a fejlesztés során a tesztelés is megfelelően halad, a minőségellenőrzés mire és milyen mértékben terjedt ki, és ez hogyan változott a folyamat során, mérőszámokra és mutatókra van szükségünk.

Mért is fontos mindez? Milyen ismeretekre tehetünk szert általuk?

• Megmutatják ezek a metrikákák, hogy
  • hány hibát találtunk,
  • mennyit lehetett lezárni már közülük,
  • mennyit kellett újra nyitni,
  • mennyi lett elhalasztva,
  • hány kritikus hiba van közöttük.
• Segítenek a hibák vizsgálatában, lokalizálásában és ellenőrzésében
• Rávilágítanak a tesztelés gyenge pontjaira ezzel lehetőséget adva annak javítására.
• Megmutatják, hogy a tesztelési startégiánk mely részei szorulnak fejlesztésre.
• Felhívják a figyelmet a tesztelésben jelentkező kockázatokra.
• Támogatják a döntéshozatalt:
  • Segítenek validálni, hogy megfelel-e a termék az ügyfél elvárásainak.
  • Segítenek eldönteni, hogy az adott működés megfelelő-e (OK/NOK).
• Hozzájárulnak a fejlesztési folyamatok megfelelő minőségéhez.
• Termék és ügyfélkockázatokra figyelmeztethetnek. (Pl. melyik követelményben van a legtöbb kritikus hiba).

Kétféle mérőszámot használatunk ezek mérésére: a Mutatókat és a KPI-okat

Nézzük meg, hogy mi a különbség közöttük

A KPI-ok (Key Performance Indicator) a tesztelés eredményeinek mutatóiból számított ill. származtatott értékek. Ez egy adott időszakra és célra vonatkozó, mérhető és számszerűsíthető mérőszám. Ez így elsőre nem biztos, hogy mindenkinek sokat mond, de a későbbiekben fény derül a részletekre is.

Ha egyszerűen akarjuk megfogalmazni, akkor a mutatók a „nyers” mért értékek, amik hasznosak, de leginkább akkor tudjuk őket használni, amikor kontextusba helyeztük (legalább fejben). Például tudjuk, hogy a legtöbb teszteset megtervezése 10-35 perc között volt, akkor azzal még olyan sokkal jobb helyzetbe nem kerültünk egészen addig, amíg használni nem kezdjük ezt az információt adott körülmények között. Ha az átlagos teszteset-írási időt kiszámoljuk, ami 20 perc, akkor már egy használható KPI-t kapunk. A napindító megbeszélésen kiderül, hogy szükségünk lesz 9 új tesztesetre a délben kezdődő futtatásnál, akkor tudjuk, hogy az átlagban 180 percet vesz igénybe. Tehát dönthetünk úgy, hogy egy tesztelőre rábízzuk, mert valószínűleg délre kész lesz vele, vagy mehetünk a biztosabb irányba és 2-3 tesztelőnek adjuk a feladatot, akik ideális esetben egy óra alatt végeznek vele, de még akkor is bízhatunk benne, hogy délre elkészülnek, ha a feladat nehezebb az átlagosnál.

A szoftvertesztelésben például az alábbi tevékenységeket, eseményeket mérhetjük és számszerűsíthetjük:

1. Követelmények száma: ez a fejlesztéssel szemben támasztott összes követelmény „mennyisége”.
2. Tesztelt követelmények száma: azon követelmények darabszáma, amiken legalább egy teszteset futott.
3. Lefuttatott tesztesetek száma: a legalább egyszer végrehajtott tesztesetek száma.
4. Tervezett tesztek száma: megírt, de nem futtatott és nem felülvizsgált (nem review-zott) tesztesetek száma.
5. Felülvizsgált tesztesetek száma: felülvizsgált (review-zott), de nem futtatott tesztesetek száma.
6. Sikeres tesztek száma: sikeresen végrehajtott (megírt, felülvizsgált) tesztesetek száma.
7. Sikertelen tesztek száma: végrehajtott, de hibára futott (megírt, felülvizsgált) tesztesetek száma.
8. Blokkolt tesztesetek száma: projektszintű, vagy technikai okból (még) le nem futtatható (megírt, felülvizsgált) tesztesetek száma
9. Teljes teszttervezési idő: a tesztesetek megtervezésének és megírásának teljes ideje.
10. Teljes tesztvégrehajtási idő: a tényleges tesztvégrehajtási időt jelenti.
11. A talált hibák száma: a tesztelők által megtalált hibák teljes számát jelenti
12. Az elfogadott (accepted) hibák száma: azon hibák száma, amelyeket a fejlesztők, vagy a projektmenedzserek találtak, függetlenül attól, hogy validálták-e vagy nem.
13. Elutasított hibák száma: az észlelt, de nem érvényesített (validált) hibák száma.
14. Az elhalasztott hibák száma: az iterációs fázisban (prioritás, kritikusság vagy stratégiai okok miatt) nem javítandó hibák.
15. A megoldott hibák száma: az adott iterációban megoldott hibák számát mutatja. Ennek diagramon való összevetése az összes megtalált hibaszámmal megmutatja a hibajavítás arányát.
16. Teljes hibaelhárítási idő: a hiba megtalálása és a javítása közötti idő.
17. Az átadás után talált hibák száma: a fejlesztés során a hibák megtalálása kritikus jelentőségű.

Az egyes mutatók értéke attól a szoftverfejlesztési fázistól függ, amelyben az eredményeket vizsgáljuk.

Nagyon fontos meghatározni a teszteléshez:

• a projekt igényeit,
• a szoftvertesztelési metrikák céljait,
• a megfelelő tesztelési metrikákat,
• azt, hogy metrikák kinek készülnek (ki fogja olvasni és mire fogja használni).

A fentieket figyelembe véve nézzünk néhány példát arról, hogy milyen KPI-okat vezethetünk be:

• monitorozás és teszthatékonyság,
• teszt erőforrás kampányonként,
• tesztlefedettség,
• tesztköltség.

Mit is jelentenek ezek?

Maga a KPI tulajdonképp a fent említett metrikák kontextusba helyezése, amivel már viszonyítani, számolni tudunk, és amiből a következtetéseket le tudjuk vonni. Nézzünk egy példát: megmértük, hogy 10 teszt bukott, ami lehet jó, rossz és katasztrofális eredmény is. Ha például 12 tesztből bukott 10 az komoly baj, ha 1500 tesztből, akkor az szép eredmény (is) lehet. Ugyanannyira nem mérvadó a 10 teszt bukása, mint amikor egy futó 2 másodperccel veri meg az ellenfelét. Maratonnál szinte ugyanakkor értek be, míg 100 méteren hatalmas győzelem. A teszteknél KPI-ként már azzal számolunk, hogy az összes teszt és a bukott tesztek arányát figyeljük meg. A 10 és 1500 tesztnél ugyanaz a bukásszám 83,33% és 0,66% közötti bukási arány. Itt mutatkozik meg, hogy a KPI mennyivel jobban kifejezi az adott helyzetet.

A kontextust tovább árnyalja, hogy nem mindegy, hogy az előző iterációban, vagy verzióban mi volt az arány. Ha korábban léteztek a mostani hibák is, és mellé még egy tucat másik, akkor haladnak a javítások. De amennyiben az előző verzióban csak 2 hiba volt, akkor romlott a szoftver állapota.

Ha még egy gondolattal továbbmegyünk, mégpedig a KPI-ok kapcsolatára, megláthatjuk, hogy a KPI-ok együttes használata, megfelelő kombinációja fogja a képet igazán teljessé tenni. Maradjunk a fenti példánál és az 1500 futtatott tesztnél. Önmagában jelentéktelennek tűnik a hibaarány. Egy online piactér esetében például, ha a 10 bukott teszt között azok vannak, amikkel a megrendelés véglegesítését, vagy a termék kosárba helyezést, megrendelés beküldését, adatok beérkezését, vagy a fizetést ellenőrzik, akkor máris a katasztrofális szoftver állapotnál találjuk magunkat. Így, ha a sikertelen tesztek aránya mellett a kritikus hibák arányát is vizsgáljuk, máris látjuk a baj méretét. Ha figyelembe vesszük a hibajavítás idejét, a határidőt stb. el tudjuk dönteni, hogy mivel orvosolható a helyzet.

Monitorozás és teszthatékonysági metrika

Ezen a metrikán belül számos dolgot tudunk vizsgálni, különböző céllal. Nézzünk példákat erre:

1. Sikeresen lefutott tesztek aránya
   Célja: ellenőrizni, hogy a lefutott tesztek milyen arányban sikeresek.
   Azáltal, hogy összehasonlítjuk a különböző szoftververziók (pl. kiadások, fejlesztési fázisok) sikeresen lefutott tesztjeinek arányát, össze tudjuk hasonlítani a verziók minőségét. Látni fogjuk, hogy melyik mennyire felel meg a követelményeknek. Minél magasabb a mutató, annál jobb a minőség.
2. Sikertelen tesztek aránya
   Célja: megmutatni a termékhibaarányt.
   A sikertelen tesztesetek százalékos aránya segít annak eldöntésében, hogy a szoftver kiadható, szállítható-e. A magas arány komoly minőségi problémákat jelezhet. Az alacsony hibaarány viszont elengedhetetlen a vállalkozások számára az ügyfelek elégedettségének biztosításához. Ezzel minimalizálhatják a hibák miatt kiesett bevételt.
   Gyakorlati példa rá a fent kifejtett értékesítő oldal, melynél minden nagyobb hiba egy az egyben bevételkiesést tud okozni. Ezt a metrikát a Kritikus hibák arányával együtt érdemes használni, ahogy a korábbi példánál is láttuk.
3. Blokkolt tesztek aránya
   Célja: jelezni, hogy a tesztelés mennyire megy zökkenőmentesen, ellenőrizni, hogy az infrastruktúra ezt mennyre teszi lehetővé, valamint megmutatni, hogy a szoftver az alapvető működési elvárásoknak megfelel-e.
   Ez egy olyan mérőszám, amelyet azon tesztesetek százalékos arányának mérésére használnak, amelyeket valamilyen akadály, például hiányzó előfeltételek, a tesztkörnyezet vagy a szükséges tesztadatok elérhetetlensége ill. a tesztelt rendszer hibája miatt nem lehet végrehajtani.
   Tipikus eset szokott lenni, amikor nem elérhető a szerver, vagy egy részfejlesztés nem készült el az adott buildre, elromlott egy funkció, ami korábban már működött, és rá épülne az ellenőrzés. Például nem írjuk ki a terméknél, hogy mennyi van raktáron, mivel nem tudjuk lekérdezni, akkor a mennyiségre, érték megjelenésére, színére vonatkozó tesztek nem tudnak lefutni.
4. Megjavított hibák aránya
   Célja: a szoftver fejlődését, javulását mérni.
   Ez a mérőszám a szoftverfejlesztő csapat hatékonyságának mérésére szolgál abban a tekintetben, hogy a tesztelés során talált hibák mekkora részét tudták már megoldani. A javított hibák alacsony százalékos aránya azt jelzi, hogy a projekt megvalósítása késhet.
   Megjegyzés: A rögzített hibák százalékos arányát gyakran használják más szoftverfejlesztési mérőszámokkal, például a hibasűrűséggel és a hibahátralékkal együtt, hogy átfogóbb képet adjon a fejlesztési folyamatról, és azonosítsa a fejlesztendő területeket.
5. Az elhalasztott hibák aránya
   Célja: segít megérteni a minőségbiztosítás menedzsment folyamatainak hatékonyságát is.
   Az elhalasztott hibák százalékos aránya azokat a hibákat vizsgálja, amelyeket egy adott időkereten, pl. sprinten, vagy kiadási cikluson belül halasztottak el (nem lesz rá lehetőség, hogy megjavítsák). Az elhalasztott hibák magas aránya azt jelezheti, hogy a fejlesztési vagy tesztelési folyamat javítására van szükség, vagy hiányoznak az erőforrások az összes azonosított probléma adott időkereten belüli megoldásához.
   Maradva az online kereskedelemnél, az egyes kijelzőkön elcsúszott gombfelirat javítása későbbre halasztható, ha épp a megrendelésleadás sikertelenségét okozó hibán dolgozik a csapat, vagy ha el kell készülni egy olyan modullal, ami miatt a raktárkészlet megfelelően fog látszani.
6. Kritikus hibák aránya
   Célja: a megtalált hibák súlyosságát, illetve a súlyos hibák arányát mérik vele
   Ez a mérőszám akkor hasznos, amikor a kritikus hibák számának csökkentésére fókuszálnak a kiadást megelőzően. Erre jó példa a fent említett online piactérnél talált megrendelést gátló súlyos hibák aránya a többi hibáéval szemben.
7. Hibafeloldási/hibakezelési idő
   Célja: megmérni a jelentett hibák, vagy problémák megoldásának idejét.
   A magas átlagos hibafeloldási idő azt jelezheti, hogy a csapat küzd a hibák időben történő kijavításával, ami késedelmet okozhat a szoftverkiadásokban, és potenciálisan kihathat az ügyfelek elégedettségére, ha a hibák élesben is kint vannak.
   Érdemes megjegyezni, hogy ez a mutató nem lehet a fejlesztőcsapat teljesítményének egyetlen mérőszáma. Más szoftvertesztelési-mérőszámokat, például a jelentett hibák számát, a hibák súlyosságát és a vevői elégedettségi értékeléseket szintén figyelembe kell venni, hogy átfogóbb képet kapjunk a csapat hatékonyságáról.
   Emellett a management felől jövő prioritási igények, kérések, egyéb feladatok, más fejlesztési területek kiemelése stb. erősen befolyásolhatják az adott időszakban a hibák javításának lehetőségét.

Ahogy az ábrán is látszik, a hiba megtalálása és a javítás kezdete között eltelt idő, valamint a javítás és a tesztelés közötti idő is nagyban hozzájárul a feloldási idő tartamához. Ezek az időszakok lehetnek a folyamat részei, pl. adott ceremóniára, megbeszélésre, sprint fordulóra, döntésre (döntéshozóra) való várakozás, vagy eldöntött prioritási kérdés, erőforrásra való várakozás, vagy egyszerű rossz kommunikációból, hibás folyamatokból adódó késlekedés, de mindenképp növelik a feloldási időt. Ha hosszú a feloldási idő, akkor érdemes a folyamatok részleteit megvizsgálni, hogy kiderüljön mi okozta a lassúságot.

Tesztelési erőfeszítés kampányonként

1. Tesztvégrehajtás hatékonysága
   Célja: betekintést nyújt a tesztelési folyamat hatékonyságába. Megmutatja mennyi időt töltünk az egyes tesztesetek végrehajtásával. Segít optimalizálni a tesztelésre fordítható idő hatékony eltöltését.
   A TEE (Test Execution Efficiency) mérőszám magában foglalja azt az időt, amit arra való várakozással töltünk, hogy az erőforrások, (például adatbázisok vagy hálózati kapcsolatok) rendelkezésre álljanak. A magas TEE-érték azt jelzi, hogy a tesztelési folyamat hatékony, minimális idő- és erőforrásveszteséggel dolgozik, míg az alacsony TEE-érték olyan hiányosságokat jelezhet, amelyeket kezelni kell. Például túl sok tesztesetet kell végrehajtani, vagy a tesztelési környezet nincs megfelelően beállítva. Ezenkívül segíthet a tesztesetek rangsorolásában és az erőforrások megfelelő elosztásában. Valamint akkor is nagyon hasznos, mikor a csapatnak azt kell mérlegelni, hogy mit és hogyan érdemes automatizálni.
2. Teszttervezés hatékonysága
   Célja: betekintést nyújt abba, hogy mennyi időt fordítanak az egyes tesztesetek megtervezésére.
   A tervezési hatékonyság mérése hasznos az erőforrások elosztásának optimalizálásához. Ha tudja, mennyi időre van szükség egyetlen teszteset megtervezéséhez, jobban hozzárendelheti az erőforrásokat a teszttervezési folyamathoz. Például reális elvárásokat tud támasztani az érintettekkel szemben.
3. Teszt felülvizsgálat (review) hatékonysága
   Célja: Ellenőrizni, hogy a csapat, vagy a tesztelő milyen hatékonyan tudja ellenőrizni az elkészült teszteket.
   A felülvizsgálat hatékonysági mutatója segíthet a csapatoknak azonosítani azokat a területeket, ahol javítani kell a tesztelési folyamatukat, például egyszerűsíteni a felülvizsgálati eljárásokat, megtalálni a szűk keresztmetszeteket. Felfedezhetik például, hogy bizonyos típusú tesztek vizsgálata hosszabb időt vesz igénybe, aminek az optimalizálása csökkentheti a teljes tesztelési időt. A felülvizsgáló csapat összetételét, a munka felosztását változtatva, plusz képzéseket tartva, a többiek munkájának jobb megismertetése által segíthetünk a hatékonyság növelésében.
4. Tesztelési időre vonatkozó megtalált hibaarány
   Célja: a tesztelési folyamat általános hatékonyságát méri, mivel megmutatja, hogy adott idő alatt mennyi hibát találtunk meg. A tesztek végrehajtási idejével elosztjuk az összes megtalált hibák számát, és ezt szorozzuk százzal.
   Fontos megjegyezni, hogy ezt a mérőszámot más tesztelési mérőszámokkal, például a hibasűrűséggel vagy a tesztlefedettségével együtt kell használni, hogy teljesebb képet kapjunk a tesztelési folyamat menetéről.
   Ha szinte hibamentes a szoftver, ami szuper, akkor az adott hiba megtalálása sok időbe fog telni ill. soknak fog tűnni ez az idő, pedig a fejlesztés a legjobb úton halad, és a tesztelés is alapos. Tehát ez is egy olyan metrika, amit kontextusában kell értelmezni.
5. Tesztesetenkénti hibaszám
   Célja: becslést ad arra vonatkozóan, hogy átlagosan hány hibát találtak teszteset-végrehajtásonként.
   Érdemes megjegyezni, hogy ennek a mutatónak a pontosságát olyan tényezők befolyásolhatják, mint a tesztesetek minősége (hossza), a tesztelt szoftver összetettsége és a tesztelő csapat szakértelme. Ezért fontos, hogy az eredményeket az adott tesztelési környezet összefüggésében értelmezzük, és ezt a mérőszámot más tesztmérőkkel együtt használjuk, hogy átfogó képet kapjunk a tesztelési folyamat hatékonyságáról.
6. Átlagos hibafeloldási idő
   Célja: a szoftverhiba megoldásához szükséges átlagos időt mérni az azonosítástól a sikeres javításig.
   A teljes hibafeloldási idő az egyes hibák kijavításához szükséges idők összessége. Ha ezt elosztjuk a tesztelési folyamat során javított hibák teljes számával, megkapjuk az átlagos hibafeloldási időt.
   A kiszámításával a tesztelő csapatok nyomon követhetik a hibajavítás előrehaladását. Az alacsonyabb érték azt jelzi, hogy a hibákat gyorsan kijavítják, ami javíthatja a szoftver minőségét és csökkentheti a teljes tesztelési időt. Másrészt a vártnál hosszabb ideig tartó magas átlagos hibafeloldási idő a szoftverfejlesztési folyamat problémáira vagy akár további erőforrások vagy szakértelem szükségességére utalhat.
7. Automatizált tesztek aránya
   Célja: automata és manuális tesztek egyensúlyának ellenőrzése, nyomon követése.
   Az összes teszteset és az automatizáltak arányát azért fontos ismernünk, mert az automatizált tesztesetek gyorsabbak, kevesebb emberi erőforrást igényelnek és megkönnyítik az ismétlődő tesztelési feladatok elvégzését, így erőforrást és pénzt takaríthatunk meg. Emellett a manuális tesztelés előnyeit akkor tudjuk kihasználni, ha megfelelő arányt tartunk fent a módszerek között, valamint megfelelő módszert választunk az adott ellenőrzésekre. Ebben pedig ez a metrika segíthet.

Tesztlefedettség

1. Követelménylefedettség
   Célja: annak ellenőrzése, hogy az összes követelmény legyen legalább egy tesztesettel lefedve

   Ennek a kulcsfontosságú teljesítménymutatónak a segítségével a csapat nyomon követheti a legalább egy teszteset által lefedett követelmények százalékos arányát. Ez a mérőszám segít értékelni a teszteset tervezésének funkcionális lefedettségét. A tesztmenedzser figyelje ezt a KPI-t, és határozza meg, mit kell tenni, ha a követelmények nincsenek lefedve legalább egy tesztesettel.

2. Tesztfuttatás előfeltételeinek lefedettsége
   Célja: megmutatja, hogy a szoftver funkcionalitásának mekkora része van tesztelhető állapotban.
   Segít abban, hogy képet kapjunk a végrehajtott tesztesetek teljes, valamint a függőben maradt tesztesetek számáról. A tesztmenedzser figyeli ezt a KPI-t, hogy biztosítsa a program fő funkcióinak lefedettségét.
   Tipikus példa, amikor külön csapatok fejlesztései érnek össze a szoftverben. Az egyik csapat elkészült azzal a modullal, ami a raktárkészletet ki tudja írni, így az aktuális érték megjelenik a termék mellett. Egy másik csapat dolgozik a termék megrendelés lemondásának visszavezetésén a raktárkészletbe, és még nincsenek készen. Ilyenkor azon tesztesetek amik a lemondás utáni készlet növekedést vizsgálják, azok nem futtathatóak, hiába van kész a készlet lekérése, hiszen mindenképpen hibára futnának.
3. Adott követelmény teljesülése
   Célja: megmutatni, hogy a termék készen van-e a kiadásra.
   Ha egy kritikus követelmény még nem lett tesztelve, vagy nem felel meg a tesztelésen, a kiadást el kell halasztani.
   Például, ha nem vagyunk benne biztosak, hogy az átutalás megérkezett, vagy hogy jó összegről állt ki a számla, akkor a terméket nem csomagolhatják és adhatják oda a vevőnek. Ilyen esetben az alkalmazás sem kiadható, nem kezdhetik el használni a vásárlók.
4. Le nem fedett követelmények
   Célja: ellenőrzi, hogy ne hagyjunk ki semmi fontosat.
   Ennek a KPI-nek az a célja, hogy megbizonyosodjon arról, hogy a tesztelés során használt funkciókat a minőségbiztosítási csapat nem hagyja ki.

Metrikák használata

Nagyon fontos, hogy ezeket a metrikákat okosan használjuk tesztelésben és a teljes fejlesztésben egyaránt. Ahogy korábban írtam, egy-egy mutató önmagában téves következtetésekre juttathat minket. A KPI-ok ennél alapvetően árnyaltabb képet adnak, viszont ezeket is könnyű rosszul használni, vagy értelmezni. Pl. egy fejlesztés alatt álló komplex szoftverbe bekerül több, óriási fejlesztés, ami az integrációk miatt számos új hibát eredményez Látszólag a szoftver drasztikusan rosszabb, de az új feature-ökre bontva már láthatjuk, hogy a helyzet kezelhető. Vagy jelentheti éppen az ellenkezőjét is: le kell időlegesen állítani az új fejlesztések bekerülését, és rendbe kell tenni az aktuális állapotot, mivel arra alapozni túl sok bajjal és későbbi javítással járna.

Ha jó döntéseket akarunk hozni, egyfelől alaposnak kell lennünk a metrikák kiválasztásában, másfelöl jól kell következtetnünk, harmadrészt pedig nem csak a számokat kell figyelnünk. Ebben is segítenek a jól kiválasztott tesztmenedzser eszközök.

Forrás:

https://testomat.io/blog/key-software-testing-metrics-kpis/

https://www.investopedia.com/terms/k/kpi.asp

https://kms-technology.com/testing/the-8-most-important-kpis-for-software-quality-assurance.html