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ó.

Hibakezelés

Szerintem rengeteg anyag van az interneten a hibakezelés fontosságáról, milyenségéről. Ezért most olyan dolgaimról írnék, amelyek nem annyira triviálisok, talán, azok, amelyek keserű tapasztalatok nyomán születtek meg.

A hibakezelés közös terület. Nem lehet ezt eléggé hangsúlyozni. Előfordul, hogy a rendszerszervező, programozó, tesztelő, ügyfél képviselője ugyanazt a rendszert használja. Ennek nyomán nem karbantartott rendszereknél megfelelő keveredés is megjelenik majd.

Az egyik régebbi helyemen megdöbbenve vettem észre, hogy minden egyéb értesítés nélkül egy angol menedzser egy fél éve lezárt hibajegyet újranyitott, csak annyi megjegyzéssel, hogy újra priorizálási megbeszélés volt, kérjük ellenőrizni.

A rendszer megengedte neki, és nem volt egyéb lehetősége arra, hogy teszt eset futtatást kérjen - ugye, a teszt eset és a hibajegynek van egy közös szakasza, a lépések, amelyeket végre kell hajtani. Node, a hibajegy egy bizonyos rendszer állapotra, kiadásra vontakozik, így ne engedjük azt később újranyitni, csak azért hogy hasonló lépés sort hajtassunk végre a tesztelővel egy akár teljesen új verziójú alkalmazáson.

Definiáljunk tehát felhasználói csoportokat. Akár minden egyes csoport mellé leírva, hogy milyen területről érkeztek a tagok, kik azok, és milyen feladatot hajtanak végre, milyen szerepkört testesítenek meg a rendszer segítségével.

Minden egyes szerepkörnek jól rosszul értelmezett feladatrendszere van. Használjunk olyan hibajegy kezelő rendszert, amelyben van munkafolyamat definiálás, melyben az egyes lépések engedélyezését szerepkör tagsághoz tudjuk kötni - személyes kedvencem a JIRA.

Valamint ugyancsak hasznos lehet, jelentősen eltérő szerepek esetén, ha az eszköz megengedi, akár rejtsük el a mások által felvett hibajegyeket, ezáltal virtuálisan szeparált hibajegy adatbázisokat létrehozva, amelyeket megfelelő hozzáféréssel egyben lehet látni, kezelni - TestDirector - data hiding opció a defect managementben.

Teszt futtatás

A teszt futtatás megtervezése fontos feladat. Nem szabad elfelejtkezni arról, hogy csakis egy egy funkció újonnani, első tesztelése során lép fel az az idealisztikus állapot, hogy a megtervezett teszteket egy az egyben lehet futtatni is.

Mit is kellene akkor futtatni a következő teszt körben?

1.,Fontos, hogy az újonnan elékszült funkciók milyenségéről a fejlesztői csapat mielőbbi visszacsatolást kapjon. A remélhetőleg már elkészült, új funkciókat ellenőrző teszt esetek futtatása kiemelt fontosságú. Természetesen megfelelő projekt menedzsment támogatás kell ahhoz, hogy az új funkció(k) bemutatásának idejére az ezeket tesztelő esetek is készen legyenek.

2., Ezzel szinte párhuzamosan a kijavítottra jelentett hibajegyek tesztelését is ütemeznünk kell. Ideális világban minden egyes hibajegyre (ha még nem volt) készül teszt eset, és a tesztelő ezt futtatja.

Így elkerülhető az a tipikus hiba, miszerint régen lezárt hibákat (rossz hozzáférés, és munkafolyamat szabályozás mellett) csak azért nyitnak újra, hogy a hibát leíró lépéssor (=teszt eset) futtatását kérjék a tesztelőtől.

3., Ha megbizonyosodtunk arról, hogy minden lehetséges kijavítottra jelentett hibajegyet ellenőriztünk, akkor, a reménybeli módon, a hibákhoz kötött (és a teszt menedzsment eszközben ezeket könnyedén megtalálva) az előző körökben hibára futott teszt esetek újrafuttatásával is számolni kell. Nincs kész a funkció tesztje, ha a vele kapcsolatos hibajegyeket lezártuk. Az ellenőrzött, minnél szélesebb logikai lefedettséget biztosító teszt eset sikeres futtatása, szinte minden esetben többet jelent mint pár hibajegy ellenőrzése.

4., Regressziós tesztek. Minden új tesztkörben, buildben, releaseben, kiadásban javasolt egy jól definiált regressziósnak kinevezett teszt készlet futtatása. A definición folyamatosan dolgozni kell. Előfordulhat, hogy csökkenteni kell, mert futtatásának hossza olyan terhelést ró a tesztelő csapatra, amelyet nem tud kezelni. Előfordulhat, hogy növelni kell a regresszióban részvevő tesztesetek számosságát, mert hibás kódrészletek nem akadnak fent a hálón.

