Nemegyszer előfordult már, hogy a projekt elején megbecsült tesztelésre szánt időt a projekt alatt megváltoztatták, csökkentették. Általában azért szokták változtatni az idő intervallumokat, mert:
- Nem marad elég pénz a tesztelésre
- A fejlesztés csúszik, de a végleges határidőket tartani kell
- A megfelelő mennyiségű és minőségű tesztadatra várni kell
- Későn lehet használatba venni a tesztkörnyezetet.
- stb...
Sőt, néha már a projekt előtt elkezdik a tesztelés hatókörét (és ezzel együtt az idejét is) csökkenteni, mert:
- Nem jól becsülik fel a tesztelési munkát
- Drágának találják a beérkezett árajánlatokat
- A feladatra nincs elég pénz
- stb...
Olykor meg kell húzni a határvonalakat és ezt a projekt szereplőinek meg kell érteni. Nem lehet mindenkinek kedvezni.
Ilyen esetekben milyen lehetőségünk van, hogy kevesebb erőforrásból ugyanolyan minőségi munkát végezhessünk?
Sajnos ha nem ad a projekt vezetősége elég erőforrást (embert, időt, eszközt) akkor nem sok mindent tehetünk. Lehet priorizálni a feladatokat, átcsoportosítani az erőforrásokat, de ne várjunk csodákat. Ilyenkor erőnk nagy részét a tesztelési csapat megvédésére kell áldozni.
Szomorúan hangzik, hogy Önmagunk védelmére kell fordítani a drága tesztelési időt, de sajnos ezzel tudjuk elérni azt, hogy a projekt végén a tesztelésre segítőtársként, ne pedig bűnbakként nézzenek. Nem mindegy, hogy a tesztelés segítségével rámutatunk pár működésbeli hiányosságra, vagy felelősségre vonnak amiért nem végeztük el bizonyos modulok részletesebb tesztelését. A felelősök keresésénél a tesztelők elég nagy hátrányból indulnak. "Egy felderítetlen hibáért ki más lenne a felelős ha nem a tesztcsapat?"
Hogyan tudjuk megvédeni a tesztelést?
Dokumentálással és eszkalálással. Dokumentáljunk minden olyan tényt, ami hátráltatja a tesztelést, egyben a felettesekhez juttassuk el az információt.
Amennyiben tudomásunkra jut, hogy egy teszteléshez szükséges feltétel nem teljesül, úgy azon nyomban tegyünk lépéseket a probléma feldolgozására. Írjuk le a tényt és tegyük közre. Közöljük a projekt többi szereplőjével a kialakult helyzetet és tegyünk javaslatokat a megoldására.
Vázoljuk fel mindkét esetet, hogy sikerül-nem sikerül elhárítani a problémát. Mit jelent ez a tesztelésre nézve, mit jelent a minőségre nézve? Milyen előnyünk származik a probléma megoldásából? Milyen hátrányokkal kell számolni, ha nem, vagy csak részben oldjuk meg a problémát?
A feljegyzéseket küldjük el a projekt megfelelő tagjainak (akik tudnak tenni a probléma elhárításáért), a feletteseinknek, hogy információk birtokában dönthessenek a probléma megoldásáról.
A dokumentálással és ezzel a konstruktív hozzáállással általában elkerülhető az, hogy a projekt legvégén a tesztelési csapat legyen a hibás minden egyes fel nem derített hibáért.
Mit érünk el a dokumentálással?
A következő projektben is lesz tesztelés és lehetséges, hogy az előbb felsoroltak miatt jobb feltételeket fog kapni. Ezáltal nagyobb esélyünk lesz minőséget beépíteni az alkalmazásba.
Tapasztalat
Sajnos voltam olyan projektben, ahol az eszkalálást és a dokumentálást is mellőztük. Egyszerűen csak tettük a dolgunkat. Ha nem volt megfelelő tesztadat, tesztrendszer, akkor találtunk más munkát. Dolgoztunk folyamatosan, de alig valamivel lett jobb az eszköz. A projekt végén az alkalmazás használhatatlan volt. Ki volt a felelős? Természetesen a tesztelői csapat. Az első 2-3 kérdésre lehetett úgy válaszolni, hogy azért nem teszteltük, mert ..., de a többinél már nem hittek nekünk. Bizonyítani nem tudtuk, dokumentálva nem volt.
Mit mondjak, nem volt egy kellemes érzés a szidalmakat begyűjteni. Azóta minden projektben ügyelek arra, hogy ilyen ne fordulhasson elő. Ha mégis ilyen történik, azt elfogadom az én hibámnak, nem tolom át a felelősséget senki másra.
Kommentek