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