Menü Bezárás

A tesztelés jól halad ez mit is jelent pontosan? A termék jó állapotban van, vagy jó a lefedettségünk, vagy sok hibát találunk? A tesztelés nem jól halad?
A termék jó állapotban van? A tesztelés megakadt? Szokatlanul sok hibát találunk?

Nem meglepõ módon az emberek válaszaiban a kérdés értelmezése is benne van. Ugyancsak nem meglepõ módon, az értelmezés is különbözõ. Ami viszont meglepõ, hogy úgy tûnt, jó néhány ember hisz abban, hogy a kérdésre adandó válasz egy, közös értelmezésen alapul, és természetesnek gondolják, hogy ezt kérdés feltevõje automatikusan meg is érti.

Mit is jelent tesztelni  többek között , megírni, szerkeszteni, megjegyzésekkel ellátni és igazolni egy történetet. Mint bármely más jó történet, egy teszteléssel foglalkozó történet is több témát érint. Három, fonalként egymásba csavarodó történetszálról ismerjük meg a jól megírt tesztelési történetet. Egy fonalat kihagyunk, és a félreértelmezés esélye drasztikusan megemelkedik. Említettem ezt már korábban , de úgy tûnik, itt az ideje az emlékeztetõnek.

A Gyors szoftver tesztelés módszertanban a három szálon szõtt tesztelési történet fontosságát hangsúlyozzuk; mely szálak mindegyike saját üzenetet hordoz.

A termékrõl és a jelenlegi állapotáról szól az elsõ üzenet. A tesztelés folyamán sokat tanultunk a termékrõl; mi ez, mit csinál, hogy mûködik, hogyan nem mûködik az ügyfeleink nézõpontjából. A legfõbb ok, amiért a megrendelõk tesztelõket bíznak meg, hogy minél elõbb megismerkedjenek azokkal a problémákkal, amelyek a termék használhatóságát, értékét veszélyeztethetik ennek nyomán fõként hibaleírások lesznek a termék állapotáról szóló üzenet fõsodrában.

A kockázatok, mint potenciális, de még nem felfedezett problémák, ugyancsak erõs hangsúllyal szerepelnek ebben az üzenetben. A termékkel kapcsolatos jó híreket mindig könnyû elmondani, jól néznek ki a termék állapotáról szóló jelentésben. A rossz hír viszont, és fõként a további rossz hírek esélye, menedzsment figyelmet követel magának.

A tesztelésrõl szól a következõ üzenet. Jótállásra van szükségünk, ha a menedzsment bizalmát el akarjuk nyerni, megtartani. Leírván a konfigurálás, mûködtetés, megfigyelés és kiértékelés folyamatát, válik a termék állapotáról szóló üzenetünk indokolttá és megbízhatóvá. Ezen felül, a tesztelésrõl szóló üzenetben meg kell fogalmazni azon módszereket, amelyek segítségével felismerjük a problémákat, a döntéseinket megalapozó tesztelési orákulumot. Legvégül meséljünk még arról, merre kerestük a problémákat; a tesztelési lefedettségrõl.

Fontos, hogy beszéljünk arról, mit fedtünk le tesztelésünkkel, de talán még fontosabb arról beszélni, hogy mi van még hátra, vagy mit nem tervezünk egyáltalán lefedni, addig amíg nem módosul valami.

A nem lefedett területek olyan hibákat, kockázati tényezõket rejthetnek, amelyek jóval veszélyesebbek a már azonosítottaknál. Mivel idõnk és energiánk véges, választanunk kell a tesztelési célokban. A mi felelõsségünk az, hogy a tesztelési célok kiválasztásának módjáról, okairól az ügyfeleink értesüljenek. A lehetséges, de nem elvégzett tesztelési célokat külön ki kell emelni, hogy ügyfeleink megfelelõen elõkészített döntéseket tudjanak hozni a nem tesztelt termék területekhez kapcsolt kockázatokról, vagy útirány és erõforrás módosítás nyomán ezen célok tesztelésérõl rendelkezhessenek.

Beszélnünk kell arról, mennyire jó a tesztelés. Ha a második szál az elsõt támogatta, a harmadik a másodikat. Ennél a pontnál, az a feladat, hogy elmondjuk, hogy a lehetséges legjobb tesztelést csináljuk, vagy azt, hogy miért nem, és milyen javaslataink vannak a jobbá tételre.

