Pillérek

Jó néhány cégben névleg létezik a mindennapi életben használt szoftverfejlesztési módszertan, melynek általában a teszteléssel folgalkozó részét rövidítik le, ha a határidő szorítása úgy kívánja. Definiáljunk hát módszertantól függetlenül egyszerűen kommunikálható tételeket, amelyek segítségével mindennapi tudatban tartjuk a szoftvertesztelést, mint szüksges és elfogadott részét a termékfejlesztésnek.  

Előfordult már, hogy a tesztelésért felelősként nem értették, miért kérsz még embert? “Csak nyomogassátok át!” utasítás érkezett szállítási határidő előtt pár nappal? Minőségi kifogásokat emeltek a tesztelés munkájával kapcsolatban egy fél éve kiadott termék ügyében? Kérdezték, hogy ezt a hibát miért csak most találtátok meg? 

Vezetőink, (nem tesztelő) munkatársaink nincsenek tisztában a tesztelői munka alapjaival.

Minőség

A tesztelés ugye, mint a fejlesztési folyamat része, ugyancsak minőségorientált kell, hogy legyen. A tesztelés mérése sokkalta nehezebb, mint bármely más IT-folyamaté. Nagyon sok esetben sajnos csak implicit módon, a kiengedett, az ügyfél által észrevett hibák számában mérik a tesztelés minőségét, majd kérdezik, ti ezt miért nem vettétek észre? Mindezt úgy, hogy nem adnak lehetőséget arra, hogy a tesztelő megtervezze, minőségbiztosítsa a munkáját.

A folyamathoz csatolt, annak szerves részeként kezelt, minőségi, ellenőrizhető, minőségbiztosítható a tesztelési dokumentáció, amelyet természetesen a projekt termékeként értelmeznek a részvevők. 
Sosem felejtem, mikor 2001 környékén a kiadott szoftververzió mellett ott volt egy CD-n több száz oldalnyi teszteset és ennek futtatási információja, mely az ügyfél kiemelt megelégedettségét eredményezte. 

Minőséget első körben úgy tudunk megjeleníteni, ha megtervezzük a munkánkat, ezt leírjuk, terméket hozunk létre, mely terméket lehetőségeink szerint minőségbiztosítunk. A termékek lehetnek tesztesetek, tesztfuttatási jegyzőkönyvek, hibajegyek, tesztkörnyezet-leírások; a minőségbiztosítási folyamat lehet ezek ellenőrzött áttekintése, a “review”. Reviewnak ezernyi változata van, leginkább ajánlott az ISTQB FL certified tester tananyagban definiált review típusokat átnézni. 

Végül aláírásunkkal vállaljuk, hogy a dokumentum és a benne foglalt tesztelés a tudásunk maximumát tartalmazza. 

Ha munkánkat jól végeztük, akkor nem csak a tesztelői tapasztalat – amely sok helyen az egyedüli záloga – volt a kulcsa a megfelelően letesztelt, jó minőségű alkalmazás sikeres kibocsátásának, amelynek legyen része a tesztelési dokumentáció is.

Átláthatóság

Sokszor, sokan kérdezik, hogy mi tart nektek annyi időt? 
“Ez csak pár sor módosítása volt a szoftver kódjában… “

Nem tudják, mit csinálunk, nem ismerik a tesztelés belső folyamatait. Sőt, sajnos nem egyszer a tesztelés sem konzisztens az elvégzendő feladatok listáját érintően. Bármilyen módszertant is használunk, szükség lehet testreszabásra, melynek nyomán célszerű leírni a tesztelés belső folyamatait. 

Mit, miért, hogyan, milyen dokumentumok felhasználásával, milyen termékek létrehozásával, mikor végzünk el. Jobb esetben a tesztelést a projektfolyamat egészében ábrázolva – jó példa erre egy Deming minőségi kör szerint felépített “teszt kör” definíció. Célszerű talán erről egy, a projekt által közösen használt wikiben írni egy bejegyzést. 

Majd oktatást (szükség szerint megismételve) tartani a tesztelőknek, és egyszerűsített, rövidített formában a projekt többi tagjának is. 

Fontos, hogy a leírt folyamatoknak megfelelően osszuk ki a tesztelőknek a feladatokat, és a projekt-helyzetjelentésben a tesztelés ne csak egy nagy fekete dobozként jelenjen meg.

Skálázhatóság

A tesztelés, tehetünk szinte bármit, mindig is hullámhegyekkel, völgyekkel él együtt. Hullámhegyek, amikor a projekt lassan átadási fázisba kerül, és az addig itt-ott csak egy kicsit késő folyamatok a tesztelésnél gyűlnek össze, jelentős késéseket okozva. Gyorsan és sokat kell dolgozni. 

Ha leírtuk, közzétettük, hogy mit, milyen folyamatokban, milyen minőségi elvárásokkal kívánunk elvégezni, ezen folyamatokat monitorozzuk, akkor időben, egyre pontosabban tudjuk majd a várható plusz tesztelői erőforrás igényét jelezni vezetőink felé. 

Remélem, sikerült mankót nyújtani a tesztelés elfogadtatásához, a problémáink megértetéséhez, valamint ugyancsak bizakodva tekintek a jövőbe, mikor egy kedves olvasónak a vezetője egy krízishelyzetben érteni fogja, hogy nem öncélú a tesztesetek írása a kérdéses funkcióhoz. 

A következő számban a tesztelés és a programozás közötti klasszikus felfogásban értelmezett együttműködésről írok.

Szerző: Schaffhauser Balázs