5., Valamint bármilyen, a témával kapcsolatos, a fejlesztőktől érkező igényt célszerűleg ki kell elégíteni.

Ha készen van a teszt futtatásban részvevő elemek kiválasztása, szükség szerinti frissítése, akkor a tesztkörnyezet frissítése, ütemezése a következő feladat.

A végrehajtás során a manuális tesztelésért felelős tesztelő kolléga (automatizálásról kicsit később) a megtervezett teszt eseteket futtatja a tesztelés alatt álló alkalmazáson (AUT - application under test).

A szervezetben kialakult szokások, jobb esetben teszt stratégia alapján vannak a teszt esetek részletezve. Ennek megfelelően előfordulhat, hogy a teszt eset csak elnagyolt lépéseket tartalmaz és csak néha elvárt végeredményt, illetve az utolsó bitig definiált teszt eseteket, minden esetben leírt elvárt eredménnyel is láttam már.

Értelemszerűen, az elnagyolt változatnak kevesebb a tervezési igénye, a részletesnek pedig a futtatási, reprodukálási erőforrásigénye.

A remélhetőleg fontossági sorrend szerinti futtatás során a tesztelő tehát végrehajtja a teszt esetben található lépéseket, az elvárt eredménytől való eltérés esetén jelez. Vannak olyan szabványok, ahol ezen eltéréseket a teszt futtatás végén gyűjtik össze és döntik el, melyik valójában hiba. Jellemzően olyan megközelítéssel találkoztam eddig, amelyben a tesztelő az eltérés megtalálása után azonnal (1-2 napon, órán belül) hibát jelez.

Célszerű lezárási feltétel rendszert definiálni a teszt futtatáshoz, amellyel objektíven tudjuk jelezni azt, hogy mostmár egy nagyobb, teszt futtatásokat összefogó, tesztelési folyamat lezárható.

Teszt tervezés

Véleményem szerint a legszebb, és leginkább elhanyagolt része a tesztelésnek.
Statikus tesztelésnek is nevezik, mert a tesztelendő alkalmazást - az esetek javarészében - nem futtatjuk. Teszt tervezés során teszt eseteket írunk, frissítünk.
Ennek forrása szinte bármi lehet, és kell hogy legyen, a tesztelők által rögzített követelmények, az elemzők üzleti követelménylistája, a fejlesztési módszertannak megfelelő különböző szintű fejlesztési dokumentácó, folyosói pletykák, eddigi tapasztalat az alkalmazással kapcsolatban, hogy párat megnevezzünk. A tesztelőnek erkölcsi kötelessége, hogy a lehető legszélesebb skálán mozogva szerezze be a munkájához szükséges információt.

Különböző szintekben kell gondolkodni a teszt tervezés során. Alapvetően a fejlesztéssel párhuzamos szinteket kell kialakítani, ha ez nem megy, vagy a tesztelésnek kell kezdeményeznie, akkor javaslom a standard "V" model 4 szintjét, a modul, integrációs, rendszer, elfogadási tesztek szerinti tagozódást. Ezekről részletesen kicsit később.

Különböző módszertanok, technikák szerint lehet írni a szinteknek megfelelő teszteseteket. Többek között említeni fogjuk a fehér és fekete doboz tesztelést, egyenlőségi particiókat, határérték elemzést.

Az elkészült, frissített teszt eseteket ellenőrizni kell. Az ISTQB több féle review módszert ajánl, ebből az eddigi tapasztalatomban egy egyszerűsített megoldást tudtam használni.
Két szinten történik a teszt tervezés: felső szinten a követelmények azonosítása után, ezen követelményeket kielégítő teszt eset struktúra létrehozása a feladat. Számos teszt menedzsment eszközben megvan a lehetőség csak a összefoglaló, summary rész megírására. Itt pár szóban le kell írni, hogy mi a célja a tesztnek, kb. milyen teszt adatokon fog futni. Ha ezzel készen van a tesztelő, akkor jelzi a teszt menedzsernek, aki review-t, áttekintő megbeszélést hív össze, ami előtt (definiált időkeretben) felkészülés zajlik. Egy, a domain-hez jól értő tesztelő, és egy tesztelésben jártas kolléga átnézi a teszt terv vázlatokat. Az áttekintő megbeszélésen a teszt tervező előadja az ő értelmezésében az adott funkció célját, lényegét majd a teszt terv vázlatot mutatja be. A domain tudással rendelkező tesztelőnek ilyen szempontból kell vizsgálnia a tesztterv összességét, a teszt tervezésben jártas részvevő pedig a tesztterv integritását veszi górcső alá. A megbeszélés végén születik egy egyszerű szöveges feljegyzés, melyben a módosítandó pontokat sorolják fel.
Ezután a teszttervező a rögzített pontokat átvezeti a teszt terv vázlaton, majd a teszt terv vázlatot elkezdi feltölteni teszt lépésekkel. Ezzel párhuzamosan végleges állapotában definiálja a teszt adatokkal kapcsolatos elvárásait, és létrehozási kéréssel átadja a teszt adat felelősnek.

