A helyzet az, nem gondolkodtam sokat azon, hogy mi legyen az előadás bemelegítő témája. Egy tesztmenedzser barátom jutott eszembe, aki többször panaszkodott nekem arról, hogy -természetesen szigorúan a hatékonyságnövelés érdekében- a felettesei csökkentettek valamilyen rendelkezésére álló erőforrást (idő, tesztmérnökök), és mindeközben azt várják tőle, hogy továbbra is “biztosítsa ugyanazt a minőséget”.
Persze erre én rögtön ugrottam, rendszerint nyílt kritikával illetve az elhangzottakat: "Szereptévesztésben élsz, te is és a feletteseid is."
A tesztelők nem biztosítanak minőséget. Még csak meg sem kell, hogy próbálják.
A tesztelés információgyűjtés (illetve a különböző jelentéseken keresztül információszolgáltatás is).
Egy tesztelő által előállított legfontosabb termék nem valamiféle írásos teszt terv, nem a teszt esetek esetleges scriptjei, vagy ezek formális dokumentációja, hanem a tesztelt rendszer (vagy a projekt) minőségi jellemzőivel kapcsolatos információ. És információk, bizonyítékok egyszerű gyűjtése még nem jelent cselekvést is ezek alapján. Márpedig a minőség biztosítása mindkettőt igényelné: egyrészt visszajelzéseket, másrészt a beavatkozást.
Kaner és szerzőtársai ill. Bolton a következőképpen fogalmaznak: a tesztelők önmaguk nem hoznak létre minőséget és nem is vesznek el ebből. (Mondhatjuk, hogy sikerült elrontanunk a programot, de a helyzet az, hogy rossz volt már akkor is, amikor ideadták nekünk.) Természetesen felelősek vagyunk a saját munkánk minőségéért, vagy annak az információnak a minőségéért, amit mások számára nyújtunk -jellemzően a tesztek eredményein és a hibajelentéseken keresztül, ezáltal segítve azoknak, akik közvetlenül hatnak a minőségre - de ez nem a szoftver minőségének a biztosítása.
A minőség azoktól jön, akik építik a programot, ennek biztosítása pedig a döntéshozóktól függ: jellemzően a fejlesztők és a menedzsereink hatóköre ez. A mi feladatunk az, hogy megkönnyítsük a munkájukat jó minőségű információ átadásával. Ez segíti a döntéshozatalt és így egy projekt folyamán a minőség biztosítását. De mi, tesztelők nem tervezünk rendszereket a felhasználók igényei alapján, nem írunk kódot, nem javítunk hibákat, nem mi döntünk az alkalmazásfejlesztés menetrendjéről, vagy arról, hogy mennyi pénzt fordíthatunk rá. Nem mi határozzuk el, kik dolgoznak majd a projekten, milyen kapcsolatot kell kiépíteni a felhasználókkal és még hosszasan lehetne folytatni a felsorolást. A tesztelők szerepe szolgáltatás jellegű, nem pedig kontroll vagy döntéshozatali.
Az előadást megelőző este kíváncsiságból végigpörgettem a résztvevők névsorát, vajon kik ők, honnan, milyen szakmai titulussal érkeznek. Néhány ember neve mellett szembeötlő volt a "QA - Quality Assurance" jelzés. Hívhatják a csoportotokat "Quality Assurance"-nak, de ez ne maradjon meg a fejetekben. Amit csinálunk, az inkább "Quality Assistance".
És ha valaki ezen a ponton arra gondol, hogy ez csak játék a szavakkal, arra kérem, nézze egyszerű technikai szemmel a kérdést:
Végtelen számú lehetséges tesztből végrehajtunk és kiértékelünk néhányat. Ugyan mit biztosít ez?
