Amikor valaki elkezd szoftverteszteléssel foglalkozni, könnyű azt gondolni, hogy a feladat egyszerű: megkapjuk az alkalmazást, végigkattintgatjuk a funkciókat, és ha valami nem működik, hibát írunk róla. A valóságban a tesztelés ennél jóval több. A jó tesztelő nem egyszerűen hibákat keres. Kérdez, elemez, összefüggéseket keres, kockázatokban gondolkodik, és megpróbál olyan helyzeteket is elképzelni, amelyekre mások esetleg nem gondoltak.
Ez a fajta gondolkodás természetesen nem alakul ki egyik napról a másikra. Kezdőként teljesen normális, ha bizonyos csapdákba beleesünk.
Nézzünk meg hetet a leggyakoribbak közül.
1. Csak a happy path tesztelése
Az egyik legtipikusabb kezdő hiba, hogy azt ellenőrizzük, működik-e a rendszer akkor, amikor mindent szabályosan csinálunk.
Vegyünk egy egyszerű regisztrációs űrlapot.
Megadunk egy nevet, egy szabályos e-mail-címet, egy megfelelő jelszót, majd rákattintunk a Regisztráció gombra.
Sikerült? Remek. Csakhogy ezzel még nagyon keveset tudtunk meg a rendszer működéséről.
Mi történik például akkor, ha
- üresen hagyjuk valamelyik kötelező mezőt;
- hibás formátumú e-mail-címet adunk meg;
- túl rövid vagy túl hosszú értéket írunk be;
- szóközöket használunk;
- ékezetes vagy speciális karaktereket adunk meg;
- már létező e-mail-címmel próbálunk regisztrálni;
- kétszer kattintunk gyorsan a Regisztráció gombra?
A felhasználók nem mindig azt teszik, amit a fejlesztő vagy a specifikáció készítője elképzelt.
A tesztelő feladata éppen ezért nem csak annak ellenőrzése, hogy a rendszer működik-e megfelelő használat mellett, hanem annak vizsgálata is, hogyan viselkedik más helyzetekben.
A happy path fontos. De csak a kezdet.
2. A követelmények készpénznek vétele
Kezdőként könnyű úgy tekinteni a specifikációra, mint valamiféle megkérdőjelezhetetlen igazságra. „Ez van leírva, tehát ezt kell tesztelni.”
Pedig maga a követelmény is lehet:
- hiányos;
- félreérthető;
- egymásnak ellentmondó;
- elavult;
- technikailag megvalósíthatatlan;
- vagy egyszerűen hibás.
Tegyük fel, hogy egy követelmény ezt mondja: „A felhasználó erős jelszót köteles megadni.”
Tesztelőként itt nem az az első kérdés, hogy milyen tesztesetet írjunk. Hanem az, hogy: Mit jelent az, hogy erős?
Minimum 8 karakter? Kell nagybetű? Szám? Speciális karakter? Mi a maximális hossz? Elfogadunk szóközt? Mi történik az ékezetes karakterekkel?
Ha ezekre nincs válasz, akkor nemcsak tesztelési problémánk van. A követelmény sem elég pontos.
A tesztelés tehát sokszor már jóval azelőtt elkezdődik, hogy egyáltalán lenne működő szoftverünk.
A jó tesztelő nem csak ellenőriz. Kérdez is.
3. Mindig ugyanazoknak a tesztadatoknak a használata
Van egy jól bevált név: Teszt Elek. Van egy e-mail-cím: teszt@teszt.hu.
És innentől kezdve minden tesztesetet ezekkel hajtunk végre. Kényelmes? Igen. Elégséges? Általában nem.
A tesztelés minőségét nemcsak az határozza meg, mit tesztelünk, hanem az is, milyen adatokkal tesszük ezt.
Egy névmező például egészen másképp viselkedhet ezekkel:
- Anna
- Kiss-Nagy Anna
- Árvíztűrő Tükörfúrógép
Egy nagyon hosszú név, vagy akár speciális karaktereket tartalmazó bemenet. Ugyanez igaz számokra, dátumokra, telefonszámokra, fájlokra és gyakorlatilag minden más bevitt adatra.
Érdemes gondolkodni például: érvényes, érvénytelen, szélsőértékű, üres és szokatlan adatokban. Nem azért, mert a felhasználó biztosan minden elképzelhető furcsaságot be fog írni. Hanem azért, mert szeretnénk megtudni, hol vannak a rendszer határai.
4. A teszteset mechanikus végrehajtása
Van egy tesztesetünk.
- Nyisd meg az oldalt.
- Add meg a felhasználónevet.
- Add meg a jelszót.
- Kattints a Bejelentkezés gombra.
- Ellenőrizd, hogy megjelenik-e a kezdőoldal.
Minden lépés sikeres. Pipa. Jöhet a következő teszteset. Ez nagyon könnyen megtörténik, főleg akkor, amikor sok tesztesetet kell végrehajtani rövid idő alatt. Csakhogy közben lehet, hogy a képernyőn megjelent valami furcsa.
Lehet, hogy a bejelentkezés öt másodpercig tartott a korábbi egy helyett. Eltűnt egy menüpont. Furcsán törik egy szöveg. Megjelent egy hibaüzenet, majd azonnal eltűnt. Vagy valami más történt, amit a teszteset nem kért kifejezetten ellenőrizni.
A teszteset segédeszköz, nem szemellenző. A tesztelőnek végrehajtás közben is figyelnie kell a rendszer egészére. Sok érdekes hibát pontosan úgy találunk meg, hogy észrevesszük: „Ez ugyan nem része a tesztesetemnek, de valami itt nem stimmel.”
5. Minden furcsa működést automatikusan hibának tekinteni
Találtunk valamit, ami nem úgy működik, ahogy szerintünk kellene. Bug! Vagy mégsem?
A tesztelőnek különbséget kell tudnia tenni aközött, hogy: „nem így működik, ahogy én vártam” és aközött, hogy: „nem úgy működik, ahogy a rendszernek működnie kellene”.
Ehhez meg kell vizsgálni például a követelményeket, az üzleti szabályokat, a korábbi működést és az érintett környezetet. Előfordulhat az is, hogy valóban hibásnak tűnik a működés, de a követelmény nem egyértelmű. Ilyenkor nem feltétlenül az a jó megoldás, hogy azonnal megírunk egy hibajegyet. Lehet, hogy előbb kérdeznünk kell. A tesztelő munkájának fontos része, hogy információt gyűjtsön és bizonyítékokra támaszkodjon, ne pusztán feltételezésekre.
6. Pontatlan hibajegy írása
Tegyük fel, hogy tényleg hibát találtunk. Beírjuk a hibajegybe: „Nem működik a bejelentkezés.”
Csakhogy ebből a fejlesztő valószínűleg nem fogja tudni, mi történt.
- Melyik környezetben jelentkezett?
- Milyen felhasználóval?
- Mit csináltunk pontosan?
- Mit vártunk?
- Mi történt helyette?
- Mindig reprodukálható?
- Van hibaüzenet?
Egy jó hibajegy célja nem az, hogy bebizonyítsuk hibát találtunk. Az a célja, hogy a megfelelő ember megértse, reprodukálni tudja és ki tudja vizsgálni a problémát.
Egy használható hibajegyben ezért jellemzően szükségünk lesz többek között:
- egyértelmű címre;
- megfelelő előfeltételekre;
- reprodukciós lépésekre;
- tényleges eredményre;
- elvárt eredményre;
- releváns környezeti információkra;
- és szükség esetén képernyőképre, videóra, logra vagy más bizonyítékra.
A „nem működik” ritkán elég.
7. A „nem találtam hibát” összekeverése azzal, hogy „nincs hiba”
Ez az egyik legfontosabb szemléletbeli különbség.
Tegyük fel, hogy lefuttattunk 50 tesztesetet, és mindegyik sikeres lett. Mit mondhatunk? Azt, hogy az általunk elvégzett tesztek során nem találtunk hibát. Azt viszont már nem feltétlenül mondhatjuk, hogy a rendszer hibamentes. A kettő nem ugyanaz.
A tesztelés mindig valamilyen meghatározott körben, adott idő alatt, adott környezetben, adott adatokkal és adott módszerekkel történik. Lehetnek olyan kombinációk és körülmények, amelyeket nem vizsgáltunk. Lehetnek olyan hibák, amelyeket a tesztjeink nem fedtek fel.
Ezért fontos megérteni, hogy a sikeres tesztelés nem bizonyítja egy szoftver teljes hibamentességét. Sokkal inkább információt ad arról, amit megvizsgáltunk. És minél tudatosabban választjuk meg, hogy mit és hogyan tesztelünk, annál értékesebb lesz ez az információ.
Kommentek