Manapság gyakran látni és hallani olyanokat, hogy valakinek minőségbiztosítási szakemberre van szüksége. A munkakör mibenlétét firtató kérdésre gyakran az a válasz, hogy tesztelés, tesztesetek írása és végrehajtása. Az alábbiakban tisztázni szeretném, hogy miért van itt nagy tévedés, és milyen összefüggésben áll a minőségbiztosítás a teszteléssel.

Minőségbiztosítás kontra tesztelés

A minőségbiztosítás nem azonos a teszteléssel. Sőt, megkockáztatnám azt a szélsőséges állítást, hogy egyik sem része a másiknak. Miért? Több okból is – egyrészt a tesztelés a fejlesztés része kell, hogy legyen, ahogy volt ez akkor is, amikor a minőségbiztosítás fogalmát még nem [sokan] ismerték. Másrészt tesztelni lehet jól és rosszul is, még akkor is, ha dedikált ember teszi.

A minőségbiztosítás egy olyan – jó esetben technikai apparátussal társuló – értéknövelő elv és koncepció, amit a fejlesztési folyamatra kell ráültetni, és annak a lehető legtöbb fázisában alkalmazni. A szoftverfejlesztésben a minőségbiztosítás a követelményelemzésnél kezdődik és a támogatás megszűnésével ér véget. A tesztelés nem a minőségbiztosítás része, hanem a fejlesztési folyamaté, melyre ugyanúgy alkalmazni illene a minőségbiztosítás éppen aktuális koncepcióját, ahogy más életciklusfázisokra is.

A teljesség igénye nélkül íme néhány dolog, ami a minőségbiztosítás fogalmába tartozik:

• A szoftver egyes életciklusokban való megtestesülései (követelmények, rendszertervek, tesztelési tervek, megvalósított szoftver és dokumentáció) közötti konzekvencia és konzisztencia biztosítása – A köztes állapotok egymásból transzformálhatóságának biztosítása. A szoftverben megvalósított funkciók teljes összevethetősége a tervezett funkciókkal így annak biztosítása, hogy valóban azt csinálja az alkalmazás, amit a megrendelő kért
• Változáskezelés és kockázatkezelés – A fejlesztés közben óhatatlanul felmerülő igények és változáskérések kezelhetőségének biztosítása, valamint a kockázatok megfelelő időben való felismerése.
• Ergonómia – A használhatóság, esztétika és más formai jellemzők biztosítása.
• Dokumentációs minőség – A műszaki, illetve a felhasználóknak és üzemeltetőknek szóló dokumentumok és segédanyagok, a forráskódbeli megjegyzések tartalmi és formai minőségének biztosítása. (Olvastam olyan szoftverarchitektúra-dokumentumot, amiben „ha a processz leül, ki kell lőni” és ennél még trehányabb megfogalmazások voltak (például osztáj – sic!), és hát bizony egyik nagy állami intézményünk dokumentumáról van szó, amit az egyik igen nagy és neves szoftvergyártó készített.)
• Támogatási minőség – A támogatási szolgáltatás minőségének biztosítása, SLA kialakítása és betartása, érdemi támogatás nyújtása.
• Belső és külső eljárások megfogalmazása – A hibabejelentés, változáskérés (külső eljárások), illetve a fejlesztési és támogatási mód (belső eljárások) megfogalmazása és betartása.
• Az újrafelhasználhatóság elvének maximalizálása – Gyakorlati refaktoring, megfelelően strukturált forráskód.

Ezek közül csupán egy dolog a teszteléssel kapcsolatos minőségbiztosítás.

Bár tagadhatatlan, hogy minőségi szempontból tesztelésben nem áll jól a magyar informatikai társadalom, ugyanakkor ez sajnos elmondható az ergonómiáról és a dokumentációs minőségről is – és más területeken is lehetne javítani. (Itt kell megjegyezni, hogy kivételek, szép példák szerencsére akadnak.)

Minőségbiztosítás a tesztelésben

Tehát a minőségbiztosításnak annyi köze van a teszteléshez, hogy jobb helyeken illik minőségi tesztelést végezni. Mit is jelent a minőségi tesztelés és mi kell hozzá (szintén a teljesség igénye nélkül)?

