FreiMind 
Frei Dávid QA tesztmérnök

FreiMind 
Frei Dávid QA tesztmérnök

Tesztelés kockázat alapon

2021.01.04. 20:58

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.