2010. március 30., kedd

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és a gyakorlatban – A szakértő tesztelők lapja