Átgondolt tesztelési stratégia – A szükséges erőforrás-szükséglet megfelelő azonosítása, a feladatok és allokációk ütemezése. (Én a tesztelés alapdokumentumát nevezem tesztstratégiai dokumentumnak.)

Praktikus és költséghatékony tesztelési eszköztár – Gyakorlatban jól használható eszközöket, melyek a tesztelést gazdaságosabbá teszik, ezáltal egy adott költségkereten belül alaposabb, szélesebb körű tesztelésre adva lehetőséget.

Vezetői szándék – Hiába a legjobb tesztelési és minőségbiztosítási szakember, ha a cégben hiányzik a minőségi termék előállítására törekvés szándéka vagy a minőségi tesztelés szükségességének megértése. Ha a menedzsment elutasítja a tesztelési apparátus beszerzésének ötletét, korlátozza az erőforrásokat, és – úgy kell mondjam, jó magyar szokás szerint – a minden másra alkalmatlannak talált embereket ülteti a tesztelői gépekhez, akkor hiába a szakértői szándék.

Minőségi tesztszakemberek – Ahogy az előbb említettem, tapasztalható egy olyan elterjedt gyakorlat, hogy aki nem tud [hatékonyan] programozni, azt támogatási vagy tesztmérnöknek teszik meg. Ennél rosszabbat el sem lehet képzelni! A tesztelés saját, jól képzett szakembereket kíván. A tesztesetek megfogalmazásához nagyfokú precizitásra és fogalmazási készségre van szükség. Tudni kell türelmesen leírni akár harmincadjára is szép, kerek mondatokban bizonyos tesztlépéseket – és nem csak akkor, ha a tesztesetekbe az ügyfél is belepillanthat: egy tesztesetet úgy kell kialakítani, hogy a tesztet bármikor, bárki végre tudja hajtani, akár anélkül, hogy gyakorlata lenne a tesztelt szoftverben.

Minőségi tesztelési stratégia

Egy dokumentum sem attól lesz tesztelési stratégia, hogy az a címe. A tesztelés stratégiájaként módszereket, eszközöket, erőforrás-szükségleteket, ütemezést és – a végére hagyva a legfontosabbat – terjedelmet kell meghatározni. Végig kell gondolni, hogy milyen típusú tesztekre van szükség: Van-e értelme a terheléses tesztnek? (A Notepad esetén nem nagyon, hát spóroljunk.) Vannak-e biztosítandó minőségi és teljesítménybeli paraméterek? Van-e értelme migrációs tesztnek vagy adatbázistesztnek?

A tesztelési stratégia körébe tartozik továbbá a tesztelésre vonatkozó minőségi paraméterek meghatározása: milyen lefedettséget kívánunk biztosítani az egyes tesztek során, és mik azok a peremfeltételek, melyek sikeressé vagy sikertelenné tesznek egy tesztet?

További teendők is akadnak még szépen: a tesztadatok és tesztkörnyezet kialakításának módja (akár egy erről szóló jövőbeli dokumentumra való utalás formájában); a tesztelési módszerek és eljárások (automatikus tesztelés vagy manuális tesztelés, hibabejelentés és -kezelés módja) meghatározása.

Ha mindezekről szó esik egy dokumentumban, akkor azt nyugodt szívvel el lehet menteni Tesztelési stratégia névvel.

Csatoltam egy tesztstratégiai sablont, ami a fentieket és a lentieket igyekszik minél hűbben tükrözni – a Nyájas Olvasó használja csak egészséggel!

Minőségbiztosítási irányba mutató praktikák

Végül érdemes szót ejteni arról, hogy néhány konkrét teszttípus és azok teszteseteinek minősége hogyan biztosítható.

Automatikus tesztelés

Sokak által vitatott kérdés, hogy jó-e az automatikus tesztelés. A határozott válaszom úgy hangzik, hogy: attól függ. Ad-e értéket a projekthez vagy csökkenti-e annak költségét?

