Szoftvertesztelés

Nagyon sokan beleesnek abba a hibába, hogy lebecsülik a tesztkörnyezet fontosságát. Leginkább ez kisebb projekteknél van így, de sokszor bele lehet futni a nagyobbaknál is. A tesztkörnyezet felállítása, karbantartása természetesen plusz munkát jelent a környezetek üzemeltetőinek, a fejlesztőknek, menedzsereknek. Körülbelül itt be is lehet fejezni a hátrányok sorolását. :)

Nézzünk pár előnyt:

A tesztelők és a fejlesztők munkája teljesen elkülönül egymástól. Ha ugyanazon a környezeten kell dolgozniuk a tesztelőknek és a fejlesztőknek, a tesztelők munkája gyakorlatilag semmit sem ér. Időpocséklás az egész, mivel mialatt tesztel, azalatt megváltozhat alatta az alkalmazás. Így az addig lefuttatott tesztjei érvényüket vesztik, a tesztelő kezdheti elölről a munkáját.

Folyamatosan kontroll alatt lehet tartani a tesztkörnyezetre kikerült alkalmazás verziókat. Így a hibák rögzítésénél pontosan meg lehet jelölni, melyik verzió, melyik funkciójánál találtuk meg a hibát. Az új verziókat a fejlesztőknek illik dokumentálni, hogy abban milyen új funkciók kerültek bele, illetve milyen eddig ismert hibákat javítottak ki. Ez segít a tesztelőknek az adott verzió feladataira koncentrálni.

A verzió számot ismerve a fejlesztőnek pofon egyszerű lesz ismét előidézni a hibát, megtalálni az okát és kijavítani. Ha egy környezeten van a fejlesztés és tesztelés, akkor az egyes verziók nem tudnak elkülönülni egymástól, egyes hibák okát nem lehet majd kideríteni. (Megjegyzem pont azok a hibák a legrosszabbak, amelyek nem reprodukálhatóak, látszólag kijavultak.)

A tesztkörnyezetre célszerű stabil verziókat kitenni, hogy amíg a fejlesztés dolgozik, addig a tesztelők is tudjanak haladni a munkájukkal. Így ha a következő verzió instabil, kritikus hibákkal van teli, akkor a fejlesztés egyszerűen tovább dolgozhat anélkül, hogy a tesztelést nagy mértékben hátráltatná a feladataiban. (Általában az szokott előfordulni, hogy az egyes verziókat idő hiányában nem tudják teljesen leellenőrizni a tesztelők, az új verzió már készen van, a fejlesztők már tesztelésre akarják adni. Egy hiba kijavítása legtöbbször kevesebb időbe telik, mint a teljes körű tesztelése, ellenőrzése.)

Nem utolsó sorban a tesztadatok is tiszták maradhatnak. Míg a fejlesztők tesztelnek a saját adataikkal a fejlesztő környezeten, addig a tesztelők sokkal életszerűbb adatokkal dolgozhatnak. Akár az éles környezetről lehet adatokat migrálni, ezáltal is precízebb tesztelést elérni.

Azt már le sem merem írni, hogy igazából több tesztkörnyezetet is lehetne egymás mellett üzemeltetni. Egyiken integrációs tesztek folyhatnak, másikon funkcionális, harmadikon terheléses, stb.

Sok esetben ez csak álom marad.....

Az alkalamzások beszerzésénél sokszor szóba kerülnek az open source termékek. Legfontosabb tulajdonságuk az ingyenesség, a legnagyobb hátrányuk a nem megfelelő support. Általában ezen két dolog mérlegelése után dönt sok vállakozás az open source termékek mellett, vagy ellen. 

Igényfelmérés

Először is tisztázzuk, hogy milyen feladatra kívánjuk igénybe venni a leendő eszközt. Pontosítsuk a követelményeinket! Megfelelő igényfelméréssel sok pénzt takaríthatunk meg. Nem mindegy, hogy milyen kialakult struktúrába szeretnénk beleilleszteni az eszközt, milyen folyamataink vannak, milyen emberek fogják használni az alkalmazást.

Ha már tudjuk az igényeinket, akkor lehet kezdeni összegyűjteni a potenciális szoftvereket. Célszerű open source, alacsony költségű és piacvezető eszközöket összehasonlítani, hogy pontosan tisztában legyünk az ár-érték aránnyokkal.

Fizetős szoftverek keresése

Magyarországon a piacvezető eszközök mindegyikének van értékesítője. Elég őket felhívni máris csapatostul mennek ki a leendő ügyfélhez prezentálni az alkalmazás előnyeit, a kiegészítő szolgáltatásokat. Megfelelő összegért megkapjuk a kívánt szoftvert és igény szerint be is állítják a vállalati környezetbe.

Létezik megfelelő open source eszköz?

Olvassunk teszteszközökkel foglalkozó fórumokat, blogokat. Keressünk rá mások milyen szoftvereket használnak, olvassuk el a véleményüket. Kérjünk tanácsot megfelelő szakembertől, hogy ő milyen eszközöket ismer, melyiket használta, milyen tapasztalatokat gyűjtött. Biztos vagyok benne, hogy pár nap alatt találunk 3-4 olyan teszteszközt, amelyre érdemes elvégezni az ár-érték elemzést.

Amennyiben open source szoftvert választunk, úgy tudomásul kell venni, hogy azt telepíteni, konfigurálni, beállítani nekünk kell. Nincs support, akit zaklatni lehetne különböző kérdésekkel. A felmerült problémákat saját magunknak kell elhárítani.

