Szoftvertesztelés

Ha már hibakezelő eszközt használunk, akkor csak egy aprócska lépés azt tesztmenedzser eszközzel leváltani. Ezekből az eszközökből is léteznek drágább és olcsóbb megoldások. Mivel tud többet egy tesztmenedzsment eszköz egy hibakezelő rendszernél?

Nyilván tudjuk benne tartani a tesztelési követelményeket

Ugyebár a szoftvertesztelés arról szól, hogy ellenőrizzük a rendszerrel szemben támasztott követelményeket. Nos ezeket a követelményeket muszáj valahol nyilvántartani, hogy lássuk mit kellene majd leellenőrizni.

Képes a teszteseteket karbantartani

Nem elég csak a követelményeket nyilvántartani, hanem az azokhoz tartozó teszteseteket is rögzíteni kell. A tesztesetekhez lehessen pontos lépéseket megadni (végrehajtandó feladat - elvárt eredmény). Lehessen hozzájuk képeket, leírásokat, SQL parancsokat, vagy bármi olyat csatolni, amely segíti a tesztelő munkáját. Lehessen a teszteseteket csoportosítani, valamilyen struktúrába rendezni.

A követelményeket tesztesetekkel tudjuk lefedni

Minden egyes követelményt értelmezni kell, majd ki kell gondolni, milyen teszteléssel fogjuk bebizonyítani, hogy azt a követelményt teljesíti, vagy nem teljesíti a rendszer. Vagyis a tesztmenedzser eszköznek képesnek kell lennie teszteseteket karbantartani és a teszteseteket összekötni az egyes követelményekkel. Egy teszteset több követelményt is alátámaszthat, illetve egy követelményt több tesztesettel is igazolhatunk, vagy buktathatunk meg. (Magyarul több a többhöz kapcsolat kell legyen a követelmények és a tesztesetek között.)

Amennyiben téged is érdekel, hogy hazánkban hogyan használják a tesztmenedzsment eszközöket, kérlek töltsd ki az alábbi kérdőívet!

Köszönöm.

Mi a célunk egy hibakezelő eszközzel?

Az, hogy egy helyen, kontrolált keretek között tartsuk a hibákat. Így segítjük mind a tesztelés, mind a fejlesztés munkáját. Nem utolsó sorban pedig a vezetőség is pontos képet tud alkotni a rendszer minőségéről, állapotáról.

Milyen szempontok alapján válasszunk eszközt?

• Természetesen nem mindegy mennyibe kerül. Az ár mindig fontos.
• Mennyi felhasználó fogja használni? (egyszerre/összesen)
• Kik fogják használni? (Milyen IT tudással rendelkeznek?)
• Mire szeretnénk használni? (Csak hibakövetés, vagy tesztmenedzsment?)
• Kívülről hozzáférhető kell legyen? (Szállítók/vevők fogják használni?)
• Több projektet hogyan kezel?
• Jogosultságokat hogyan kell kezelnie. (Felhasználói csoportokat létrehozhatunk, azokhoz hogyan kapcsolhatunk jogokat? A jogosultságokat milyen részletességgel tudjuk definiálni?)
• Mennyire egyszerű adminisztrálni a rendszert?
• Mennyire lehet a vállalat tesztelési módszereit, annak tulajdonságait modellezni az eszközben?
• Mennyire segíti majd a fejlesztők munkáját? A projektvezetők munkáját? A tesztelők, tesztvezetők munkáját?
• Munkafolyamatokat meg lehet adni benne?
• A vezetőségnek milyen riportokat kell prezentálni? (Egyszerűbb ha már tudja az eszköz ezeket a riportokat, mintsem nekünk kelljen valahogy összebuherálni még azokat kézzel.)

Ezen kívül még biztosan van más szempont is, ami szerint osztályozni lehet egy hibakezelő rendszert. A lényeg, hogy olyan eszközt válasszunk, amelyet mi is és ügyfeleink/partnereink is egyszerűen tudnak kezelni, könnyű és hatékony munkavégzést teremt a fejlesztőknek, tesztelőknek, tesztvezetőknek  és projektvezetőknek egyaránt.

Bug tracker, vagyis hibakezelő, hibakövető rendszer. Szokták még defect tracker-nek is nevezni. A hibakövetés (bug tracking, defect tracking) a fejlesztésnek egy része, melyben a fejlesztők/tesztelők/felhasználók összegyűjtik a szoftverben található problémákat, hibás működéseket. Ez segíti a fejlesztőket abban, hogy a későbbi program verziók pontosabban kiszolgálják a megrendelő által támasztott igényeket.

A programozók a fejlesztésben részt vevő dedikált tesztelőkön kívül külső segítséget  is igénybe vesznek a hibák felderítésben. Elkerülendő az e-mailben, telefonon, szóban bejelentett hibák, a felhasználókkal, tesztelőkkel való több csatornás kapcsolattartás, ezért, hogy minden egyes hibajelentés a megfelelő formában álljon rendelkezésre, hibakezelő rendszert (bug tracker system) érdemes használni. A hibakezelő rendszerekben a fejlesztők kötelezővé tehetnek olyan paramétereket, melyek elősegítik a hibák megértését, megkeresését, kijavítást.

Egy-egy fejlesztésben fontos paraméter lehet:

