Ha feltennénk a körkérdést, hogy mi okozza a legtöbb problémát a szoftverfejlesztés során, akkor a leggyakrabban kapott válaszok között jó eséllyel ott lenne, hogy a projektnek nincs egy mindenki által elfogadott és jól használt dokumentációja.
Vagyis nem létezik közös tudásbázis arról, hogy mit várunk a szoftverünktől, mást gondol a fejlesztő, mást gondol az üzleti oldal, és mást gondolnak a tesztelők. Az a helyzet pedig, ahol mindenki másra számít, mert nincsenek egyértelmű feladatok és célok meghatározva, sok konfliktushoz fog vezetni. Ezt a problémát hivatottak megoldani a tesztesetek.
Ki írja a tesztesetet
A minőségbiztosítás az egész fejlesztői csapat felelőssége, de alapesetben a tesztesetek írása és karbantartása tipikusan tesztelői feladat. A jó teszteset leírja, hogy egy konkrét user lépés (tesztlépés) az appunkban, milyen elvárt eredménnyel jár együtt, valamint azt is, hogy ezt a lépést, lépéseket, hol kell végrehajtani.
Ha a szoftverünk teljesíti egy ilyen tesztlépés-elvárt eredmény kombinációban leírtakat, akkor jól működik. Ha nem, akkor főszabályként hiba, bug van benne, amit ki kell javítani. Azonban az is előfordulhat, hogy a szoftver jól működik, viszont a teszteset rosszul van megírva, ilyenkor a tesztesetet kell javítani.
A teszteset felépítése
Hogy egy tesztesettel jól be tudjunk határolni egy elvégzendő feladatot, a következő feltételeknek kell megfelelnie:
- Meg kell mondania, hogy milyen felületen tesztelünk
- Egyértelműen meg kell neveznie a tesztesetet
- Pontosan le kell írnia tesztesethez tartozó tesztlépés-elvárt eredmény párosokat
A felület lehet egy webes applikáció esetében például desktop, mobil, vagy tablet is, attól függően, milyen felületre optimalizáltuk a szoftvert. Ez a fő rendező egység, ami maga alá gyűjti a teszteseteket.
Ezt követi maga a teszteset elnevezése, mint például a regisztráció, ez alá pedig bekerülnek a tesztlépések párosok. Kicsit lejjebb mutatom, hogyan néz ki ez a gyakorlatban.
Teszteset template
A következő template nagyon egyszerű, nem kell hozzá más csak egy Google spreadsheet, ahol felveszem a következő oszlopfőket.
- Teszteset neve (Test Case Name)
- Sor típusa (Row Type)
- Tesztlépés leírása (Test Step Description)
- Elvárt eredmény (Expected Result)
- Megjegyzés (Comments)
Ez így néz ki a gyakorlatban. Az oszlopfőket külön színnel jelölöm, alatta a második sorban jelölöm, hogy az ebbe a mappába tartozó tesztesetek desktopos tesztesetek lesznek, majd jön is az első tesztlépés.
Tesztlépések esetén a teszteset neve oszlop mindig üres lesz, míg a mappa és a tesztlépés típusú soroknál a tesztlépés leírása, elvárt eredmény és megjegyzés oszlopok lesznek logikusan üresek.
Mi a jó sorrendje a tesztlépéseknek
Az alábbi tesztlépések egy teljesen hétköznapi applikáció regisztráció formjának tesztlépései. Az első tesztlépés arról szól, hogy nyissuk meg az applikációt, kicsit feleslegesnek tűnhet, de ez az első lépés feladata.
El kell magyaráznia, hogy hova kell navigálnom az appon belül, hogy végrehajthassam a tesztlépéseket. Ez kvázi egy nulladik lépés, amit első lépésnek hívunk, ami ebben az esetben triviális, de képzeljük el azt a helyzetet, amikor az első lépés az, hogy az applikáció egyik eldugott, ritkán használt pontjára navigáljak el, és ezt nem írom le. Nem lenne könnyű megtalálni.
Szóval az első lépésünk az, hogy nyissuk meg az appot, az elvárt eredményünk pedig az, hogy jelenjen meg a login screen rajta a username és jelszó fieldekkel és a login gombbal.
Ezt követően pedig jönnek a tesztlépések, először csak usernevet adunk meg, majd megpróbálunk belépni, nem sikerül. Majd jön a usernév, és a rossz jelszó kombináció. Nem tudunk belépni újra. Jön az újabb variáció erre a témára. A usernevünk most rossz, de a jelszónk jó. Újra nem fogunk tudni belépni. Majd jön az utolsó lépés, amikor a jelszavunk és a felhasználónevünk is jó, ebben az esetben az appnak be kell engednie a usert.
Az hogy ilyen sorrendben jönnek a tesztlépések a teszteseten belül az nem véletlen. Egy tesztesetben érdemes mindig egy felülettel foglalkozni, nem pedig ugrálni a felületek között, könnyebben követhető, és gyorsabban végrehajtható a forgatókönyv a tesztelő számára, ha nem kell felesleges oda-vissza navigációkat tennie. Például nem rögtön a második lépés az, hogy sikeresen belép, mert ha az lenne, akkor ahhoz hogy le tudja tesztelnie a sikertelen belépésekhez tartozó hibaüzeneteket, a sikeres belépés után ki kéne lépnie, majd újra elnavigálnia a nyitóoldalra, hogy tesztelje a sikertelen belépést.