Döntés

Bárhogy is döntsünk, ha foglalkozunk a szoftverteszteléssel és megpróbáljuk segíteni a tesztelési folyamatot egy eszközzel, máris nagy lépést tettünk meg a minőségi szoftverkészítés irányába.

---

Egyéni vélemény

Eddigi tapasztalataim alapján a fizetős szoftvereket általában nagyvállalatok engedhetik meg maguknak. Pláne igaz ez ha szoftvertesztelésről beszélünk.

Sok közepes cég viszont saját fejlesztésű szoftvert gyárt ahelyett, hogy open source terméket venne igénybe. A döntés oka, hogy nincsenek tisztában az open source eszközök tudásával, szolgáltatásaival. Félnek bevezetni egy ismeretlen eszközt.

Ha kellő figyelemmel választjuk ki az open source eszközt, akkor sok kockázatot csökkenthetünk.

Az első részben szó volt arról, hogy gyakorlati oktatást kell adni a tesztelőknek. Hogyan lehet ezt megvalósítani?

Amennyiben van rá lehetőség, akkor próba projekten kell kitapasztalni a tesztelői affinitást. Ez a projekt lehet egy üzleti szempontból kis prioritású alkalmazás, vagy netán egy teljesen belső projekt. Belső projektnek nevezem azt a szoftverfejlesztést, melynek végtermékét vállalaton belül fogjuk használni. Itt is figyelembe kell venni azonban, hogy ne olyan funkció tesztelését adjuk oda a betanítandó munkatársnak, amely kritikus a vállalkozás működését tekintve, hanem inkább a periférián lévő modulok, funkciók ellenőrzését bízzuk rá.

Ha találunk ilyen projektet, akkor nagy szerencsénk van, ugyanis meg van oldva a projekt szimuláció. Amennyiben nincs projekt, viszont az erőforrást be kell tanítanunk, na akkor már egy kicsit nehezebb a helyzetünk.

Mi régebben úgy oldottuk meg, hogy vettünk egy lefutott projektet. Ennek a projektnek a verzióit egy verziókezelő rendszerben tároltuk, amelyből visszafelé elkészítettünk 4-5 buildet. Ezeket a buildeket meghatározott időközönként kitettük a tesztelendő környezetre. Volt egy tesztmenedzser eszközünk, melyben a tanulók felvették az adott verzió hibáit. (Nem találtak olyan hibát, melyet mi azelőtt ne kaptunk volna el.) A hibák a következő verzióban vagy kijavultak, vagy úgyanúgy szerepeltek benne. Az egész szimulációhoz 1 ember kellett, akit mi vezető fejlesztőnek hívtunk. Ő tette ki az új verziókat, buildeket, válaszolt a hibákra, állította a hibák státuszát, stb... Napi 2-3 órás munkájával 4-5 embert tudott folyamatosan oktatni, feladattal ellátni.

Ha a tesztelőket csoportokba szervezzük, akkor a csoportmunkát is megtanulhatják egycsapásra. Feladatok leosztását, egymásra figyelést, csoportos munkavégzést.

Ha minden kötél szakad, akkor ilyennel is lehet próbálkozni. Persze egy komolyabb cég életében szinte kizárt, hogy ne legyen bármilyen belső fejlesztés. Viszont ha nincs, akkor segíthet egy ilyen szimuláció.

Miben jobb a szimuláció egy új fejlesztésnél?

Egy dologban biztosan. Ha össze tudjuk hasonlítani a két hiba adatbázist (az eredetit és a tanulóit), akkor különböző kérdésekre kaphatunk válaszokat.

• Megtaláltak-e minden hibát az egyes verziókban?
• Milyen típusú hibák nem kerültek elő?
• A hibaleírások mennyire hasonlítanak az eredetiekre?

Ezekre a kérdésekre adott válaszok abban segítenek, hogy meglássuk az új generáció hibáit, hátrányait. Esetleg ezeken még az élesbe kerülés előtt javíthassunk. Akár elméleti, akár gyakorlati oktatással.

Folyamatos kihívást jelent egy projektben a határidők tartása. Általánosan elmondható, hogy a szoftvertesztelés kevesebb időt kap már a projekt előkészületében, mint amennyit a tesztelők, tesztvezetők eredetileg igényelnek. Erre még pluszban jön a projekt ideje alatti csúszások, míg végül azzal állunk szemben, hogy 1 nap alatt kellene 5 napnyi munkát elvégezni. Az egész ahhoz vezethet, hogy a tesztelőkön megnőhet a nyomás, felületessé válhat a munkavégzésük. Haladni szeretnének a tesztek futtatásával, de nem a megfelelőeket veszik előre, ami miatt súlyos hibák kerülhetnek az éles rendszerre.

Hogyan lehet ebből a dugóhúzóból kikerülni?

Priorizáljuk a teszteket. Jelöljük meg minden egyes tesztesetet, hogy mennyire fontosnak véljük a lefuttatását. Amint látszódik, hogy a munka nem áll összhangban a hozzá tervezett idővel, úgy a legfontosabb (legmagasabb prioritású) teszteket kezdjük el futtatni, majd haladjunk az alacsonyabb prioritás felé.

Mit érünk el vele?

A tesztelni kívánt alkalmazás nagyobb eséllyel lesz üzemképes. A lényeges funkciók működőképesek lesznek, azokban hibák, hibás működés nem fog előfordulni. Amint vége a hajtásnak, le lehet futtatni az alacsonyabb prioritású teszteket is.

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.