A jóslatok a problémákra vannak, nem a tökéletességre

Egy ellenőrzés rámutathat egy hiba jelenlétére, illetve arra hogyan kellene a szoftvernek viselkednie. Teljesen mindegy, hogy milyen jóslatokra támaszkodunk, a teszt sohasem tudja megmondani, hogy a szoftver jól működik-e, illetve jól fog-e működni a jövőben. És akkor mire jók a jóslatok egyáltalán?

James Bach és én is folyamatosan finomítjuk a gondolatainkat a tesztelést illetően, így történt ez a jóslatok tekintetében is. A jelen írásomban, erre reagálok most:

„A tesztelés magában foglalja a program tesztadatokkal történő futtatását és az így kapott eredmények elemzését is. Különböző típusú teszteredmények születhetnek. Ezek tartalmazhatják a program kimeneti változóinak végső értékét vagy kiválasztott változók közbenső nyomait. Tartalmazhatják továbbá mért időadatokat az éles rend-szerre vonatkozóan.

A tesztek megkívánják a külső kapcsolatok és mechanizmusok meglétét is, amivel az eredmények valódiságát vizsgálni lehet. Ez a mechanizmust nevezzük a további-akban jóslatnak. A jóslatok lehetnek különböző űrlapok, tartalmazhatnak táblázato-kat, kézzel számított értékeket, szimulált eredményeket, követelmény leírásokat.” – William E. Howden, A Survey of Dynamic Analysis Methods, in Software Validation and Testing Techniques, IEEE Computer Society, 1981

Miközben nagy tisztelettel vagyok az olyan úttörők munkássága felé, mint Prof. Howden, van néhány probléma ezzel a tesztelési megközelítéssel a pontosság tekintetében.

• A tökéletes eredmény egy szoftvertől nem alapvető. Egy eredmény vagy jó vagy nem jó, mely az aktuális elgondolástól, elvtől, vagy modelltől függ. Triviális példa: Matematikailag igaz, hogy ha egy számot kettővel osztunk, akkor annak a számnak éppen a felét kapjuk. A legtöbb területen ez igaz, de ahogy egy George Carlin vicc mondja, ha egy morzsát kettévágunk, akkor nem két fél mor-zsánk lesz, pontosan két morzsát kapunk.
• Lehet, hogy egy alkalmazás funkcionálisan tökéletese eredményt ad, de az még koránt sem biztos, hogy elfogadható az üzleti folyamatok vonatkozásá-ban. Például: Az alkalmazás 2+2 eredményeként 4-et ad, de fehér háttérre fehér betűvel írja ki.
• Kölcsönösen igaz ez akkor is, amikor az alkalmazás hibás eredményt ad, de az eredemény még mindig egészen elfogadható. Példa: a számítógép órája minden másodpercben egy tizedmásodpercet késik, de minden percben újraszinkronizálja magát az atomórával. A számítógép tulajdon-képpen sohasem mutatja a pontos időt, de a felhasználó ezt sohasem fogja észre-venni és igazából nem is érdekli. Egy másik példa, ha az alkalmazás nem ad pontos eredményt a tízedik helyi érté-ken, de mivel csak az első 2-3 helyi értéket jelenítjük meg, ez egyáltalán nem szá-mít.
• A megfelelő eredményt nem lehet előre tudni. Néhány esetben, főleg a tudományos alkalmazásoknál a kísérlet megtörténik, és felfedezünk valami újat. Hogy meghatározzuk a kapott eredmény helyes-e vagy sem, meg kell vizsgálni a matematikai modelleket, meg kell vizsgálni az alkalmazás és a hálózat korlátait is. Ezekben az esetekben a helyes eredmény elfogadása nem triviális és további fejlesztést, tervezést igényel. Példa: egy rendszer teljesítményének értékelése nem nagy dolog. Viszont össze-hasonlítani különböző rendszerek (vagy adott időpillanatban a rendszer különböző verzióinak) teljesítményeit már a tesztelés kihívása.
• Mint ahogy egy szoftver fejlesztésénél és tesztelésénél is lehet, hogy felfedezünk nem kívánt, nem jól definiált, vagy egyáltalán nem definiált részeket is. Annak érdekében, hogy egy program képes legyen a megfigyelésre, definiálnunk kell mit kell megfigyelni és ezt le kell kódolnunk. A gép nem tud elképzelni, felta-lálni, vagy tanulni és nem lát előre az eredmények és felfedezések tekintetében. Ezzel szemben az ember képes a folyamatos tanulásra, előre tudja jelezni az el-gondolásait és a felfedezéseket. Néha olyan felfedezésekre is képesek vagyunk, amire nem is gondoltunk előre. Néha biztosak vagyunk benne, hogy most valami újat fogunk felfedezni – ezek néha jók, de néha hibásak is lehetnek. Külön-külön megvizsgálva, tesztelve új dolgokat fedezhetünk fel. A tesztelés megmutatja ne-künk, hogy ez az új felfedezés egy új hibát vagy problémát tárt-e fel és abban is segít, hogy merre induljunk, mit tegyünk az új felfedezéssel.
• A jóslat lehet hibás, vagy egyáltalán nem is releváns. Példa: egy alkalmazás, amely arra hivatott, hogy egy másik alkalmazás működését ellenőrizze lehet, hogy önmagában hibás. Lehet, hogy a dokumentáció nem aktuá-lis, vagy a szakértők, akik a rendszert betéve ismerik, elfeledkeztek valami fontos-ról.
• A jóslatok inkonzisztensek. Lehet, hogy van pár nagyon jó eszközünk a hőmérséklet mérésére, de a hőmérsék-let mérése a klimatológiában alapvetően bizonytalan. Mi a pontos hőmérséklet a szabadban? Napon, vagy árnyékban? Amikor a hőmérő egy épület közelében van, vagy távol tőle? A föld közelében, vagy egy kicsivel magasabban? Néhány kérdés-re egy másik írásomban választ adok.

