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?
- Megfelelő minőség növekedést hozza?
- Nincsenek ismert kritikus hibák?
- A minőség növekedés felülmúlja az ismert nem kritikus hibákat?
- 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.
- Kritikus területek (a hibák költsége és következménye magas)
- Látható területek (a hibák a legtöbb felhasználó számára észlelhető)
- 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.
- Komplex területek
- Sokszor változtatott területek
- Még nem kipróbált módszerek, technológiák
- Fejlesztésbe bevont emberek
- Időnyomás
- Hiba történet
- 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.