A szakma nem felejtette el, csak annyira nagy az eredendő állapottér, hogy egyszerűen nem lehet minden esetet figyelembe venni.
Azt se felejtsétek el, hogy mindig ott az időkorlát. Persze automatizáljuk a tesztelést, de vajon a teszt automata is figyelembe vesz mindent.
Én a magam részéről nagyon pártolom és használom is a statikus teszteket. Mert kellő tapasztalattal és tudással a hibák 90%-át kiszűrik. Hozzáteszem messze elkerülőm a web alkalmazás fejlesztést, inkább embedded és biztonságkritikus dolgokkal foglalkozom.
Konkurens esetben a dinamikus tesztelés nagyon szépen el tud kritikus hibákat "rejteni" lásd Airbus (tudnék Boing és Bombardier hibát is említeni, nem beszélve a Grippenről, vagy esetleg a Fobosz-Grunt, a Mars Climate Orbiter esete, vagy az első Ariane V felrobbanása).
Miért követtek el elemi hibákat?
-Hülyék lennének? Nem hiszem.
-Elemi hibát vétettek? Igen.
-Mi a hibák elkövetésének oka? Saccolom idő és pénzhiány.
-Felelősségre kellene a fejlesztőket vonni? Baromi nagy kárt okoztak. Szerintem nem, ez számukra a legnagyobb büntetés.
Tanulni kell az esetekből, fel kell tárni a problémákat, őszintén, nem egy fenyegetés árnyékában.
Ne felejtsük el a következő egyszerű "definíciókat":
-Mi a hardver: amibe belerúgunk.
-Mi a szoftver: ami miatt belerúgunk.
Még egy rövid kiegészítés:
A szoftver átadásánál (általános életciklus modell 6. lépés) a megrendelővel részletesen át kell vetetni a terméket, nem csak a nesze itt van, kész, vigyed. Mindenki utálja csinálni, én is, de ne kerüljük ki.
Ha hiba marad a szoftverben, akkor analizáljuk és javítsuk ki. Nem szeretem a zseni gyerekeket, akik egy sort átírnak és ezzel kész is a javítás. A szoftvertörténelem három legnagyobb kárt okozó hibája egy egysoros javítás volt. Ha javítasz - főleg konkures, vagy real-time, vagy mindkettő progit - igen újra kell tesztelni szigorúan.