• Felfedezünk néhány inkonzisztenciát a rendszerben, de mégsem tudjuk kijaví-tani, garantálni a jó működést. Ahogy Djikstra szokta mondani, a tesztelés megmutatja a hiba jelenlétét és nem a távollétét. Ennél részletesebben, mélyebben nézve Popper szerint a teóriákat csak hamisítani lehet, nem lehet őket bizonyítani. Példa: Nem számít hányszor teszteltük azt, hogy a kalkuláció 2+2-re 4-et adjon eredményül. Sohasem tudhatjuk, hogy minden esetben ezt követően is 4-et fog adni eredményül. Csak annyit mondhatunk, hogy az eddigi tapasztalataink alapján arra következtetünk, hogy 4 lesz az eredmény, de a következtetések bizonytalanok és problémásak is lehetnek. Nassim Taleb példája: A pulyka a farmon minden nap abban a hitben erősíti magát, hogy a farmer érdeklődik és szereti a pulykákat — míg egyszer csak, pár nappal a Hálaadás előtt kap egy nagyon hirtelen, kellemet-len és (a pulyka szempontjából) villanásnyi betekintést, hogy rosszul gondolta.
• Néha nem is kell tudnunk a jó eredményt, ahhoz, hogy eldöntsük, hogy a kapott eredmény rossz. Példa: A cosinus függvény eredménye -1 és 1 között kell hogy legyen. Nem kell tudnunk, mi a jó eredménye a cos(72)-nek, hogy eldöntsük a 4.2-es eredmény rossz. Gyakran a tesztelők nagy biztonsággal képesek eldönteni az adott ered-ményről, hogy rossz anélkül, hogy tudnák a jó eredményt.

A tökéletesség ellenőrzése – különösen akkor, amikor a teszteredmények mechani-kusan, vagy indirekt módon lettek kiértékelve – üzleti veszélyeket hordoz magában. Minden jóslat gyarló. Egy „helyes” teszt egy hibás jóslaton alapulva nem fog helyes eredményt adni, és nincs az a „helyes” teszt, amely jó eredményt adna. Ebben az esetben minden teszt egy tudományos kísérlet. És mint minden kísérlet hibás is le-het. Egyik teória a másikat támasztja alá, de ez nem azt jelenti, hogy a kísérlet igaz. Kísérletek milliói mondják azt, hogy nincs fekete hattyú. Megfigyelések milliói semmit sem árulnak el arról, hogy valami hiba volna, amiből fekete hattyú születhetne. A legjobb amire képesek vagyunk, hogy egy olyan tesztet futtatunk, ami egy újabb fe-hér hattyú megfigyelését eredményezi. Az ilyen esetekben emlékezzünk erre a példára.

Egy ellenőrzés rámutathat egy hiba jelenlétére, illetve arra hogyan kellene a szoftvernek viselkednie. Teljesen mindegy, hogy milyen jóslatokra támaszkodunk, a teszt sohasem tudja megmondani, hogy a szoftver jól működik-e, illetve jól fog-e működni a jövőben. És akkor mire jók a jóslatok egyáltalán?

Ha megfordítjuk a fókuszt a pontosságon, akkor sokkal robosztusabb felfedezésekre leszünk képesek. Nem használhatjuk a jóslatainkat logikusan abban az értelemben, hogy a szoftver jól működik-e, illetve hogy jól fog-e működni, a használhatjuk arra a jóslatainkat, hogy kiderítsük van-e valami olyan ellentmondás, ami miatt a szoftver nem fog jól működni. Ezért mondjuk azt a Rapid Software Testing-ben, hogy a jósla-tokkal feltárhatjuk az esetleges problémákat a szoftverben.

Forrás: http://www.developsense.com/blog/2015/03/ oracles-are-about-problems-not-correctness/
Szerző: Michael Bolton