Pár hete egy régi barátommal beszélgettem, aki elment tesztelőnek egy nagy céghez. Szép és jó, hogy egy olyan méretű (nagy nemzetközi multi) cég nem csak fejleszti a szoftvert, hane teszteli is. Kérdezgettem, hogy milyen technológiákat használnak, már csak amennyire el szabad ilyen dolgokat szigorúan szakmai érdeklődés szintjén árulni.
És akkor elhangzott egy kérdés, amire nem számítottam, és amire hirtelen nem is tudtam mit válaszolni:
Te hogyan tesztelnél egy olyan alkalmazást, aminek nincs specifikációja?
He? Ho? Hát sehogy. A tesztelés annak ellenőrzése, hogy a szoftver megfelel a specifikációnak. Vagy nem?
Végig gondolva rá kellett döbbennem, hogy nem. A fenti definíció, amely szerint a tesztelés azt ellenőrzi, hogy a szoftver megfelel-e a specifikációnak egy olyan műszaki definíció, amelyik a legtöbb esetben használható, de nem ez a tesztelés legfőbb célja. A legfőbb cél az, hogy a szoftver hasznpt hozzon a felhasználónak, az ügyfélnek. Csak ezt nehéz ellenőrizni. Ehelyett vizsgáljuk, hogy a szoftver a speckónak felel-e meg.
Máskor is felmerült már ez a kérdés, hogy mi az amire kíváncsiak vagyunk, és mi az amit mérünk. Annak idején, sok éve, amikor egyetemen oktattam, és ennek folyományaként vizsgáztatni is kellett, meg zárthelyiket iratni, az egyik hallgató a szememre vetette, hogy a zárthelyivel való mérés nem igazságos, hiszen nem a tudását méri, hanem azt, hogy a zárthelyiben megadott feladatot milyen jól oldja meg.
Szembesülnie kellett azzal, hogy nem álltam le vitázni vele, hanem ighazat adtam neki. A zárthelyi eredménye nem határozza meg, hogy milyen a tudása, csak összefügg vele, esetleg csak korrelál. Szinte minden esetben amikor mérünk nem azt mérjük amit tudni szeretnénk, mert az többnyire nem mérhető. Ehelyett mérünk valami mást, ami összefügg azzal amit tudni szeretnénk. Esetleg csak korrelál, és az igazat megvallva néha még azt sem.
A tesztelés is ilyen. Azt mérjük, hogy a szoftver megfelel-e a specifikációnak. Ha a specifikáció azt írja le, hogy mire van szüksége a megrendelőnek, akkor a szoftver specifikációnak való megfelelősége egészen jól korrelál a szoftver üzleti alkalmasságával. De ha nem fejlesztünk, hanem csak taknyolunk valamit, akkor nem biztos, hogy van specifikáció. Tesztelni meg akkor is kell.
Egyébként meg ez a taknyolás is egy olyan téma, amit sokan elítélnek, magam sem szeretem és próbálom is elkerülni ha egy projek ebbe az irányba kezd görbülni. De nem Isten ellen való vétek. Nem alapvetően rossz. Csak tudni kell, hogy mire való, mikor használható, és meddig lehet vele eljutni. Nevezhetjük agilis tervezésnek és fejlesztésnek is. Aztán refaktorálunk, de ez egy olyan téma amit már rágtunk eleget.
Visszatérve a specifikáció nélküli alkalmazás tesztelésére, csak úgy lehet tesztelni, ha tisztában vagyunk az üzleti igényekkel. Amilyen jól ismeri a tesztelő az üzleti igényeket, annyira lehet jó a teszt (nem biztos, hogy annyira lesz jó is, ahhoz még tesztelni is tudni kell). És ekkor jöttem rá, hogy miért olyan kevés a tesztelés a szoftver projektekben üzleti oldalon.
Aki az üzlethez ért (a domain-hez), az többnyire nemm ért a teszteléshez. Aki a teszteléshez ért, az nem ért az üzlethez. Ahhoz, hogy tesztelni lehessen tisztességesen, bizony kell a specifikáció, ami összekötné azt a két tudást. Ehhez pedig mindenképpen munkát kell befektetni a megrendelő részéről. Még akkor is, hogy ha a specifikáció kialakításában szakértők segítenek. Legalább nekik el kell mondani, hogy mit is szeretne. Ez pedig munka.
A legtöbb esetben pedig a nem informatikusok valamiért azt várják a szoftvertől, hogy az majd megoldja a problémákat. Pedig nem.
Az informatika segít, hogy mindenki megoldja a saját problémáját, de senki helyett nem oldja meg azokat.
