Tesztelés kockázat alapon

A kockázat alapú tesztelés megoldást nyújthat a projektek legkritikusabb tesztelési kihívásaira, mint a hiányos tesztelési követelmények, a sorozatos csúszások miatti beszűkült tesztelés, a tesztek mértékének tudatos meghatározásának problémája. A továbbiakban ennek mikéntjéről fogok mesélni.

A 2017-es év első Teszt & Tea meetup-ján lehetőség nyílik 4 hazai előadást hallgatni a kockázat alapú tesztelés alkalmazásáról. Az esemény ingyenes, jelentkezni a www.meetup.com/teszt-tea oldalon tudtok (Teszt & Tea Budapest, Február 1, 17:00).

A téma kapcsán elsőre Erik Van Veenendaal remekül összeszedett kézikönyve jut eszembe magyar fordításban Praktikus Kockázat Alapú Tesztelés néven. 

A fejlesztési projektek előrehaladtával a korábbi szakaszok csúszása miatt a tesztelést gyakran nyomás alatt kell elvégezni. Erre a kihívásra - hacsak nincs megfelelően felépített automatizált tesztelési keretrendszerünk - egy jól összeszedett "differenciált" tesztelési stratégia bevezetése a megoldás, amely során definiáljuk miként hozhatunk ki a legtöbbet a tesztelésből a rendelkezésünkre álló időn belül. Tehát mit milyen mértékben teszteljünk?

A tesztelés alacsony, kód szintű végrehajtásától kezdve egészen a legmagasabb szintű elfogadási tesztig meg kéne tudnunk határozni melyek a legfontosabb és leginkább hibára hajlamos részei a tesztelt rendszerünknek és ez alapján definiálni a tesztelés mélységét, mennyiségét.

Ugorjunk is az elméletről a gyakorlatba...

A rendszerünk fejlesztése közepén járunk és sorra jönnek ki az újabb és újabb release-ek, azaz javítások és új fejlesztések egyaránt. A komplexitás növekedésével egyre nehezebb jó döntést hozni a release kiadásakor. Vajon „elég jó” a rendszerünk, hogy kiadjuk?

1. Megfelelő minőség növekedést hozza?
2. Nincsenek ismert kritikus hibák?
3. A minőség növekedés felülmúlja az ismert nem kritikus hibákat?
4. Jelen helyzetben mindent figyelembe véve több gondot okozna, mint nyereséget eltolni a kiadást, hogy javítsunk a minőségen?

Röviden ha ezekre a kérdésekre Igen a válasz, akkor kiadható az új release. Az első 2-re a hagyományos tesztelési riportokból, illetve a hibajegyekből egyértelmű választ tudunk kapni.

A 3. pontban azt kell bebizonyítanunk, hogy a tesztelés megfelelő bizonyítékot ad-e a kritikus kockázatok kezelésére és a minőség növekedésére. Ezt a bizonyítékot akarjuk szolgáltatni, méghozzá nem ritkán a szükségesnél jóval kevesebb erőforrással is időn belül.

Az alábbi 2 dimenzió szerint határozd meg mit tesztelj intenzívebben és mit kevésbé.

1)    Mérd fel mik üzletileg a legfontosabb részei a rendszerednek.

1. Kritikus területek (a hibák költsége és következménye magas)
2. Látható területek (a hibák a legtöbb felhasználó számára észlelhető)
3. Leginkább használt területek (a hibák a mindennapi folyamatokat gátolják)

​

2)    Mérd fel azon területeket, amelyek technikailag a leginkább hibára hajlamosak.

1. Komplex területek
2. Sokszor változtatott területek
3. Még nem kipróbált módszerek, technológiák
4. Fejlesztésbe bevont emberek
5. Időnyomás
6. Hiba történet
7. Távolra kihelyezett fejlesztés

​

Fontos, hogy a felmérést minél többféle projekt résztvevő segítse. Fejlesztők, architektek, üzleti elemzők, tesztelők közösen tudják a legpontosabban meghatározni az egyes vizsgált területek kockázatának mértékét. A cél az, hogy különbséget tudj tenni az egyes területek, funkciók között a tesztelési stratégia szempontjából. Ne feledd, ha minden magas prioritású, akkor nincs prioritásod. Valamint egyszerre nem fogsz tudni 20-30 területnél többet egymáshoz hasonlítani. Kezd magas szinten, egyszerűbb felmérés segítségével és csak ha szükséges menj ennél mélyebbre.

És hogy mit jelent mindezek alapján egy differenciált tesztstratégia? Például ezt:

Minél nagyobb a kockázat mértéke, annál alaposabb tesztelést igényel.