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.

Teszt kör - PDCA

A PDCA elv alkalmazása a tesztelésben

Dr. W. Edwards Deming munkásságából merítvén, kísérletet szeretnék tenni arra, hogy az általa híressé tett PDCA elvet a programozók és tesztelők közötti munka ütemezésére, egymás megértésére alkalmazzuk.

A klasszikus út

Örök probléma, hogy mikor, milyen tartalommal, milyen céllal érkezik a tesztelésre a fejlesztés alatt álló alkalmazás új buildje; folyamatos a késés, állandóan előfordulnak jelentős, utolsó pillanatban a buildbe tett módosítások.

A teszt csapat meg ilyenkor áll, néz, hogy mi történt. Felkészülni, teszteseteket frissíteni, teszt futtatásokat ütemezni jellemzően már nincs idő. A helyzetet nem egyszer nehezebbé teszi ha az adott build “release candidate” állapotban érkezik, tehát még a teszteléshez alapvetően nem értő termékgazda / projektmenedzser is a tesztcsapat sarkában lohol, követelvén a mielőbbi kibocsátást.

Egy-két ehhez hasonló szituáció - és átvirrasztott éjszaka - nyomán kezdtem el keresni valami egyszerű, kézzelfogható, megvédhető megközelítést a fenti helyzet megismétlődésének elkerülése érdekében.

Deming PDCA elve egyszerűen átlátható, minden oldal által megérthető megoldási javaslatot nyújtott.

Alábbiakban nézzük át hogyan is lehetne a PDCA elvet alkalmazni főként a programozás és a tesztelés kapcsolatában:

PLAN

A programozók feladata az új build tartalmának meghatározása, beleértve a hiba javítási, új fejlesztési feladatokat is. Az ütemezési kérdések tisztázása a projektvezető aktív részvételével. Egyeztetés a dokumentáció írásért felelőssel. A build tartalmának publikálása egy a projekt összes részvevője által elérhető helyen (erre leginkább a hibajegy-, feladatkövető rendszerek alkalmasak, ahol fel kell állítani egy közös, globális szűrő feltételt, amelynek használatával mindenki "ugyanazon az oldalon" van)

A tesztelők feladata a közös területen elérhető tervezett build tartalom alapján, bárhol és bármilyen struktúrában is található, a teszteset “vagyon” frissítendő részének azonosítása; egyeztetés a programozói oldallal, a tervezett funkciók minél szélesebb körű megértése. Nagyon fontos, hogy a tapasztaltaktól eltérően, mindenképp kell, hogy legyen a tesztcsapatban erre szabad kolléga, aki nem az előző build elhúzódó tesztelésén dolgozik. Teszteset frissítés alatt jobb esetben az automatizált tesztek frissítését is érteni kell.

Projektvezetési kérdés, hogy a PLAN fázisnak mikor van vége, illetve van-e egyáltalán definiált vége. Tesztelői szempontból erőteljesen javasolt, hogy legyen.

DO

A programozók feladata a build tervben meghatározott feladatok kivitelezése, hibajavítás, új funkciók fejlesztése. Kisebb mértékben, egyeztetve a teszteléssel, projekt vezetéssel a build tartalom változása is elképzelhető.

A tesztelőknek fel kell készülniük az új build tesztelésére: a meghatározott teszteset frissítési feladatok kivitelezésére, a tesztkörnyezet felállítására és a teszt futtatás ütemezésére.

A projektvezetőnek lehetőség szerint ezt az időszakot minél zártabbnak kell kezelnie, és meg kell védenie a csoportot az utolsó pillanatos módosításoktól.

CHECK

A programozók az elkészült fejlesztési munkákat ellenőrzik, a unit teszt, code review stb. után buildbe fordítják, majd átadják a tesztelésnek.

A tesztelők az előre elkészített teszt környezeten, frissített teszteseteket futtatnak az alkalmazás új buildjén. Hibajegyeket rögzítenek, kommunikálnak a programozókkal a legjobb közös megértés érdekében.

ACT

A programozók a projektvezetéssel közösen priorizálják a talált hibajegyeket, a fontosnak, javítandónak talált jegyeket javítják.

A projektvezető a projekt helyzete és a hibajegyek milyensége alapján dönt a javító build gyors összeállításáról, vagy a következő standard build ütemezésének megkezdéséről.

A tesztelők az esetleges javító build tesztelését végzik. A teszt futtatás során talált teszteset hibákat javítják, belső folyamatokat vizsgálnak, javítanak. Szükség szerint együttműködnek a programozókkal a hibajegyek megfelelő reprodukálása, javítása érdekében.

Az agilis világ

A fentiek talán kicsit követhetőbbé, élhetőbbé teszik a tesztelők mindennapi munkáját egy klasszikus felfogású szervezetben. A 10 éve zászlót bontott agilis szoftverfejlesztési megközelítés a fenti elveket gyúrja össze. A programozók, tesztelők együtt fejlesztik a terméket, nincs lényegi időbeni különbség a teszt tervezés, program tervezés, a kódolás és a teszt eset írás között; az iteráció alatt a scrum master feladata a csoport megvédése a jelentős változtatásoktól. Dinamikus, határok, átadás átvételi pontok (és akár rögzített hibajegyek) nélküli, minden nap érvényesülő PDCA szerinti munkavégzés jellemzi az agilis projektet.

--
Ezen bejegyzés a Tesztelés a gyakorlatban magazin 2011-2 számában is olvasható.