Tesztelési alapelvek

Ha egy teszt hibát tár fel, bizonyítékot kapunk arra, hogy a vizsgált munkatermékben probléma van. Ha sok tesztben nem találunk hibát, az jó hír a kipróbált helyzetekről, de nem bizonyítja, hogy minden lehetséges bemenetben, állapotban és környezetben helyes a működés. A tesztelés csökkentheti a rejtve maradó hibák kockázatát, teljes bizonyosságot azonban nem ad.

Képzeld el, hogy egy regisztrációs űrlapot három életkorral próbálunk: 17, 18 és 19 évvel. Mindhárom eredmény megfelelő. Ettől még lehet hiba hiányzó dátum, rossz formátum vagy eltérő időzóna esetén. A pontos megfogalmazás tehát nem az, hogy 'a regisztráció hibátlan', hanem hogy 'ezekben az ellenőrzött esetekben nem figyeltünk meg eltérést'.

Egy egyszerűnek látszó űrlapnál is sokféle bemenet, böngésző, jogosultság, időpont és hálózati állapot kombinálódhat. Ha mindent mindennel kipróbálnánk, a vizsgálandó esetek száma gyorsan kezelhetetlenné válna. Kivételek lehetnek egészen apró, véges rendszerek, de valódi alkalmazásoknál általában választanunk kell. Ezért nem az a kérdés, hogy 'teszteltünk-e mindent?', hanem hogy az időnkben a legfontosabb esetekre koncentráltunk-e.

A választást a kockázat, a funkció használatának gyakorisága, a hiba lehetséges hatása és a teszttervezési módszerek segítik. Egy online jelentkezésnél érdemes elsőként a határidő körüli beküldést, a mentést és az ismételt küldést vizsgálni. A kevésbé fontos kozmetikai eltérések is rögzíthetők, de nem feltétlenül előzik meg az adatvesztés ellenőrzését. A kiválasztott mintáról és a nem vizsgált részekről is tudni kell beszámolni.

Nem kell megvárni a kész programot. Egy követelmény vagy képernyőterv áttekintése is feltárhat hiányt: pontosan kit tekintünk jogosultnak, mi történik hibás bemenetnél, hogyan jelezzük a sikert? Ha ezeket a kérdéseket még a megvalósítás előtt tisztázzuk, kevesebb hibás feltételezés kerülhet tovább a tervekbe, a kódba és a tesztesetekbe. A korai ellenőrzés lehet statikus, tehát a program futtatása nélkül végzett vizsgálat.

Tegyük fel, hogy a követelmény szerint 'az előfizető kedvezményt kap', de nem mondja meg a kedvezmény mértékét és a jogosultság kezdetét. Ha ezt a tesztelő a tervezéskor jelzi, a csapat pontosíthatja a szabályt. Ha a kérdés csak kiadás előtt merül fel, több egymásra épülő rész módosulhat: árképzés, számlázás, üzenetek és meglévő tesztek. Az alapelv nem számszerű garancia minden projektben, hanem gyakorlati ok arra, hogy minél korábban kérdezzünk.

A felfedezett hibák gyakran nem egyenletesen oszlanak el: egyes összetett vagy gyakran változó részekben több probléma jelentkezik. A korábbi hibajegyek, a módosítások és az üzemeltetés tapasztalatai ezért segítenek meghatározni, mely részeket vizsgáljuk alaposabban. Az alapelv nem azt állítja, hogy egy konkrét rendszerben mindig ugyanaz a modul hibás, vagy hogy a többiben nem lehet gond.

Ha egy kedvezményrendszerben több eltérés van a kupon és az áfa együttes számításában, érdemes közeli eseteket keresni: kerekítés, visszatérítés, több kupon, eltérő pénznem. A tesztterv így a megfigyelt kockázatra válaszol. Ugyanakkor egy új funkció vagy átalakított modul később más területre helyezheti a hangsúlyt; a hibacsoportokat időről időre újra kell értékelni.

Ha változatlan tesztadatokkal és lépésekkel sokszor ismételjük ugyanazt az ellenőrzést, az új hibák megtalálásában egyre kevesebb segítséget adhat. A termék közben fejlődik, új szabályok és új használati szokások jelennek meg. Az eredeti teszteket ezért célszerű felülvizsgálni, új adatokkal kiegészíteni, és szükség esetén új teszteseteket írni. Az alapelvet olykor 'peszticidparadoxonként' is említik, de a lényeg a tesztek megújítása.

