Szoftvertesztelés

Csináljunk részletes, mindenre kiterjedő hibaleírásokat.

Alaposan járjuk körbe a hibát, írjunk le róla minden részletet, csatoljunk hozzá minél több anyagot, hogy megkönnyítsük a fejlesztők dolgát. A hibákhoz csatoljuk képeket, írjuk le a pontos előzményét, a használt felhasználó-jelszó párost, csatolhatunk hozzá SQL utasítást, különböző fájlokat, esetleg a specifikáció ide vonatkozó részét. A lényeg, hogy a fejlesztőket minél több információval lássuk el a hibákkal és azok előfordulásával kapcsolatosan.

Térképezzük fel a hibát teljesen

Próbáljuk meg reprodukálni, hogy minél több részletet le tudjunk róla írni. Milyen előzményei voltak a hibának, hogyan és mikor jön elő. Talán az előfordulásában találunk olyan logikát, amely már egyértelművé teszi a fejlesztőnek a hiba pontos helyét a kódban.

Ezekkel azt érjük el, hogy a fejlesztőknek könnyebb lesz megtalálni, reprodukálni a hibát. A hibajavítás tetemes része lehet a hiba előállítása, reprodukálása, megértése, megismerése. Ha ezt az időt le tudjuk csökkenteni, akkor gyorsítani tudjuk a hibák kijavításának sebességét.

Hogyan tudjuk a hibajavítást gyorsítani?

• Jelezzük a hiba súlyosságát

• Csináljunk részletes, mindenre kiterjedő hibaleírásokat

• Térképezzük fel a hibát teljesen

• Dolgozzunk összhangban a fejlesztőkkel

• Csináljunk státusz riportokat

• Eszkaláljuk a problémát

A legfontosabb a hibák súlyosságának jelölése. Egy hibariportból nem mindig tűnik ki, hogy az a hiba milyen súlyos, mennyire akadályozó a tesztelés számára. Ha eddig nem jelöltük a hibák súlyosságát, akkor ezentúl ezt is jegyezzük fel. Ha a használatban lévő hibakezelőben be lehet venni egy plusz mezőt, akkor egyszerű dolgunk van. Ha nem, akkor nincs más hátra, mint a súlyos hibákat rendszeres időközönként összeszedni és átbeszélni mindegyiket a fejlesztés vezetőjével.

A cél, hogy a hibák javításának dátumát előrébb mozdítsuk.

Mindenképpen szükséges hogy a projektvezető, vezető fejlesztő értesítve legyen arról, a tesztelési csapat nem tud kellő munkát végezni. Az már a projektvezető dolga, hogy eldöntse mikor javítják ki a hibát.

Viszont arra ügyeljünk, hogy kizárólag azon hibák érdekében lépjünk fel, amelyek tényleg akadályozzák a tesztelést. Ám ezek érdekében mindenképpen cselekedjünk!

Nem minden alkalommal egyezik meg egy hibának a prioritása és a súlyossága. A hibajavítás prioritásának beállítását a projektvezető, vezető fejlesztő végzi, míg a hiba súlyosságát a tesztelő határozza meg. Sokszor kerülhetünk olyan helyzetbe, amikor egy súlyos hibát kis prioritással vesznek a fejlesztők és időben jóval később kerül kijavításra, mint ahogy azt a tesztcsapat elvárná.

Gondolhatnánk, hogy ilyen nincs, mivel a súlyos hibák mindig magas prioritásúak. De tévedünk ha ezt hisszük. Előfordulhat az, hogy a tesztelést megakasztja egy hiba, de a fejlesztők mégsem ennek kijavításával törődnek, mert más fontosabb feladatuk van. Például egy modul, vagy unit fejlesztése sürgősebb, mint a hibajavítás, mert a unitra épülnek a többi modulok és nélküle nem tudnak tovább haladni a fejlesztésben. Vagy a késéssel több fejlesztő munkavégzését veszélyezteti, csúsztathatja. A fejlesztő elsősorban a fejlesztési csapat érdekeit nézi, a tesztelő pedig természetesen a tesztelési csapatét.

Mindenkinek megvan a saját munkája, határideje. A cél, hogy azt befejezze. Pláne így van ez, ha külsős fejlesztő cég készíti az alkalmazást. Majdnem biztos, hogy a mi általunk súlyosnak tekintett hibák nem olyan időrendben fognak javulni, mint ahogy azt elvárnánk. :)

A tesztelők, tesztvezetők számára általában az a cél, hogy a tesztelést akadályozó hibákat minél hamarabb kijavítsák a fejlesztők. Ennek elérése érdekében a súlyos, megakasztó hibákat részesítsük nagyobb figyelemben. Ahol lehet hívjuk fel rájuk a figyelmet.

Egyik vállalatnál a legnagyobb problémát a munkafeltételek megteremtése okozza. A tesztelés azért nem tud elindulni, mert nincs belépőkártya, szék, asztal, számítógép, illetve már a portán is csak kínkeserves harcok árán tudok bejutni.

Természetesen én akár otthonról is dolgoznék a laptopról, de a vállalati szabályzat nem engedi. Saját laptopot nem lehet hálózatra kötni, viszont belső asztali gépet meg nem adnak. Így az már másodrendű probléma, hogy nincs felhasználónév, jelszó, elérhetőség a tesztelendő rendszerhez.

Mire minden megoldódik, eltelik a tesztelési idő nagy része. Természetesen ezeket a problémákat ismerik a cégnél, de senki nem számol vele, hogy az új embernek a munkavégzéshez szükséges feltételeket meg kell teremteni. Akkor nem gond, ha több éves projektről van szó, mert az a pár nap az elején nem oszt, nem szoroz. De ha 2-3 hetes projektben 1 hétig tart ez a kis közjáték, az nagy problémát okozhat.

A kérdés, hogy két egymástól külön dolgozó tesztcsapat munkáját hogyan lehet objektív módon összehasonlítani, ha a csapatok más fejlesztőkkel, eltérő tesztelési környezetben, különböző határidőkkel és teljesen más feladatokkal foglalkoznak.

Viszont nekünk a projektek végén meg kell mondanunk, hogy melyik tesztcsapat teljesítette jobban a munkáját.