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