Automatikus tesztelés esetén a tesztesetek elkészítése többnyire hosszadalmasabb, költségesebb, adott esetben nagyobb szakértelmet igénylő munka, mint a tesztesetek manuális megírása. Ha többször végre szeretnénk hajtani egy tesztesetet, vagy a teszt során több rendszer összehangolt működésére van szükség (például egy elosztott terheléses tesztben), akkor mindenképp érdemes megvizsgálni az automatikus tesztelés lehetőségét. Ha a teszteseteket átlagosan háromszor végre kell hajtani, akkor az automatikus tesztelés már nem lesz drágább, mint a manuális, a gyakorlatban viszont ritka, hogy csak háromszor kelljen tesztelni egy rendszert a végső átadásig.

Modultesztelés (unittesztek)

A unittesztek (vagy ahogy mondani szeretem, magyarul, modultesztek) minőségbiztosítása röviden arról szól, hogy egy egészséges lefedettséget megcélozva gondoskodjunk a funkciók megvalósításában részt vevő metódusok helyességének ellenőrzéséről. A modultesztelésre szerencsére léteznek bevált, elterjedt eszközök (xUnit-család: JUnit és nUnit, a Visual Studio Team Foundation Edition modulteszt-apparátusa és más kezdeményezések).

Fontos ugyanakkor megfogalmazni és kellő szigorral számonkérni a modultesztelési elvet, aminek néhány fontos pontja az alábbi:

• Megfelelően dokumentáltak-e a metódusok, paramétereik és visszatérési értékük? Enélkül a tesztelő nem tud megalapozott tesztesetet írni, ha pedig a fejlesztő írja – amit egyesek jónak tartanak, mások elképzelhetetlennek), akkor is előfordulhat, hogy a fejlesztő másik istállóhoz igazol, ezért ezen oknál fogva a dokumentáltság nem úszható meg.
• Hogyan választjuk ki a 100%-os lefedettséget nyújtó tesztesethalmazból az 50-60%-os lefedettséget biztosító tesztesetet? Üzleti és technológiai kockázat, funkciókövetés (function trace) vagy használati gyakoriság alapján?
• A hibák jelzési, követési és megoldási módja. Ha nem dokumentáljuk a hibákat, csak gyorsan – vagy lassabban – kijavítjuk, fontos mérőszámot veszítünk el, amit a fejlesztési módszer és a fejlesztők utóértékelésénél fontos lenne ismerni.

Funkcionális tesztelés

Egy közepes méretű üzleti alkalmazásnál alig találni minden szempontból teljesnek nevezhető teszteset-gyűjteményt, ha manuális tesztelést végeznek. Ha például egy beviteli mezőt tesztelünk, akkor egy helyes és egy helytelen érték kipróbálása még nem nevezehető teljes körű vizsgálatnak – ha viszont van egy automatikus tesztelési eszköz, akkor kis befektetéssel írható olyan paraméterezhető szkript, amit több helyes és helytelen értékkel meghívva szélesebb körű, minőségi tesztelést lehet végezni.

Szintén nevezhetjük tesztelési minőségbiztosítási kérdésnek azt a problémát, hogy hogyan állapítjuk meg, hogy minden követelmény teljesülését teszteljük-e? Úgy alakítottuk-e ki fejlesztési módszerünket, hogy tisztában vagyunk minden követelményelemmel, egyáltalán, tettünk-e azért valamit, hogy az elkészült szoftver jó eséllyel tükrözze az eredeti követelményeket? Egy ezt biztosító módszerről egy következő cikkben fogok írni.

Felületteszt, használhatósági teszt vagy ergonómiai teszt

Gyakran kihagyott teszttípus az ergonómiai teszt, amit felülettesztnek és használhatósági tesztnek is nevezhetünk – tulajdonképp az ergonómiai teszt a felületi logika és a használhatóság más szempontjainak együttesét vizsgálja. Manapság sajnos inkább csak webhelytervező cégeknél szokás ilyeneket végezni, ahogy az ergonómia egész kérdésköre is legfeljebb olyan cégeknél jelenik meg, akik fél lábbal a marketingiparban is tevékenykednek.

Az ergonómiai tesztek során – szokás szerint a teljesség igénye nélkül – az alábbi tényezőket kell megvizsgálni és értékelni:

