Tesztlefedettség – Ipari szabványok

Tesztlefedettség alatt sokmindent érthetünk. Általában a kódsorok lefedését és a lehetséges utak lefedését értik a tesztelők alatta. De hogy egyszerre mindkettőre gondoljunk, erre szinte alig van példa. 

A Minőségbiztosítási/Tesztipar mostanság el lett árasztva azzal a kényelmesnek vélt koncepcióval, melyre csak úgy utalunk, hogy Tesztlefedettség. Koncepciónak nevezem, mivel egy, a menedzsment fejéből kipattant gondolattal kezdődik, ott náluk le is ragad, majd végül a tesztelőnek adják, hogy végrehajtsa a megadott feladatokat.

És még mielőtt észbe kapnának, az elképzelés egy grafikai reprezentáció formájában ölt alakot, amire sokan csak úgy utalnak, hogy Üzleti analízis. Ez azt hivatott reprezentálni, hogy a jelenlegi tesztek, melyeket bevezettek/létrehoztak vagy a kód „X” sorát fedik le, vagy az üzleti rész „Y” számát, de mindkettőt általában nem.

A kérdés a következő: ez egy korrekt reprezentációja a teljes forgatókönyvnek, melyben a tesztek lefedettsége mérhető? És nem pedig az, ahogy a tesztmenedzser vagy a fejlesztési menedzser – aki már kellően sok energiát fektetett bele – szeretné elképzelni. Az előbb leírtak téves képet adnak egy olyan fontos probléma kezeléséről, mint a tesztlefedettség. A tesztelés egy olyan koncepció, ahol ellenőrizzük, hogy üzleti/felhasználói szemszögből minden megfelelően működik-e, míg a tesztlefedettségnek mindkettőre figyelnie kell – a felhasználói és a fejlesztői nézőpontra is.

Engedd meg, hogy végigvezesselek egy tipikus „Szoftvertesztelési életcikluson”. A követelmények egy HATALMAS adag dokumentum formájában érkeznek, melyek számos iteráción és felülvizsgálaton estek át üzleti és az érintett befektetői részéről (de legritkábban a tesztcsapattól).

Ez a gondosan összeállított csomag egy hivatalos ceremónia keretén belül kerül a tesztelőcsapat birtokába, amit úgy nevezünk: „Az életciklus kezdete”. A tesztmenedzser keresztülrágja magát ezen az örömteli dokumentáción, és a „korábbi” tapasztalatai alapján megbecsüli, hogy mi mindent kell tesztelni, és mely tesztesetek tekinthetőek nagyjából késznek. Ezt „Becslési periódusnak” nevezzük, és egy durva becslést ad, hogy mikor fog elkészülni a tesztelőcsapat – figyelembe véve az automatizálást, manuális tesztelést, a teljesítményt és a biztonságot.

A „Becslési periódus” végeztével a feladat a vezetőkhöz kerül felosztásra és becslésre, de immáron a tesztmenedzser által biztosított dokumentum alapján. Egészen mostanáig a csapat többi tagja nincs is bevonva, és majd a csapatok megbízott vezetői döntik el, mit csinálnak a beosztottjaik. A dokumentáció végre kezd körvonalazódni, amit a kényelem kedvéért úgy nevezünk, hogy „Tesztterv” vagy „Tesztelési stratégia”. Ez hamarosan a tesztelő csapat arany Bibliájává/Védájává válik, és ehhez kell igazodni. És ezennel hivatalosan is kezdetét veszi a szoftvertesztelési életicklus.

Miután az Üzleti követelmény dokumentációt vagy a Termék követelmény dokumentációt a teszteseteidhez igazítottad, hozzá is foghatsz ezeknek a folyamatba való bekötéséhez. Ez az a pont, ahol elkezdesz olyan koncepciókat is bevonni, mint a tesztmátrix és a tesztvektorok, amely laikus szóhasználattal (fejlesztői nyelven) annyit tesz, hogy a tesztek az alkalmazás nézeteinek különböző adatkapcsolati pontjai köré vannak strukturálva.

És most jön a legjobb rész! Itt bújik meg a Tesztlefedettség néven ismert bűnös, amikor jön a felettes tesztelő és közli, hogy a kód „X” során vagy az üzleti rész „Y” számán végzünk tesztlefedettséget (GUI alkalmazásoknál, amik általában a tesztelt alkalmazások 90%-a). De tudja egyáltalán, hogy mit is fedett le a teszteseteivel? Néhányuk tudja, míg mások csak feltételezik egy ilyen cikk elolvasása után vagy a felettesük jóváhagyása után, aki talán szintén ilyen helyekről szerezte tudását. A teszteseteket szétválogatják, majd egy részük az automatizálásért felelős csapathoz kerül, hogy a regressziós folyamatba iktassák, másik részük pedig a „Hiba életciklusa” folyamatba kerül! (Hogy ez egységesen mit is jelent a szétszórt csapatoknak, nagyban függ attól, hogy a menedzsment mennyit költött egy jó hibakövető alkalmazásra. Az én javaslatom Joel Spolsky „FogBuzz” (http://www.fogcreek.com/fogbugz/) blogjának megtekintése. De tegyen mindenki belátása szerint.

Miután megvannak a tesztesetek és bevágták őket az automatizált tesztkörnyezetbe, ráveti magát a tesztmenedzser, és egy rakás gombot nyomkod végig a konzolon (amit a csapata készített neki, hogy az egész egy sétagalopp legyen a számára, vagy pedig a menedzsment áldozott valamivel többet azokra az igazán hatékony alkalmazásokra). És már meg is született a gyönyörűen színezett jelentés arról, hogy mi sikerült és mi nem, és különösképpen „Mennyi kód/felület volt lefedve a teszt során”. Az igazi szépség a menedzsment számára!

De valójában mennyire is hasznos egy ilyen jelentés? Az én őszinte véleményem szerint semennyire! Jó munkát végeztünk a kódsorok lefedésében, de lefedtük az utakat is, melyeken keresztül végrehajtják a kódot? Erre szerintem még az esetek 25%-ában sem gondolnak. Biztosan lefedtük a határértékeket is? Lehet, hogy néhány teszteset biztosította ezt, de lefedtük volna az egészet? Gondoskodtunk-e azokról a végleges értékekről, amelyek a képernyőn bizonyos mezőkben megjelenhetnek? Nem, ez többnyire egy garantált hiány.A következőt tettük:

• Biztosítottuk, hogy a kódsorok legalább 85-90%-a le van fedve a teszteseteinkben automatizált scripteket használva (Remek! Ez probléma lehet alapos manuális tesztelésnél, szóval nem kell megsértődni).
• Biztosítottuk, hogy minden GUI képernyő le van fedve.

De biztosra mentünk, hogy azon a raszteren minden egyes mezőérték le van fedve? Általában nem! Ezek azok a területek, ahol hibákba futunk. És többnyire a „Negatív tesztelésként” ismert fogalom sem kap kellő figyelmet ilyen esetekben.A szokásos problémák:

• Nincs elég idő
• Nem olyan fontos, hiszen ilyen eset nem történhetne a gyártás során.

De ezek fontos dolgok, és hozzájárulnak a tesztjeink lefedettségéhez. Ebben a cikkben főleg arra hívtam fel a figyelmet, hogy mi az, amit nem tesztelnek és/vagy milyen rosszul tesztelnek dolgokat. A jövőben érdemesebb körültekintőbben eljárni a különböző teszteszközök esetén.

Forrás:http://testingcircus.com/Documents/Testing-Circus-Vol2-Issue12-December-2011.pdf

Szerző: Gagneet Singh