Sokan vannak azon a véleményen, hogy a tesztelők lusták. Akár igazuk is lehet, mivel számos esetben a tesztelőkön semmilyen kontroll nincs. Most biztosan több tesztvezető is azt gondolja, hogy de én igenis irányítom a csapatomat, és számon kérem a napi munkájukat. Ez rendben is van, na de nem egy helyen megfordultam már én is, tehát tudom azt, hogy mivel a tesztvezető több projektet is irányít, az egyes projektek mindennapi történéseibe már nem lát bele. Sokszor az a helyzet, hogy a vezető meetingekre jár, terveket készít, beszámolókat tart, kapcsolatot ápol, míg a tesztelő végzi a projekt tesztelését. Bármikor is kérdezik meg tőle, hogy "Józsikám", hogy állsz a teszteléssel, barátunk azt mond, amit akar. Akkor is, ha van tesztmenedzsment eszköz, ha van hibakezelő eszköz, ha bármilyen módon dokumentálva van az ő munkája, akkor is tud úgy "füllenteni" a főnöknek, hogy az ne vegye észre.
Ha a tesztelő nem talált meg egy hibát és netán felelőségre vonják, akkor jöhetnek a kifogások:
- a specifikáció nem volt egyértelmű,
- nem volt tesztadat,
- nem volt tesztrendszer,
- későn került ki a build,
- nem volt elég idő a tesztelésre,
- én néztem, de pont akkor, pont ott, pont jó volt, nem is értem a másik rendszeren miért rossz,
- biztos beállítási probléma,
- stb..
Tesztvezető legyen a talpán aki az összes kifogást le tudja ellenőrizni.
Nem azt állítom, hogy minden tesztelő ilyen mentalitással dolgozik, de ha belefutunk egy ilyenbe akkor problémáink akadhatnak.
Ilyen helyzetekben általában segítenek a mérések, mérőszámok.
Szubjektíven mindenki meg tudja mondani, hogy ki a leggyengébb a csapatban. Csak ezt a mérést a feletteseink nem mindig fogadják el. A számomra legkönnyebben használható objektív mérés, amikor a hibák számát hasonlítjuk össze.
Számoljuk össze a tesztelő által elkapott hibákat, és az összes bejelentett hibát. Ezek aránya már lehet egy mérőszám. Ha finomítani akarjuk, akkor a tesztelő által elkapott hibákat az összes olyan hibával hasonlítsuk, melyeket a tesztkörnyezeten is lehet reprodukálni. Ezzel kiszűrhetünk beállítási problémákat. A körülmények figyelembe vételével még tovább szűkíthetjük az összes hibák számát, ha kivesszük belőle azokat, amelyeket a tesztelőnek eleve nem kellett nézni, vagy nem volt hozzá elég ismerete. Pl.: üzleti folyamatok hibái, melyekhez mély üzleti tudás kell, amellyel a tesztcsapat tagjai nem rendelkeznek, tesztadatok hibái, stb.
A képlet finomításával azt lehet elérni végső soron, hogy összeszámoljuk mennyi olyan hiba van, amelyet elkapott és mennyi amelyet - habár meg kellett volna találnia de - nem fedezett fel a tesztelő. Ezek aránya adja meg a tesztelő munkavégzésének hatékonyságát.
Kommentek