• Operációs rendszer típusa, verziója
• Böngésző típusa, verziója
• Alkalmazás verziója
• Tesztrendszer neve
• Az alkalmazás moduljának neve
• Funkció neve
• Tesztadat halmaz, tesztadat fájl neve
• ...

Amennyiben rendelkezünk hibakövető rendszerrel, úgy óriásit javíthatunk a fejlesztés minőségén, az előállított termékek, szoftverek használhatóságán.

Issue tracker, vagyis témakezelő, problémakezelő rendszer. Szokták még ticketing system-nek, vagy incident ticketing-nek is nevezni. Olyan rendszer amely megengedi, hogy a fejlesztők/tesztelők/felhasználók/ügyfelek rögzíthessenek különböző problémákat, valamint nyomon kövessék azt amíg meg nem oldódik, le nem záródik. A téma, probléma lehet bármi, egy felhasználói kérdés, szimpla ügyfél által feltett kérdés, egy hiba, egy technikai jelentés, egy dokumentációban való javítás kérése, egy új igény, stb...

A témakezelő rendszer abban segít, hogy a bejelentett témát a bejelentő nyomon tudja követni, milyen státuszban van, ki foglalkozik vele, mikor kap választ rá, mikor fogják kijavítani, mikor fognak vele foglalkozni.

Ilyen rendszert általában az üzemeltetés, support, vagy a help desk szokott használni. Az ide beérkező bejelentéseket különböző szempontok szerint osztályozzák. A bejelentés azonnali fejlesztés igényel, jövőbeli fejlesztési lehetőség, vagy a bejelentést az ügyfélszolgálat, az üzemeltetés fogja megoldani, netán automatikusan megoldódik, vagy egyáltalán nem is kell vele foglalkozni, lezárható.

Míg hibakezelőt általában a fejlesztés időszakában alkalmaznak, addig a témakezelő, problémakezelő előnyeit a fejlesztés utáni időszakban lehet leginkább kihasználni.

Egyébként általában mindkettő alkalmas a másik szerepének betöltésére, tehát egy témakezelőt, használhatunk hibakezelőként, és fordítva. Természetesen a megfelelő paraméterezések, beállítások elvégzése után.

Kedvenc témám. :) Már bocsánat, de kész röhej, hogy a magyarországi IT cégeknél, vagy IT osztályokon nincs használható hibakezelő eszköz. Az ember néha csak a fejét kapkodja, hogy miért nem tudnak egy ilyet beüzemelni.

Amikor egy projekt előkészítés zajlik és megkérdezzük, hogy mégis

• Milyen eszközöket használnak?
• Hogyan kommunikálnak a megrendelővel/szállítóval?
• Min keresztül küldik/kapják meg a hibákat?

A válasz: E-mail, telefon, személyesen megbeszélik. 

Ilyenkor szokott a legelső lépésünk lenni, hogy ajánlunk egy megfelelő hibakövető eszközt. Vagy ha olyan az ügyfél, akkor egyből tesztmenedzser eszközt.

Szóval miért is kell ilyen eszközt használni?

• Egykapus rendszer működtetése
• Minden hiba rögzítésre kerül
• A hibák visszakereshetőek
• A hibák nyomon követhetőek
• A hibák egyértelműen dokumentáltak
• Segíti a menedzsmentet
• Segít a riportolásban, az analitikák összeállításában
• Döntés előkészítő szerepe lehet

Dióhéjban: Egy helyen dokumentált, visszakereshető, nyomon követhető, csoportosítható adathalmazt kapunk, amellyel kontrolált keretek közé szoríthatjuk a fejlesztést és tesztelést.

Hogy mennyibe kerül? Természetesen vannak fizetős eszközök, amelyeknek borsos ára van. De vannak open source eszközök is, melyeket költséghatékonyan üzembe lehet állítani. A milliós nagyságrendtől az ingyenes szoftverekig minden megtalálható a piacon. Válasszuk egy megfelelőt magunknak.

Mi alapján lehet eszközt választani?

Azt hiszem ez egy másik bejegyzés lesz.

Induljunk ki abból, hogy mindenről lehet pontos tesztkörnyezetet csinálni. A kérdés csak az, hogy megéri-e? Lehet bonyolult az alkalmazások csoportja, vagy a rendszernek nagy erőforrás igénye van, esetleg az éles környezetet nem egyszerű modellezni, ebben az esetben egy egyszerűbb környezetet kell felállítani. Egyszerűbbet, de törekedjünk arra, hogy leginkább hasonlítson az éles környezetre.

Mindent megteszek azért, hogy az én projektjeimben ne végezzünk teszteket az éles rendszeren. Viszont (lehet most sokan nem fognak egyetérteni), lehetséges, hogy bizonyos helyzetekben nincs más választásunk és az éles rendszereken kell elvégeznünk egy-két tesztesetek futtatását.

Ha nagyon megerőltetjük magunkat, akkor biztosan tudunk olyan helyzetet mondani, amikor az éles rendszeren is lehet tesztelni.

• Idő, vagy erőforrás hiány miatt nincs tesztkörnyezet.
• Üzletileg nem túl kockázatos funkció tesztelése.
• Riportok ellenőrzése, összevetése a régebbi riportokkal.
• ...

De azt mindig tartsuk szem előtt, hogy az éles környezet nem tesztelésre van, azt a felhasználók használják.