Miért van szükség tesztelésre?

Egy alkalmazás eredményét nemcsak a saját programkódja határozza meg. Befolyásolhatja a böngésző, az operációs rendszer, a hálózat, az adatbázis, egy külső szolgáltatás, a jogosultságok beállítása és a felhasználó által bevitt adat is. Egy megoldás ezért az egyik környezetben jól működhet, a másikban viszont hibásan viselkedhet.

Képzelj el egy online jegyvásárlást. A felhasználó kiválasztja a helyét, fizet, majd várja a visszaigazolást. A folyamat érinti a felületet, a készletnyilvántartást, a fizetési szolgáltatót és az e-mailküldést. Ha a kapcsolat megszakad a fizetés és a foglalás rögzítése között, külön vizsgálni kell, nem keletkezett-e terhelés jegy nélkül. A sikeres kattintás önmagában még nem bizonyítja a teljes folyamat sikerét.

A hibák sokszor emberi tévedésből indulnak ki: félreértett követelmény, elgépelés, hibás feltételezés vagy kapkodva elvégzett módosítás. Az okok között szerepelhet az összetett feladat, az időnyomás, a hiányos kommunikáció vagy a nem megfelelő ellenőrzés is. Hiba már a követelményben vagy a tervben is lehet, nem csupán a forráskódban.

Példa: a szabály szerint a 18. életévét betöltött felhasználó regisztrálhat, de a fejlesztő a feltételbe „életkor > 18” kifejezést ír. A félreértés emberi tévedés; a hibás feltétel a termékben lévő hiba; amikor a 18 éves jelentkezőt a rendszer elutasítja, azt meghibásodásként figyeljük meg. A három fogalom nem ugyanaz.

A tesztelés segít információt szerezni a termék minőségéről és csökkenti annak esélyét, hogy súlyos hibák észrevétlenül maradjanak. Nem ígérheti, hogy minden lehetséges környezetet és bemenetet kipróbáltunk. Azokat a helyzeteket érdemes előre venni, amelyek valószínűek, nagy hatásúak vagy sok embert érintenek.

Egy ügyfélkapunál például fontosabb lehet a bejelentkezés, a jogosultságkezelés és a mentett adatok épsége, mint egy ritkán megnyitott súgóoldal apró igazítási hibája. A sorrend megválasztása nem jelenti azt, hogy a többi rész hibátlan: csak a rendelkezésre álló idő tudatos felhasználását.

A tesztelt rendszernek vannak belső részei – felület, üzleti szabályok, adatkezelés –, és vannak kapcsolódási pontjai. A böngésző verziója, a mobil képernyő mérete, az időzóna, a hálózat sebessége, egy külső fizetési szolgáltató vagy a szerver beállítása ugyanannak a funkciónak más-más feltételeket teremt. Teszttervezéskor ezért a 'mit csinál a gomb?' mellé oda kell írni azt is, hogy milyen környezetben és milyen adatokkal vizsgáljuk.

Képzeld el, hogy a beadási határidő szeptember 30. 23:59. Ha a böngésző és a szerver eltérő időzónában van, a felület még engedheti a beadást, a szerver viszont elutasíthatja. Nem biztos, hogy a gomb vagy az adatbázis hibás: lehet, hogy a két rendszer nem ugyanúgy értelmezi az időpontot. A jó hibajegy rögzíti az eszközt, az időt, az adatot és a tényleges viselkedést.

A programhibák egyik forrása a félreértés. A megrendelő 'aktív diákot' mond, de nem tisztázzák, hogy a szünetelő jogviszony ide tartozik-e. A fejlesztő jóhiszeműen választ egy értelmezést, a tesztelő pedig később eltérést talál. Ha a szabályt már a tervezéskor konkrét példákkal ellenőrizték volna, a hibás megvalósítás megelőzhető lett volna. Ezért a követelményeket is érdemes tesztelési szemmel olvasni.

Más ok lehet a bonyolult feltételrendszer, a sok függőség, az utolsó pillanatban végzett módosítás, a hiányos tesztadat vagy a nem megfelelő ellenőrzési folyamat. A felhasználó által észlelt hiba leírásából még nem következik biztosan a kiváltó ok. A tesztelő először a megismételhető tényeket gyűjti, utána a csapat vizsgálja, mi okozta az eltérést.

Egy tanulmányi rendszerben a tanuló leadja a választ. Az oldal zöld visszajelzést mutat, de a tanár nem lát beadást. Négy külön ellenőrzési pontot különíthetünk el: elküldte-e a böngésző a kérést; befogadta-e a szerver; tartósan mentődött-e az adat; ugyanazt a rekordot mutatja-e a tanári felület. Minden pontnak saját elvárt eredménye van. A felület látványa önmagában nem helyettesíti az adatok ellenőrzését.

A fontos tanulság nem az, hogy minden technikai részletet tudni kell, hanem hogy egy szoftver több elem együttműködéséből áll. Amikor hibát keresünk, rendszerszinten gondolkodunk: mi történt előtte, hol haladt át az információ, mi lett a végső állapot? A tesztelés így csökkenti annak esélyét, hogy egy látványos, de felszínes ellenőrzés hamis biztonságérzetet adjon.