A tesztelés szerepe a szoftverek fejlesztésében, karbantartásában és működtetésében

A tesztelő nemcsak a kész alkalmazást futtatja. Már egy követelmény, felhasználói történet vagy képernyőterv átnézésekor felteheti a kérdést: egyértelmű-e a szabály, ellenőrizhető-e az eredmény, mi történik érvénytelen bemenet esetén? Az ilyen korai visszajelzés még a megvalósítás előtt megakadályozhat félreértéseket.

Fejlesztés közben a részeket külön és együtt is vizsgálni kell. Amikor a rendszert karbantartják – hibát javítanak, új funkciót adnak hozzá, környezetet frissítenek –, a változtatást ellenőrizni kell, és meg kell nézni, nem romlott-e el más működés. Az üzemeltetésből érkező hibajelzések pedig új tesztesetek alapjául szolgálhatnak.

A minőség nem egyetlen hibaszám. Fontos, hogy a rendszer megfelel-e a leírt követelményeknek (verifikáció), de az is, hogy a valós használatban megoldja-e a felhasználó problémáját (validáció). Egy oldal teljesítheti a specifikációt, miközben a felhasználó a fontos műveletet nem találja meg rajta.

A tesztelési eredmény döntési információ: milyen hibák maradtak nyitva, mely funkciókat próbálták ki, milyen környezetekben, és mekkora a fennmaradó kockázat? A „sikeresen lefutott 100 teszt” önmagában kevés, ha egy fontos fizetési útvonalat egyszer sem vizsgáltak.

Tökéletes bizonyosság általában nem érhető el: az idő, a költség, az adatkombinációk és a környezetek száma korlátozza a vizsgálatot. A leállás ezért tudatos döntés a megállapodott célok, a végrehajtott tesztek, a hibák súlyossága és a hátralévő kockázat alapján.

Ha egy oktatási alkalmazásban a fő feladatsor mentése időnként elveszik, a rendszer nem tekinthető késznek attól, hogy a színek és a kereső jól működnek. Ha viszont a kiadás előtt csak egy alacsony hatású elírás marad, a kiadás vállalható lehet – a döntésnél számít a környezet és a célközönség is.

A projekt elején a tesztelés segíthet tisztázni a követelményt: mit jelent pontosan az, hogy 'gyors' vagy 'egyszerűen használható'? Az ellenőrizhetetlen mondat helyett mérhető elvárás kell. Később vizsgálhatjuk az egyes részek működését, a részek kapcsolatát és a teljes felhasználói folyamatot. Nem egyetlen 'tesztelés' nevű pillanat van a kiadás előtt, hanem egymáshoz kapcsolódó megfigyelések és visszajelzések.

Például egy könyvtári rendszer követelményében ez áll: 'a lejárt kölcsönzés nem hosszabbítható meg'. Már itt érdemes megkérdezni, hogy az esedékesség napján 23:59-kor még hosszabbítható-e, és melyik időzóna számít. Ha ez tisztázatlan marad, a fejlesztés, a teszteset és a felhasználói elvárás három különböző értelmezésre épülhet.

Karbantartás nem csak hibajavítás lehet. Új szolgáltatás, biztonsági frissítés, operációsrendszer-váltás vagy adatbázis-migráció is módosíthatja a működést. Egy kijavított helyzetre megerősítő ellenőrzés kell, de azt is nézni kell, hogy a változás nem rontott-e el korábban működő folyamatokat. Ezt nevezzük regressziós vizsgálatnak. A legfontosabb útvonalak – például bejelentkezés, mentés, fizetés – ismételt ellenőrzése kiemelten értékes.

A működtetés során a felhasználók olyan adatokat, eszközöket és folyamatokat hozhatnak, amelyekre a csapat nem gondolt. Egy ügyfélszolgálati jelzés ezért nem egyszerűen 'panasz': megfigyelés a valós környezetről. A jelzésből előbb reprodukálható esetet, majd szükség esetén új tesztet készítünk, és visszacsatolunk a követelményekhez. Így tanul a termék és a csapat.

A tesztelés mennyisége a cél, a kockázat, a rendszer használata és a rendelkezésre álló erőforrások szerint változik. Egy tanulói kvíznél és egy betegellátást támogató rendszernél nem ugyanaz a hibák lehetséges következménye. A döntéshez nézni kell, mely követelményekre vannak tesztek, milyen adatokat és környezeteket próbáltunk, milyen súlyos hibák nyitottak, valamint ki vállalja a fennmaradó kockázatot. A tesztek száma önmagában nem alkalmas a minőség bizonyítására.

Hasznos előre megfogalmazni a befejezés feltételeit: például a kritikus folyamatok lefutottak, nincs ismert blokkoló hiba, és az ismert kisebb eltérésekre van tudatos döntés. Ez nem jelenti a hibamentességet; azt jelenti, hogy a résztvevők ismert bizonyítékok és korlátok alapján döntenek. Ha egy kulcsfolyamat hibás, a sok sikeres, mellékes teszt nem ellensúlyozza automatikusan a veszélyt.