• A felhasználói felületen megjelenő gombok és más parancskiadásra alkalmas vezérlők mindegyike mögött van-e tényleges funkció? (Van-e olyan gomb, ami nincs „bekötve”?)
• Minden vezérlő rendelkezik-e hívóbillentyűvel (ALT+billentyű)? Minden gyakori funkciónak van-e billentyűparancsa (például CTRL+billentyű), és azok logikusan vannak-e meghatározva (például Windows rendszerben a másolás nem CTRL+V lett-e a szabványos CTRL+C helyett)?
• A TAB és SHIFT+TAB billentyűparancsokkal logikus sorrendben járhatók-e be az ablakok és párbeszédpanelek? (Kiváló antipélda az Enterprise Architect, ahol a TAB össze-vissza ugrál.)
• Nyelvileg helyesek-e a feliratok és üzenetek?
• A hosszabb folyamatokat jelzik-e folyamatjelzők vagy üzenetek és az egérmutató, illetve utóbbi utal-e az egérrel az adott pillanatban vagy ponton elvégezhető műveletre?
• A különböző felsorolások (listák, táblázatok stb.) elemei ésszerűen vannak-e sorbarendezve, illetve ahol a rendezhetőség és szűrhetőség követelmény, ott működik-e a rendezés és szűrés?
• Megszakíthatók-e ésszerű helyen az egyes műveletek (pl. az adatok mentése nélkül bezárható-e egy párbeszédpanel)?
• Megjelennek-e és megfelelőek-e a vezérlők eszköztippjei?
• Ha már előállt a felhasználói dokumentáció, az szinkronban van-e a szoftverrel?

Teljesítménytesztek

Végül álljon itt néhány rövid gondolat a minőségi teljesítménytesztről. A teljesítménytesztek során alapvetően háromféle dolgot vizsgálhatunk:

• Névleges kapacitás mérése – A névleges kapacitás mérése során bizonyos funkciók minőségi jellemzőit mérjük normál terhelés esetén. Ilyen minőségi jellemzők a metódusok és összetettebb üzleti funkciók végrehajtási ideje, memóriaigénye, processzorigénye, metódushívásai száma stb. Ezt klasszikusan profilereszközökkel (Visual Studio Profiler, SQL Server Profiler, AQtime stb.) lehet mérni
• Terheléses teszt – Ennek során a rendszer válaszidejének alakulását vizsgáljuk a terhelés növekedésének függvényében. Szintén profilerekkel mérhető értékek, a tesztek végrehajtásához pedig már szükség lehet automatikus tesztelési eszközökre, hogy a megfelelő forgatókönyveket elosztott környezetben koordináltan végre lehessen hajtani.
• Skálázási teszt – A skálázási tesztben a rendszer válaszidejének alakulását azonos terhelés mellett a skálázás függvényében vizsgáljuk. Hogyan reagál a rendszer arra, ha a kiszolgálófürt egy taggal bővül, hogyan viselkedik az adatbázis egy kevésbé terhelt és nagyobb kapacitású lemezen elhelyezett adatbázis esetén stb. A tesztekhez szintén profilereket használhatunk.

Végül

Bízom abban, hogy aki végigolvasta ezt a tanulmányméretűre kerekedett cikket, és nem volt teljes mértékben tisztában a tesztelés és a minőségbiztosítás kapcsolatával, esetleg nem volt benne biztos, hogyan kezdjen neki a minőségi tesztelés megtervezésének, meg hogy bárki, aki elolvasta, gazdagodott néhány hasznos tapasztalattal. Remélem, hogy sikerül lassacskán kiírtani azt a képzetet a magyar informatikus társadalomból, hogy a minőségbiztosítás és a tesztelés egy és ugyanaz, mert ez egyik területnek sem tesz jót, de különösen nem tesz jót a megrendelőnek és a gyártónak sem ez a felfogás.

A koncepció és a praktikus tanácsok megalkotásában nagy segítségemre volt az elmúlt bő fél év, ami alatt folyamatosan elláttam néhány projekt tesztkoordinátori szerepét.