Hogyan tehetünk eleget a tervezési céljainknak?

A tapasztalat szerint egyes rendszerrészekben több hiba fordul elő, mint másutt. Ha egy összetett fizetési modulban sorozatosan találnak hibákat, indokolt lehet ott több különböző bemenettel, állapottal és környezettel próbálkozni. A korábbi hibajegyek segítenek megtalálni a kockázatos területeket, de nem bizonyítják, hogy a többi rész hibamentes.

A termék változik, ezért a hibák eloszlása is változhat. Az új funkció, az új felhasználói szokás vagy a megváltozott környezet más hibákat hozhat felszínre. Ha mindig csak ugyanazokat a teszteket ismételjük, egy idő után kevés új információt kapunk. Ezért a teszteseteket és a tesztadatokat időnként felül kell vizsgálni. A stabil, automatizált regressziós ellenőrzések ismétlése ugyanakkor továbbra is hasznos.

A tesztelő reprodukálható eltérést figyel meg, leírja a lépéseket, a környezetet, a bemenetet, az elvárt és a tényleges eredményt. A hibakeresés során a hiba okát keresik: naplókat, adatokat és kódot vizsgálnak, majd megszüntetik a megtalált hibát. A kettő összekapcsolódik, de külön tevékenység.

Javítás után megerősítő teszttel ellenőrzik, hogy az eredeti probléma valóban megszűnt-e. Regressziós teszttel azt vizsgálják, hogy a módosítás nem okozott-e máshol új problémát. Ha például a kedvezmény számítását javították, érdemes az eredeti kedvezményes rendelés mellett a normál rendelést és a végösszeg kiszámítását is újra ellenőrizni.

A sikeres tesztekből azt mondhatjuk, hogy az ellenőrzött esetekben a rendszer a megadott elvárás szerint viselkedett. Nem következik belőlük, hogy minden lehetséges esetben hibátlan. A nem talált hiba mögött lehet jó minőség, de hiányos tesztadat, nem megfelelő környezet vagy gyenge tesztterv is.

Még a jól működő program sem biztos, hogy használható vagy elfogadható a felhasználónak. Egy alkalmazás pontosan számolhat, de olyan munkafolyamatot támogathat, amelyre az ügyfélnek nincs szüksége. A követelmények teljesítésének ellenőrzését ezért ki kell egészíteni a felhasználói igények vizsgálatával. A következő órán a tesztelési alapelveket önállóan is rendszerezzük.

Ha egy modulban ismétlődően találnak hibát, indokolt ott több bemenettel, több állapotból és több környezetben vizsgálódni. Például egy kedvezményrendszerben előforduló több árképzési hiba után nem elég ugyanazt a rendelést újra megnyitni: meg kell nézni az egyidejű kedvezményeket, a kupon lejáratát, a kerekítést és a visszatérítést is. A korábbi hibák tehát nyomok a teszttervhez, nem teljes térkép a rendszer minden hibájáról.

A hibák megjelenése idővel változik. Javítások után a régi eltérések eltűnhetnek, új funkciókban vagy a kapcsolódó rendszerekben mások keletkezhetnek. Ha ugyanazok a tesztek sorra sikeresek, az jelezheti a rendszer javulását, de azt is, hogy a tesztjeink már nem célozzák az új kockázatokat. A tesztkészletet ezért tudatosan frissítjük: új adatot, új üzleti szabályt és új használati mintát veszünk fel.

A tesztelés feltárja és dokumentálja az eltérést: bemenet, lépések, elvárt és tényleges eredmény, környezet. A hibakeresés (debugging) a megfigyelésből kiindulva megkeresi és megszünteti a hiba okát a munkatermékben. Ha egy szoftver 0 forintot számláz a második kupon után, a tesztelő rögzíti a helyzetet; a hibakereső a számítás menetét és az adatok átalakulását vizsgálja. A hibajavítás utáni teszt ismét bizonyítékot gyűjt.

A javítás ellenőrzése két külön kérdést tesz fel. A megerősítő teszt szerint az eredetileg hibás eset most helyes? A regressziós teszt szerint a változtatás nem rontott el egy másik, korábban működő esetet? Például a második kupon elutasításának javítása után az első érvényes kupon elfogadását és a végösszeg számítását is ellenőrizzük. A 'javítottuk' állítás nem helyettesíti ezeket a megfigyeléseket.

Ha a vizsgált esetekben nem találtunk hibát, csak a tesztelés határain belül tudunk állítást tenni. Lehet, hogy valóban kevés a hiba; de az is lehet, hogy fontos esetek hiányoznak a tervből vagy nem jó környezetben próbáltunk. A nulla talált hiba nem egyenlő a bizonyított hibamentességgel. Külön kell vizsgálni azt is, hogy az alkalmazás hasznos-e annak, aki használja, és teljesíti-e a valódi igényét.

Egy jegyfoglaló rendszer például minden dokumentált számítást pontosan végezhet, mégis alkalmatlan lehet, ha a felhasználó nem tud ülőhelyet választani, pedig ez a vásárlás döntő feltétele. Ilyenkor nem feltétlenül a kódban van hiba: lehet, hogy a csapat eleve rossz vagy hiányos célt fogalmazott meg. A tervezési célok teljesítéséhez tehát a hibák keresése mellett a célok helyességét is vissza kell kérdezni a felhasználótól. A tesztelési alapelvek teljes rendszerezése a következő, 7. órában következik.