2010. január 30., szombat

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.

Nincsenek megjegyzések:

Megjegyzés küldése

Tesztelés a gyakorlatban – A szakértő tesztelők lapja