Minden szervezetben adott, milyen sorrendben foglalkoznak a problémákkal a szakemberek. A döntéshozó eldönti, hogy belevágunk a projektbe. Az architekt tervez, a designer rajzol, a rendszerszervezők specifikálnak és felveszik a kapcsolatot a társterületekkel, a vezető fejlesztő megtervezi a fejlesztés menetét, a fejlesztők elkezdenek kódot írni, mindenki pörög ezerrel.
– A tesztelőkkel nem kéne beszélni valakinek? – kérdezi valaki.
– Hol van még a tesztelés… – érkezik a válasz.
A helyes megoldás persze az lenne, ha a tesztelők a teljes folyamatot végig kísérnék: bent ülnének a meetingeken, minden anyagot megkapnának, és elvárás lenne, hogy mindenről érdemben adjanak visszajelzést. Én tíz év alatt eddig egyszer tudtam elérni, hogy a specifikációt is tesztelhessük, ott Confluence-en, kommentekben jeleztük a hibákat, még mielőtt a fejlesztőknek elküldték volna – de ez egyedi eset maradt.
Tény, hogy a tesztelők csak azzal dolgoznak, ami valamilyen szinten már elkészült, de a tesztelők felelősek azért, hogy addigra viszont már felkészüljenek a témából. Ehhez szükséges:
- a kezdetektől figyelemmel kísérni, ami történik: beülni a meetingekre, figyelni, kérdezni,
- azonnal, érdemben megnézni mindent, ami elkészült: terveket, specifikációt, félig sem működő buildeket,
- megírni a test scripteket előre.
Tesztelőnek lenni relatíve kényelmes pozíció, hiszen nem vagyunk felelősek azért, hogy a dolog elkészüljön, sőt ami elkészült, azt is csak kritizálni kell, majd a mások által elkészített javítást is újra kritizálni. Az ehhez szükséges felkészültség és alaposság az, ami mégis a tesztelők felelőssége – a kritizálásnak is van saját minősége.