A tesztelési szintek
A tesztelési folyamatban nagyon fontos, hogy megfelelő időben megfelelő teszteket futtassunk. Ahhoz hogy ne keveredjünk össze érdemes különböző szinteket definiálni. Mi a célja az adott tesztelésnek? Milyen szinteket alkalmazzunk a tesztelésben? Adott szinteken kik készítsék el és futtassák a teszteket?
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 tesztesetek generálása, írása, módosítása, futtatása, majd a futtatás során talált eltérések elemzése, hibajavítás. Általában nincs a tesztcsapatban a unit teszt létrehozásához megfelelő tudás. Ekkor a tesztvezető 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 tesztesetek 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 definíció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 teszteseteket í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 kívülálló akár nem is ért meg. Jellemző a tesztautomatizálás, illetve a kulcsszavas tesztelés (melyről majd egy másik cikkben írok).
Több, kiegészítő része lehet a szintnek: biztonsági tesztelés, terheléses tesztelés, stressztesztelés. A tesztesetek tárolása, amennyiben megoldható, akkor a forráskódtároló eszközök még mindig 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.
(*) A tesztesetek tárolásáról: amennyiben a megfelelő jelentések elkészíthetők egyéb, hozzáadott eszköz nélkül, akkor a tárolást jó lenne az alkalmazás kóddal együtt megoldani. Tapasztalatom szerint ebben a megközelítésben sokkalta nagyobb esély van arra, hogy ugyanolyan termékként tekintsenek a teszt.
Szerző: Schaffhauser Balázs
A szerző
- 2001-től teszt vezetőként, az Egroup-ban, az Avon Cosmetics-ben, a Lufthansa Systems-ben és a 3DHistech-ben volt lehetőségem tanulni, megismerni számos iparágat a tesztelés szemszögéből. Teszt csapatok felépítése, támogatása, eszkö- zök kiválasztása, bevezetése tartozott a feladataim köré. Jelenleg a Scrum módszertant tanulom, Scrum master-ként tevékenykedek.