A második átnézés a teszt esetek, teszt adatok elkészülte után történik. Általában egyszerűbb, egy ember átfutja, ha lehet lefuttatja (dry run) akár még az alkalmazás nélkül a teszteseteket.

A projektben elfogadott rendszer szerint a tesztesetben talált hibát is lehet / kell rögzíteni a hibajegy kezelő rendszerben.

Tesztelési követelmények

Érdekesen fogadják, mikor arról beszélek, hogy a tesztelésen követelményeket kell karban / nyilvántartani.
Sok olyan dolgot tudunk követelményben rögzíteni, amiről az üzleti követelménylistában nem esik szó.

Funkciónális követelmények - igen, első pontban az ügyfél, rendszerszervező stb. által összeírt funkciónális követelmények listája is megjelenhet a tesztelési követelmények között. Ennek alapvető lényege az, hogy a teszt menedzsment eszközökben alap lehetőség, hogy a követelményekhez teszt eseteket lehet rendelni. Míg, könnyen előfordulhat, hogy a független dokumentum, követelmény kezelő eszköz és a teszt menedzsment eszköz között nincs kapcsolat. A nyomonkövethetőség miatt igen fontos dolog a rögzített követelmények és a teszt esetek közötti kapcsolatot rögzíteni.

Nem funkciónális követelmények - sok esetben előfordul, hogy a követelménylista csak funkciókkal kapcsolatos pontokat tartalmaz. Ilyen esetben a tesztelés feladatai közé tartozhat a nem funkciónális követelmények felmérése, szóbeli, vagy tapasztalat alapján összeírjuk a nem funkciónális követelmények listáját. Gyorsaság, használhatóság, terhelhetőség, tesztelhetőség stb.

Kulcs területek - a tesztelésnek minden időpillanatban készen kell állnia arra az eshetőségre, hogy az adott éppen folyamatban lévő munkát félbe kell hagynia. Ekkor is képesnek kell lennünk jelentést tenni arról, hogy mennyi munkát végeztünk el, és reményeink szerint a letesztelt területei az alkalmazásnak a fontosabb területek közé tartoznak. Amennyiben már a követelmények összeállításánál leírjuk, ez alapján konszenzusra jutunk, arról, hogy mely területek a fontosak, akkor a teszt tervezési, futattási munkákban meglesz a referencia a prioritás megfelelő kezelésére.

Architektúra - sok esetben a teszt csapat fekete doboz tesztelést végző kollégákból áll. A tesztek struktúrálása könnyebb, ha kapunk tájékoztatást az alkalmazás architektúrájáról, és ennek megfelelően gondolkodunk a saját dokumentumainkról.

Módszertan - feljegyezhető, hogy melyik alkalmazás területet melyik tesztelési módszertannal szeretnénk tesztelni.

Változás kezelés - nem egyszer előfordul, hogy a fejlesztői dokumentumok változása nem kap egyedi azonosítást, nincs központi nyilvántartása. Ekkor, a megfelelő nyomonkövetés biztosítása érdekében a tesztelők az egyes dokumentumokban talált változásokat a követelmények közé, a "változások" mappa, "dokumentum neve" változás azonosítója alatt feljegyzik, lehetőséget biztosítva az egyes változásokat tesztelő tesztesetek azonosítását. Felkészülve a kérdésre, miszerint az új szervíz csomag (stb) általi változások tesztelve vannak???

Belépési / elfogadási pont - a "módszertannál" jelzett okok miatt célszerű általános értelmű belépési és vagy elfogadási pontok definicióját megfogalmazni....

//
A bejegyzésben említett tételek nem egyszer a teszt stratégiában (test strategy, master test plan) jelennek meg.

a tesztelési mátrix

A tesztelési feladatokat és szinteket felbonthatjuk egy mátrixba.

A mátrix soraiban a feladatok: követelmény elemzés, teszt tervezés, teszt futtatás, hibajegy kezelés.
A mátrix oszlopaiban a tesztelési szintek: elfogadási teszt, rendszerteszt, integrációs teszt, modul teszt.

A cellákban pedig nyomonkövethetjük az adott feladat adott szinten való végrehajtását (amennyiben több egység foglalkozik a teszteléssel).

Célszerű a projekt indító dokumentumban elhelyezni a tesztelési mátrixot megfelelő magyarázattal.