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.

Teszt menedzsment eszköz

Általában véve nem hiszek abban, hogy a teszt menedzsment feladatokat megfelelően preparált táblázatokkal nyomon lehetne követni. A teszt menedzsment szól a követelményekről, teszt tervekről, teszt futtatásról, és nem egy esetben a hibajegy kezelésről is. Ez egy 3 dimenziós mátrixot alkot, egy követelményhez tartozhat egy vagy sok teszt eset, egy teszt eset tartozhat egy vagy sok teszt futtatáshoz, teszt készlethez. Ember legyen a talpán, aki ezt táblázatkezelőben nyomon tudja követni.

Hamár döntés született a teszt menedzsment eszköz bevezetéséről, akkor célszerű a kiválasztási folyamatban az alábbi főbb pontokat ellenőrizni:

- követelmények
A teszt menedzsment során akár az üzleti, funkciónális, vagy tesztelői követelményeket nyilván kell tartani. Jobb esetben az eszköz megfelelő fa struktúrával, azonosítással, státusszal támogatja a követelménykezelést. Fontos, hogy teszt eseteket lehessen a követelményekhez csatolni.

- teszt tervezés
A teszt esetek tervezését támogató modul. Jobb esetben a manuális és valamilyen válaszott automatikus tesztelő eszköz teszt eseteit és képes egy struktúrában bemutatni.

- teszt futtatás
Két fontos dolog: a teszt készletek (futtatandó teszt esetek gyűjteménye) megtervezése, mit, mikor, milyen rendszeren ki futtat. Valamint ezen teszt készletek futtatása, a talált eredmények rögzítése a modul feladata.

- hibajegy kezelés
Ismert integrált megoldás is, általában inkább különálló alkalmazás segítségével kezelik a hibajegyeket. Lényeges, hogy több szerepkör látja a hibajegyeket, igény szerint képesek legyünk a feladatokat elhatárolni (pld.: csak a tesztelő zárhasson le hibát. stb), valamint a megfelelő testreszabási, automatikus értesítési funkciók fontosak lehetnek.

- egyéb szempontok:
dokumentum kezelés: több helyen tapasztaltam, hogy a dokumentum kezelés eléggé hektikus, formális szabályokat nélkülöző. Ekkor nagyon nagy segítséget jelenthet a tesztelőnek, hogy az általa használt teszt menedzsment eszközben legalább alapszinten lehetősége nyílik arra, hogy a dokumentumait megfelelő módon kezelje.
szerepkörök: nagyobb tesztelési szervezetekben elkülönűlhet a tesztelést jellemző szerepkörök napi megvalósítása. Lesz aki manuális tesztet ír, aki automatikus tesztet ír és futtat, aki manuális teszteket futtat. Előfordulhat az is, hogy külsős vállalkozó együttműkődésére kell felkészülni.

Általam használt, vagy használatban lévő teszt menedzsment és hibajegy kezelő rendszerek:
HP Software (Mercury Interactive) TestDirector for Quality Center, Microfocus (Borland, Segue) silkCentral, TestLink, JIRA, Bugzilla. Ezekben felmerülő kérdésekben szívesen segítek.

Pillérek

Mivel a szoftvertesztelés viszonylag új szakma, ezért úgy gondolom, hogy le kell fektetni, hogy milyen eszmei alapokon gondoljuk el a megszervezését, üzemeltetését.

Véleményem szerint 3 fő pillért lehet azonosítani:

- Minőség
- Átláthatóság
- Skálázhatóság

Minőség. Sokszor előfordul, hogy megkérdezik, ti ezt miért nem vettétek észre? Ennek alapvető oka általában az, hogy nincs lehetőség megtervezni, és minőségbiztosítani a tesztelést.
Tehát, minőséget első körben úgy tudunk a tesztelési munkában megjeleníteni, hogyha megtervezzük a munkánkat, ezt leírjuk, terméket hozunk létre, mely terméket lehetőségeink szerint minőségbiztosítunk. Erre jó a "review" - nézzük át, mit is csináltunk. Írjuk alá a terméket, vállaljuk, hogy ez a tudásunk maximumát tartalmazza.

Átláthatóság. Sokszor, sokan kérdezik, hogy mi tart nektek annyi időt? Nem tudják mit csinálunk, nem ismerik a tesztelés belső folyamatait. Nem egyszer a tesztelés sem konzisztens az elvégzendő feladatok listáját érintően. Célszerű leírni a tesztelés belső folyamatait. Erről oktatást tartani tesztelőknek, és egyszerűsített formában a projekt többi tagjának is.
A leírt folyamatoknak megfelelően kiosztani a tesztelőknek a feladatokat, ezen feladatokat nyilvános rendszerben nyomonkövetni.


Skálázhatóság. A tesztelés, tehetünk szinte bármit, mindíg is hullámhegyekkel, völgyekkel él együtt. Hullámhegyek, amikor a projekt lassan átadási fázisba kerül, és az addig itt-ott csak egy kicsit késő folyamatok a tesztelésnél kummulálódnak, jelentős késéseket okozva. Gyorsan és sokat kell dolgozni.
Ha leírtuk, hogy mit, milyen folyamatokban, ezek hol tartanak, akkor egyre pontosabban tudjuk majd a várható plussz tesztelői erőforrás igényt jelezni vezetőink felé.