Tesztelési szintek

A tesztelési szintek

A tesztelők elfogadási tesztek alatt egyes funkciókat tesztelnek?

Rendszerteszt során, unit tesztek hibáival találkoztál?

Arról van szó, hogy a kezdő tesztelő nagyon könnyen eltéveszti a célt. Merre is megyünk, mi a célja az útnak, és milyen eszközöket tudunk felhasználni – kérdések, amelyekre az adott válaszok meghatározzák a tesztelési szintet, amely szerint kellene tesztet tervezni és végrehajtani.

Főszabályként kell elfogadnunk, hogy annyi tesztelési szintet kell definiálni, ahány logikai szinten dolgozik a projektet jellemző programozói gárda. 

Miért fontos ez? 

Minden egyes szinten, a tesztelő lehetőséget kap arra, hogy ellenőrizze az elkészült részterméket, ezzel együtt a termékfejlesztés egésze kapja meg azt a lehetőséget, hogy kevesebb örökölt hiba jusson egyre feljebb, ezáltal könnyebben, gyorsabban és olcsóbban történhet meg az adott szinten belül a hiba kijavítása. 

Lehetőség szerint a jónak látott, de hiányzó szinteket próbáljuk meg erőltetni, lehet hogy hanyagságból hiányzik a programozói oldalon.

Az alábbiakban részletezett tesztelői szintek egymással párhuzamosan is előfordulhatnak egy projekt életében.

Unit teszt
A fejlesztés alatt álló alkalmazás egységeinek tesztelése zajlik itt. Célja, hogy biztonságos alapot nyújtson a felépítmény létrehozásához. Könnyedén automatizálható.


Ebben a szintben a feladat: unit teszt esetek generálása, írása, módosítása, futtatása, majd a futtatás során talált eltérések elemése, hibajavítás. Általában nincs a teszt csapatban a unit teszt létrehozásához megfelelő tudás. Ekkor a teszt vezető feladata az, hogy ellenőrizze a unit tesztek meglétét, illetve amennyiben lehetséges, a tesztelő tapasztalatával támogassa a programozót a unit teszt megírásában (“nem elégséges a pozitív utak ellenőrzése”). Használt nyelv a programozási környezetnek megfelelő unit tester eszköz. A teszt esetek tárolása célszerűleg a szoftver kód tárolásával egy helyen (*).


Modul (integrációs) teszt
Az alkalmazás egyes részei modul készenléti állapotba kerül(het)nek, amikor is, a tesztelő feladata, hogy a modullá integrált kódelemeket tesztelje. Itt a programozási nyelvet ismerő tesztelők vannak előnyben, miszerint még nincs sehol GUI, ahol a hagyományos értelemben vett teszt elindulhatna. A programozási környezet, a forráskód, és az architektúra ismerete birtokában a tesztelő saját kódjával, elképzelései szerint teszteli a modulokat. Mike Cohn könyvében olvastam (http://www.succeedingwithagile.com/), hogy ez a szint a legjobban automatizálható része a tesztelésnek. Gondoljuk csak meg, itt még nincs az örökké változó GUI, amelyen egy üzleti funkció végrehajtásához akár több modult is automatizálni kell. Itt csak, és kizárólag az adott modul működésére lehet koncentrálni, és elég csak egyszer foglalkozni vele.
Ezen felül, igény szerint a modulok együttműködésével is kell foglalkozni ebben a szintben. Itt a szükséges tudás az egyes modulok interface definiciója és elvárt működése. A tesztelő, ha az alkalmazás felépítése megengedi, akár parancssoros állományok segítségével érheti el célját.
A használt nyelv, jellemzőleg magasabb szintű automatizálás vagy parancssoros utasítások. Tárolás lehetőleg a szoftverkóddal egy helyen (*).


Rendszerteszt
Az alkalmazáson (ha van) akkor már megjelent a GUI, részben elérhető funkciókkal. A tesztelők megfelelő dokumentációs forrás felhasználásával teszt eseteket írnak, ütemeznek, majd futtatnak.
A tesztelési szint célja: a feltételezett, jobb esetben leírt specifikációnak megfelelő működés vizsgálata. Nyelvezete általában egyszerű szöveges, a rendszerre jellemző utasítások halmaza, amit egy kivűlálló akár nem is ért meg. Jellemző a teszt automatizálás illetve a kulcsszavas tesztelés (melyről majd egy másik cikkben).
Több, kiegészítő része lehet a szintnek: biztonsági tesztelés, terheléses tesztelés, stressz tesztelés.
A teszt esetek tárolása amennyiben megoldható, akkor a forráskód tároloó eszközök még mindíg javasolt (*), amennyiben nem, akkor egy a célnak megfelelő eszköz, wiki, stb.


Elfogadási teszt
A szint célja, hogy a végfelhasználót támogassa az új (általunk) szállított termék elfogadásában. Megírása és elfogadása optimális esetben közös, megrendelői – szállítói, feladat. Nyelvezete hétköznapi, a témához értők által értelezhető, végrehajtandó mondatok egésze. Tárolás: az üzleti felhasználók által könnyedén elérhető, de lehetőség szerint verziózott dokumentációs rendszerben.




Javaslom, hogy akár a fentiek felhasználásával, tesztelési szinteket definiáljatok, ahol a cél, az eszköz – nyelvezet, kivitelezés és az ellenőrzés, rövid, írásos megfogalmazásával mind a tesztelőket, mind a projekt többi részvevőjét segítitek.