Megbízható mérések a tesztlefedettségben

Ahhoz, hogy hiteles információt kapjunk a rendszer működéséről, minőségéről mérnünk kell. Hogyan lehet mérni egy rendszer minőségét? Milyen mérésekkel tudjuk alátámasztani a tesztelői munkákat? Mit is takar pontosan a lefedettség?

Amikor tapasztalt projekt vezetőkkel és termék felelősökkel beszélek, azért akarnak – különösen, akkor ha a jelenlegi minőség nem megfelelő – bevonni tesztcsapatot a rendszer- és integrációs tesztekbe, hogy megerősítsék a rendszerbe vetett bizalmukat. A másik fontos előnye a tesztcsapat bevonásának, hogy a vezető a rendszer minőségéről rendszeres, hiteles információt kap, így folyamatosan ellenőrizheti a rendszerbe vetett bizalmi szintjét is. Sok tesztelő számára a bizalmi szint lejelentése a rendszer minőségéről gyakran nehéznek bizonyul. Néhányan a tesztelők közül a bizalmi jelentéseket rossz érzéssel teszik meg. A főbb funkcionális területek mellé mosolygós és homlokráncoló smiley-kat rajzolnak, mintha azt mondanák, „Nagyon rossz előérzetem van az XYZ funkcióval kapcsolatban”. Ha a vezetés úgy dönt, kiadja a terméket mindenképp, a szerencsétlen tesztelők akár szenvedhetnek is Cassandra átkától, ha az a bizonyos XYZ funkció tényleg megbukik az éles rendszeren. A másik lehetőség, hogy a tesztelők hitelessége elillan, ha az áll a jelentésben hogy nincsenek problémák az XYZ funkcióval.

Lefedettségek

Ha párszor ilyen módon ér kellemetlen élmény, valószínűleg elgondolkozol azon, hogy milyen más lehetőségeid v annak. A következő 500 szót olvasva biztosan találsz egy jobb utat. Ez a lehetőség a széleskörű lefedettségi mutatók használata. Nem mindegyik lefedettségi típus használható minden rendszernél, ezért neked kell döntened a következők közül:

• Kockázati lefedettség: Egy vagy több teszt (függ a kockázat szintjétől) minden egyes minőségi kockázatú tétel azonosítására. Amikor a kockázatot teszteled, abban bízol, hogy a minőség szintje elfogadható lesz. A sikeres tesztek és a kockázatok százalékos aránya méri a kockázat szintjét.
• Követelmény lefedettség: Egy vagy több teszt minden egyes követelmény specifikáció elemre. Amikor teszteled a követelményeket, bíznod kell abban, hogy a rendszer „megfelel a specifikációban meghatározott követelményeknek ” (hogy Crosby minőségi meghatározásával éljek). A követelmények és a sikeres tesztek százalékos arányát méri. Megadja, hogy milyen mértékben felel meg a rendszer az elvárásoknak.
• Tervezés lefedettség: Egy vagy több teszt minden egyes tervdokumentációs elemre. Amikor a terveket teszteled, abban bízol, hogy a terv megfelelő lesz. A tervezett elemek és a sikeres tesztek aránya adja a tervezés megfelelőségét.
• Környezet lefedettség: Megfelelő környezet érzékeny tesztek futnak minden támogatott környezetben. Ha a támogatott környezetben tesztelsz, abban bízol, hogy a rendszer „megfelelő a használatra” (hogy Juran minőségi definíciójával éljek). A környezetek és a sikeresen tesztelt környezetek százalékos aránya méri a környezet támogatást.
• Használati esetek (use case), felhasználói profil és/vagy felhasználói történetek (user story) lefedettség: Ha úgy teszteled a rendszert, ahogy egy felhasználó használná, ismét csak abban reménykedhetsz, hogy a rendszer „készen áll a használatra”. A használati esetek, felhasználói profilok és/vagy felhasználói történetek a sikeres tesztekkel való százalékos arányát méri, vagyis a rendszer felhasználóbarátságát.

Figyeljük meg, „sikeres tesztek”-ről beszéltem a mérőszámaim mellett. Ha a kapcsolódó tesztek elbuknak, akkor bízhatunk abban, hogy a rendszer egészének ismeretében értelmesen le tudod írni a problémákat az adott dimenzióban függetlenül attól, hogy az érintettek nem ismerik behatóan a rendszert. Ahelyett, hogy „rossz megérzésekről” beszélünk, vagy homlokráncoló smiley-kat rajzolunk egy digitális táblára, beszélhetnénk pontosan arról, hogy mutatták ki a tesztek az iszonyatos kockázatot, kielégítetlen követelményeket, hibás terveket, működésképtelen környezeteket, és beteljesületlen használati eseteket.

Mi a helyzet a kód lefedettséggel?

A kód lefedettség méri, hogy milyen mértékben vannak tesztelve az utasítások, elágazások és ciklusok. Csökkentett bizalommal álljunk hozzá azokhoz a részekhez, ahol nincsenek letesztelve az utasítások, elágazások és ciklusok. Minden olyan kód, ami lefedetlen, az minőségi szempontból is méretlennek tekintendő.

Egy tesztcsapat vezetőnek hasznos gyakorlat, hogy a csapat tesztjeinek kódlefedettségét mérje. Ezzel a módszerrel azonosítani tudjuk a fontos réseket a tesztelésünkben. Én és rajtam kívül sok más teszt szakember alkalmazza ezt a módját a kódlefedettségnek már több mint 20 éve. A rendszer teszt- és rendszer integrációs teszt szinteken, a kódlefedettség hasznos taktika a tesztelési hiányosságok megtalálására, de kifejezetten hátrányos lehet a bizalomépítésben.

A másik hozadéka a lefedettség mérésnek, hogy hasznos stratégiákat nyújt a minőségbeli bizalom felépítésében és a teszt eredmények értelmezésében. Tapasztalt teszt mérnökként és tesztelemzőkként, meg kell terveznünk a teszteket és futtatnunk kell őket a megfelelő lefedettségi síkokon. Tapasztalt szakmai vezetőként a teszteredményeinknek ki kell mutatniuk, mennyire alaposan foglalkoztunk minden egyes lefedettségi területtel. A tesztcsapatok, amelyek megbízhatóan teljesítenek mind hitelességet és jelentőségteljességet fejeznek ki a teszteredményeikben és ezáltal a rendszer minőségében is.

Szerző: Rex Black