Fontos kivétel: egy stabil automatikus regressziós tesztet továbbra is érdemes újra és újra futtatni. Az ilyen teszt gyorsan észreveheti, ha egy már ismert működés elromlik egy változtatás után. A 'tesztek kopnak' tehát nem azt jelenti, hogy a régi tesztek értéktelenné válnak; azt, hogy önmagukban nem feltétlenül találnak meg minden új problémát.

Nincs minden helyzetben ugyanolyan jó tesztelési recept. A rendszer célja, a felhasználók, a kockázatok és az elfogadható következmények határozzák meg, milyen ellenőrzés szükséges. Más szempontok lesznek elsődlegesek egy egyszerű iskolai eseménynaptárban, mint egy banki átutalást kezelő rendszerben. A két szoftvernél egyaránt számít a helyesség, de a hiba hatása és a szükséges bizonyíték mélysége eltér.

A környezethez tartozik a használt eszköz, a kapcsolódó szolgáltatás és a felhasználói folyamat is. Egy tanári tananyagtárnál fontos lehet a mobil olvashatóság, a keresés és a fájlletöltés. Egy sürgősségi rendszerben emellett különösen nagy súlyt kaphatnak a biztonsági és rendelkezésre állási kérdések. Az alkalmazott tesztek kiválasztását mindig a konkrét célhoz indokoljuk.

Egy rendszer teljesítheti az összes leírt követelményt, és a tesztekben mégsem találnak eltérést, miközben a felhasználó alapvető szükségletét nem oldja meg. Lehet, hogy maga a követelmény hiányos, elavult vagy rosszul értelmezett. A követelmények teljesülésének ellenőrzése mellett ezért a felhasználói igény és az üzleti cél teljesülését is vizsgálni kell. Ezt az alapelvet a hibamentesség téves következtetésének is nevezik.

Például egy időpontfoglaló rendszer pontosan ment minden előírt mezőt, de nem engedi a foglalás módosítását, pedig a felhasználók számára ez nélkülözhetetlen. A 'minden teszt zöld' ebben az esetben csak azt mutatja, hogy a megírt tesztek és a leírt szabályok összhangban vannak. A termék sikeréhez a megfelelő célt is ellenőrizni kell: egyeztetés a felhasználókkal, valódi használati helyzetek kipróbálása és a követelmények szükség szerinti módosítása.

Vegyünk egy online kurzusfelvételi rendszert. A követelmény átnézésével már korán rákérdezünk a létszámkorlátra (korai tesztelés). A jelentkezések minden lehetséges sorrendjét nem tudjuk kipróbálni, ezért a megtelt és majdnem megtelt kurzust előre vesszük (teljes körű tesztelés lehetetlensége). Ha sok hiba a várólistán jelentkezik, ott több esetet vizsgálunk (hibák csoportosulása). Ezek nem külön versengő szabályok, hanem ugyanannak a teszttervezésnek más-más szempontjai.

Kiadás után új előjegyzési szabály érkezik: frissítjük a teszteket, miközben a korábbi beiratkozási ellenőrzések tovább futnak (a tesztek megújítása). A diákok többsége telefonon jelentkezik, ezért mobilon is vizsgáljuk a fő folyamatot (környezetfüggőség). A sikeres tesztek sem fedhetnek le mindent (hibák jelenlétének elve), és külön megkérdezzük, hogy a diák számára átlátható-e a várólista (a hibák hiánya nem elég).

'Nem találtunk hibát, tehát nincs hiba' – ezt nem állíthatjuk: csak a vizsgált esetek eredményéről van bizonyíték. 'Mindent teszteltünk' – legfeljebb a megállapodott, véges esethalmazt futtattuk le. 'Csak a kész programot lehet tesztelni' – egy követelményt vagy tervet is ellenőrizhetünk. 'Minden modulra ugyanannyi teszt kell' – a kockázat és a korábbi hibák eltérő mélységet indokolhatnak.

'Ha a tesztek kopnak, a régieket ki kell dobni' – a régi regressziós tesztek védhetik a jól működő részeket; új kockázat mellé új esetet írunk. 'Egy minden projektre kész tesztlista elég' – a felhasználók és a körülmények mások. 'Ha nincs nyitott hiba, a felhasználó biztosan elégedett' – az igények teljesüléséről külön visszajelzésre van szükség. Ezeket a kijelentéseket a saját feladatodon is próbáld helyes, bizonyítható mondatokká alakítani.