A hír
Nemrégiben összeomlott az Egyesült Királyság légi közlekedése egy banálisnak tűnő dolog miatt. Egy leadott repülési tervben ugyanis két azonos nevű, de egymástól 7500 kilométerre található célpont szerepelt, melyet nem tudott feldolgozni a rendszer.
A hírnek vannak teszteléshez kapcsolódó tanulságai is, melyeket most meg is osztunk veletek.
Tanulság 1.
A tesztelők dolga megvizsgálni, hogy mit reagál egy alkalmazás arra, ha nem az előre meghatározott értékkészletből kap bemeneti adatot. Az általános elvárás az, hogy ilyen esetben:
- Ne omoljon össze a rendszer.
- Értelmes hibaüzenettel reagáljon.
- A beadott hibás adatokat utasítsa vissza (ne tárolja el, ne dolgozza fel).
Ahhoz, hogy egy tesztelő olyan, negatív utas teszteket tudjon tervezni, amivel megfoghatók ezek a hibák, alapvető teszttervezési stratégiák megtanulására van szükség. A legismertebbek ezek között a határérték elemzés, ekvivalencia particionálás, páronkénti (kombinációs) tesztelés.
Tanulság 2.
Valószínű, hogy NATS szoftverét alaposan letesztelték. Azt gondolom, hogy rendszeresen futtattak regressziós teszteket és minden új modult, funkciót, hibajavítást megvizsgáltak a tesztelők. Csak találgatok, de szerintem ez a hiba már rég benne volt a rendszerben, csak eddig nem futottak rá.
Ha egy hiba becsúszik valamikor egy rendszerbe egy új fejlesztéssel, azt a hibát később a regressziós tesztelés során már nem tudják elkapni, hiszen a regressziós tesztelés nem arra való, hogy eddig nem felfedezett hibákat kapjon el, hanem „csak” arra, hogy ha valami eddig működött, az ezután is működjön.
Hogyan lehet akkor ilyen hibát elkapni, miután már a rendszerben van?
Szerintem úgy, hogy a rendszeres regressziós tesztelést ki kell bővíteni valamilyen dinamikus tesztelési technikákkal, módszerekkel. Ilyenekkel például: FUZZ, Chaos, monkey testing.
Összegzés
Nincs hibátlan program. Ilyen esetek elő fognak még fordulni. A tesztelőnek nem feladata a hibátlan program garantálása, viszont feladata a kockázatok csökkentése.
Anno azt mondták, hogy a teszteléshez elég a józan paraszti logika. Azt gondolom ez a mondás elavult. A tesztelőknek nem elég izomból nyomni a tesztelést, a szoftvertermékek komplexitásának és ezek használatából fakadó kockázatok növekedésével egyre fontosabbá válnak a módszerek, technikák, eszközök ismerete és hatékony alkalmazása tesztelésben.
Jó tesztet! 🙂