Különösen, a képességeink szerinti leggyorsabb, legolcsóbb és legerõteljesebb tesztelést blokkoló tényezõket kell bemutatnunk. A Gyors szoftver tesztelés nevezéktan szerint, a hiba egy felismert kockázat amely a termék használati értékét csökkentheti; a probléma pedig a tesztelés értékét csökkentheti. (Amíg felismerjük, és a menedzsmentet tájékoztatjuk a tesztelést esetlegesen blokkoló tényezõkrõl, addig a címkék nem számítanak)

A harmadik szál alapeleme a tesztelhetõség . Bármi, ami a tesztelést nehezebbé, lassabbá, gyengébbé teszi, esélyt ad a hibáknak a felfedezés nélküli túlélésre. A menedzsmentnek tudnia kell a tesztelést blokkoló problémákról és errõl döntést kell hozniuk. A mi feladatunk az, hogy megfelelõ információval segítsük õket a döntés meghozatalában.

Valamikor a közeljövõben, egy esõs napon, amikor a vezetõm megkérdezi, miért nem találtad meg azt a hibát?, ésszerû választ szeretnék adni. Elsõ körben, nem én nem találtam meg, hanem senki a csapatból. Arról is jó lenne emlékeztetni, hogy a fejlesztés alatt mindent megtettünk; közösen döntöttünk a tesztelési és tesztelhetõségi fókuszpontokról.

Viszont, ha fejlesztés alatt nem beszélünk a tesztelést érintõ kérdésekrõl, akkor ezek a döntések megfelelõ minõségû információ nélkül lesznek meghozva. Igen, ha nem találtuk meg azt a hibát, akkor biztosra kell mennünk, hogy mindent megteszünk következõ alkalommal a hiba elfogására – ehhez bizony beszélnünk kell a problémáinkról.

Tapasztalatom szerint a tesztelõk általában felismerik az elsõ szál fontosságát, a termék állapotáról szóló jelentést. Kevésbé gyakori a második szál használatában szerzett tapasztalat: a teszt lefedettség modellezése és bemutatása. Sajnos szinte egyáltalán nem létezik a harmadik szál, nem nagyon vannak teszt jelentések, ahol a nem lefedett, és nem is tervezett tesztelési célokról lehetne olvasni. A harmadik szálat érintõen nagyon úgy tûnik, hogy a tesztelést veszélyeztetõ problémákról a tesztelõk egymást tájékoztatják – a vezetõkhöz már nem annyira jut el. A fenti problémák, és a termékben megjelenõ kockázati tényezõk összekötésében sem jók a tesztelõk.

Vezetõk: ha tesztelõi jelentést olvastok, akkor kérdezzetek rá mind a három szálra a történetben. Mi a helyzet a termékkel?, Honnan tudod?, Mely részeket fedtetek le, mely fontos tesztelés nem történt még meg?, Miért lehetünk boldogok a tesztelési munkával? Milyen aggodalmaink vannak? Mi áll az utadba, hogy a lehetséges, legjobb tesztelõi munkát végezzed? Hogy tudunk gyorsabban, könnyebben, átfogóbban tesztelni?

Tesztelõk: ha kérdezik: Hogy megy a tesztelés? akkor valószínûleg bármelyik, fent említett szál lehet a kérdés tárgya.

Ha nem jelezzük, mirõl beszélünk, és csak, az alábbiakhoz hasonló a tesztelés jól halad, a teszteléssel problémák vannak homályos válaszokat adunk, a kérdezõ a válaszunkat értelmezheti a termék állapotára, a teszt lefedettségre, vagy a tesztelõi munka minõségére. A jelentés, amit hallanak és ahogy értelmezik, valószínûleg nem az lesz, amit adni szándékoztunk.

Rövid válasz esetén is, a lehetõ legtisztább megoldás az, ha mind a három szálat megemlítjük. 

Forrás: How Is The Testing Going?
Szerző: Michael Bolton

A szerző

Michael Bolton
12 éve foglalkozik szoftver- tesztelők oktatásával, öt kontinensen. Ő a társszerzője - James Bach mellett - a Rapid Software Testing című kiadványnak, amely bemutatja a bizonytalan körülmények és extrém határidők között végzett szakszerű szoftvertesztelés módszertanát.
Elérhetősége:
michael@developsense.com
http://www. developsense.com

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

18 − kettő =

Vissza