Az előbb példa több szempontból is ül: a repülőgép technikailag igen bonyolult, bármelyik tervezési és gyártási fázisban előadódhat kritikus hiba és mivel az elvárt működése a levegőben történik, a hibák egy része katasztrófához vezethet. Az alkalmazások is nagyon bonyolultak, átszövik a munkánk az életünk megannyi részletét és például egy banki szoftver kritikus hibája is fatális következményekkel járhat.
Ha már a repülős példánál maradunk, érdemes megemlíteni Howard Hughes Spruce Goose nevű gépét. A mai napig legnagyobb, közel 100 méter szárnyfesztávú repülő első és egyben utolsó útja során mindössze 21 méterre emelkedett fel és egy mérföldet tett meg a levegőben. A tervezési hibák az éles tesztelés során mutatkoztak be, így a repülő az élettartama nagy részét hangárban, jóideje egy múzeumban töltötte.
A robosztus, pénznyelő rendszerek hibái hol okozhatnak ennél is nagyobb kárt? Természetesen a pénzügyi szektorban.
2012-ben a Knight Capital 30 perc alatt 440 millió dollárt veszített egy, a cég által „kereskedési hibának” nevezett probléma miatt. A valóságban a rossz szoftverfejlesztési és tesztelési modellek a felelősek.
Csak egyetlen hiba kellett egy kereskedési algoritmusban ahhoz, hogy a Knight Capital az éves nyereségének háromszorosát elveszítse. Az algoritmus célja az volt, hogy rövid idő alatt hatalmas mennyiségű részvényt vásároljon és adjon el, a katasztrofális eredményhez a rossz megbízások kombinációja vezetett.
A sokk és az azt követő eladási hullám miatt a Knight Capital részvényei két munkanap alatt értékük 75 százalékát veszítették el. A likviditásvesztés olyan nagy volt, hogy a Knight Capitalnak további 400 millió dolláros hitelkeretet kellett felvennie. A Knight Capital vezérigazgatója „egy nagyon nagy szoftverhibáról” beszélt, az elemzők szerint a szokásos, megfelelő szoftvertesztelés nélküli éles üzembe helyezés okozhatta a hibát.
Nagy rendszerekről szólva az államigazgatás is jó terepe a kritikus rendszereknek, amelyek tesztelésért kiáltanak.
1999-ben az Egyesült Királyság egy új számítógépes feldolgozó rendszert vezetett be az útlevélkérelmek egyszerűsítése érdekében. A rendszer célja a folyamat modernizálása és a hatékonyság javítása volt, de a szoftverhibák és rendszerhibák miatt a bevezetés hatalmas késéseket okozott, így több ezer brit állampolgár nem tudta időben megkapni útlevelét az utazáshoz.
A rendszert nem tesztelték megfelelően valós körülmények között, ami a rendszer túlterheléséhez vezetett. További probléma volt, hogy a kormány ekkortájt új útlevélkövetelményeket vezetett be a gyermekek számára, ami nagymértékben növelte a kérelmek számát.
A hiba teljes költsége 20 millió dollárra volt tehető, beleértve a további adminisztratív személyzet bevonását és túlórák kifizetését, valamint a pénzügyi kompenzációkat. Természetesen minden kár nem jelent meg direkt költségként, ezrek maradtak le a szabadságukról és az üzleti útjaikról, ami közfelháborodáshoz vezetett. A folyamat és a terhelés tesztelése könnyen elkerülhetővé tette volna a problémát.
Az elhíresült Pepsi botrányt nem informatikai malőrként hivatkozzuk, inkább marketingblamaként, mégis jól mutatja a minőségbiztosítás, az ötlet tesztelésének fontosságát.
A Pepsi 1992-re lemaradt a Coca-Cola mögött a Fülöp szigeteken, ezért a piaci részesedés növelése érdekében nyereményjátékot hirdetett Pepsi Number Fever néven. A játék lényege, hogy számkódos kupakokkal látták el a palackokat és a számokhoz különböző nyereményeket társítottak egy 1 millió pesó értékű fődíj mellett.
A hatás óriási volt, a Pepsi hatalmas forgalmat bonyolított, 40 százalékkal növelték az eladást és a játékban a Fülöp-szigetek lakóinak fele, több mint 30 millió játékos vett részt.
A nyertes szám az utolsó héten a 349-es volt, a probléma csak az volt, hogy ezzel a számmal egy hiba miatt 800 ezer kupak készült el. A cég azzal szembesült, hogy milliárdokat kellene kifizetniük a nyerteseknek, amit megtagadtak és a nyertes számért mindenkinek 20 dollár fájdalomdíjat ajánlottak fel. A végeredmény kitalálható: zavargások törtek ki, a Pepsi teherautóit megrongálták, palackozóüzemeket támadtak meg és sebesültekről, sőt halálos áldozatokról is érkeztek hírek, a márkaérték nagymértékű eróziója mellett. A kritikus rész tesztelése megspórolhatta volna a cég számára a katasztrófát.
A minőségbiztosítás, a szoftvertesztelés messze nem opció, sokkal inkább a folyamat elejétől a legvégéig tartó elkötelezett, szakmai munka, amely hatalmas irodalomra és gyakorlatra tud támaszkodni. A tesztelő tanfolyam során mi ennek alapjait szeretnénk lefektetni, hogy segíthessünk az első lépéseket ezen a fontos és izgalmas szakmai úton.