facebook-pixel

Tesztelési tanulságok – amikor egy rendszer összeomlik

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:

  1. Ne omoljon össze a rendszer.
  2. Értelmes hibaüzenettel reagáljon.
  3. 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! 🙂

Megosztás

Facebook
LinkedIn
Twitter

Nem szeretnél lemaradni az új bejegyzésekről?

Tartalomjegyzék

sorozatok
Dechandt Dóra

BDD rövid bemutatása

BDD pro és kontra Egyik előző írásunkban (LINK) már kifejtettük, hogyan működik a BDD. Ezúttal az előnyeire és hátrányaira szeretnénk rávilágítani. A BDD (Behavior Driven

Érdekel a tesztelés világa?

Dolgozz velünk hazai és nemzetközi projekteken

egy csoport ember ül egy asztalnál laptopokkal

Várj, ne maradj le legújabb szakmai cikkeinkről

Iratkozz fel hírlevelünkre és minden hónapban elküldjük a legizgalmasabb cikkeket

egy laptop számítógépet tartó szemüveges férfi
egy süti csokireszelékkel
Tájékoztatjuk, hogy a honlap felhasználói élmény fokozásának érdekében sütiket alkalmazunk. A honlapunk használatával ön a tájékoztatásunkat tudomásul veszi.