Miért nem elég az ellenőrzés?

Ha megkérdeznék tőlünk, mi hogyan definiálnánk az ellenőrzés fogalmát? És a tesztelését? Mi lehet a tesztelés célja? A cikkben egy gyakorlati példán keresztül láthatjuk, hogy az ellenőrzés nem egyenlő a teszteléssel.

Itt egy konkrét, megtörtént eset egy tesztelésről, ahol a hangsúly nem az ellenőrzésen volt, és nem tartalmazott olyan előre meghatározott kérdéseket, melyekre csak igen, vagy nem válasz létezett.
Ma reggel egy korábban érkezett e-maillel bíbelődtem, melyben ingyenes frissítést ajánlottak egy PDF-konvertáló csomagra, amit nevezzünk most „PDFThing”-nek. Elmesélem a történteket, és megosztom veletek az ezzel kapcsolatos gondolataimat.

Mivel az e-mail-t kimondottan nekem címezték, és fel van tüntetve, hogy korábban megvásároltam a frissítési lehetőséget, feltételeztem, hogy a cég rendelkezik az összes olyan adattal, mely alapján beazonosíthatják az általam használt terméküket.

Aztán ott volt ez a sor: „Hogy megkapja a frisítést, szükségünk lesz a termék sorozatszámának (avagy a licenc-kulcs) megadására. Ez csak pár percet vesz igénybe. [Hogy találom meg a sorozatszámom?]” (A szögletes zárójelben lévő szöveg egy link)

Feltűnt, hogy elgépelték a „frissítést”. A helyesírást lehet ellenőrizni, és egy helyesírás-ellenőrző még meg is találhatta volna a hibát. Ám az ellenőrzés nem ad garanciát a hiba javítására. Kételkedtek? Mi van, ha azt mondom, hogy az „ellen őrzés” nem garantálja a jó helyesírást. Sőt, még az „el len őrzés” sem. Nektek bizonyára rögtön feltűnt, de egy helyesírás-ellenőrző elsiklott volna felette.

De látok egy ennél sokkalta súlyosabb hibalehetőséget. Ha a cég rendelkezik az engem érintő adatokkal, miért nem nyújt közvetlen és azonnali segítséget a sorozatszám megadásához? Lehetne például egy „Az Ön sorozatszáma…” sor, vagy ha aggódnak, hogy illetéktelen kezekbe kerül a levél, akkor egy „A sorozatszám megtalálható a PDFThing menüjében a…” féle megoldás is működőképes lett volna.

A linkre kattintva egy GYIK oldalra kerültem, mely tele volt kérdésekkel. Szerencsémre a „Hol található a PDFThing sorozatszáma?” kérdésre már ott is volt a válasz.

„A sorozatszám helye függ a vásárolt termék verziójától, illetve a vásárlás helyétől. Ha a PDFThing 7-et a weboldalunkon vásárolta meg, akkor az Ön sorozatszáma (alfanumerikus karakterek) megtalálható a Súgó fül Névjegy menüjében.”

Nekem viszont PDFThing 6-om volt, amit egy boltban vettem. Ezért egy szólással élnék: következetesség egy magától értetődő céllal. Ezen válasz magától értetődő célja az lenne, hogy információt nyújtson a felhasználónak *bármely* PDFThing verzió esetén, legyen az *bárhol* vásárolva. De a válasz nem ezt a célt szolgálta. Ez hiba lenne? Nem tudom, hogy a termék tulajdonosában egyáltalán felmerült-e ezen hiba lehetősége. Egy hiba, melyet célszerű lenne kijavítani, így nem adhatok igen vagy nem választ. Amit viszont tesztelőként megtehetek, hogy jegyzem a hibát, majd tovább állok.

Úgy döntöttem megnyitom a jelenlegi PDFThing szoftverem, és megpróbálkozom egy következetességen alapuló heurisztikus kereséssel. Bizonyára következetes módon fejlődött a szoftver, a termékek egységesek, és ez az egység magában a szoftverben is megtalálható. Talán a sorozatszám is ugyanott van a 6-os verzióban, mint ahol a 7-es verzióban is megtalálható. Így rákattintok a Súgó fülre, majd a Névjegy menüre. Ám a sorozatszám nem található a GYIK-ban leírt helyen. Minden tiszteletem a terméké, de az a szöveg félrevezető és pontatlan. A következetességnél maradva, más programok esetén is gyakori, hogy a sorozatszámot a Súgó/Névjegy menübe helyezik. Mindent összevetve ez igenis problémának tűnik. Vajon a termék tulajdonosa is így fogja látni?

Halványan rémlik, hogy a termék regisztrálásakor kaptam egy e-mailt, amely tartalmazta a sorozatszámot is. El is kezdtem keresni ezt a levelet. Beletelt pár percbe, de végül megtaláltam. Kimásoltam a vágólapra a sorozatszámot, majd irány vissza az eredeti e-mailhez, és rákattintottam a termékfrissítési lehetőségre. A saját türelmetlenségem és elkeseredettségem azt sugallta, hogy itt valami probléma van. Megjegyezném, hogy bár lehet érzelmi reakciókat tesztelni, ellenőrizni már nem igazán lehet. A legjobb, amit tehetsz, hogy már előre felkészülsz bizonyos esetekre, mint például az átfutási idő, amíg a szoftver végrehajt egy folyamatot. Méréssel foglalkozó teóriák ezt helyettesítő mérésnek nevezik – amikor egy bizonyos mértékegységet használunk arra, hogy lemérjük azt az egységet, ami valójában érdekel minket.

A letöltés végeztével hozzá is kezdek a telepítéshez. Jön a kérés, hogy adjam meg a korábbi verzióhoz használt sorozatszámot, amit én meg is adok. A telepítő elfogadja, majd megkérdezi, hogy hova szeretném telepíteni a PDFThing új verzióját. Feltűnt, hogy a telepítési útvonal a 7-es verzió mappájára mutat. Feltételezem, hogy a szoftver korábbi verziója nem kerül törlésre, ezért az alapértelmezett könyvtár helyett inkább magam választok. Kiderült, hogy az új program valóban nem cseréli le a korábbi változatot. Probléma vagy sem? Ennek ellenőrzésére be kellett volna programozni egy szabályt.

Megnyitom a Programok hozzáadása/törlése menüt, és hozzákezdek a PDFThing 6 törléséhez. A program a következő ablakot dobja fel: „A következő alkalmazásokat be kell zárni a művelet folytatásához.”, majd az alatta lévő kis ablakban meglátom, hogy egy levél címére mutat, amit épp az Outlookban szerkesztek. De ez érthető, hiszen a PDFThing 6 egy eszköztárat telepít az Outlookhoz, így közvetlenül tudok PDF-et nyomtatni a levelezőből. Ugyanakkor magára az Outlook-ra nincs utalás. Tehát akkor a szoftver tervezője szerint ezt a hibaüzenetet kéne látnom?

Bezárom a hibajelzést, majd mentem a levelet a piszkozatok közé. Az eltávolító programba visszatérve rányomok az Újra gombra és az eltávolítási folyamat megy tovább. Úgy tűnik, haladt is valamit. Átváltok egy másik ablakra, dolgozom, amíg a háttérben fut a szoftver törlése. Kis idő elteltével ismét felbukkan a hibaablak, de ezúttal a Microsoft Wordöt kéne bezárnom a törlés folytatásához. A szoftver készítői ezt a működési folyamatot képzelték el?

Kíváncsi vagyok mi lett volna, ha nem próbálom meg letörölni a PDFThing 6-ot. Az Outlook és a Word is kapott volna egy újabb eszköztárat, ezúttal a PDFThing 7-től? Két különálló eszköztár lett volna? Az új lecserélte volna a régit? Talán programozhattam volna ellenőrzéseket erre, de megérte volna? Nem lett volna olcsóbb és gyorsabb már az elején kiszúrni? Talán nem. Lehet, hogy nagy rakás registry-bejegyzés, fájlok és konfigurációs beállítások, meg egyebek kapcsolódnak az Outlook-hoz (és a Wordhöz, az Explorerhez, a PowerPointhoz és az Excelhez), melyek felkutatására már külön program kellene. Egy ellenőrzés során talán fény derült volna erre, és jelezte volna a hibát a programozók és tervezők számára.

A törlési folyamat folytatódik. Majd a közepénél járva felugrik egy böngészőablak, melyben a véleményemre kíváncsiak, hogy miért törlöm le a PDFThing 6-ot? A lehetőségek: „Nem akarom megvásárolni vagy tovább használni a próbaverziót”; „Megvásároltam a terméket és letörlöm a próbaverziót”; „A legfrissebb verzióra frissítem”; „A PDFThing 6 licenc-kulcsát egy másik számítógépen akarom használni”. Úgy vélem, hogy a harmadik lehetőség szükségtelen lenne, ha a PDFThing 7 telepítése során a szoftver automatikusan törölné az előző verziót. Valóban ezt az eltávolítási folyamatot álmodták meg a tervezők?

Megválaszolom a kérdést (frissítek), amit az oldal egy „Köszönjük” válasszal jutalmaz. Eközben a törlési folyamat leállt. Sikeres volt? Nem tudom. 
A designerek úgy tervezték a törlési folyamatot, hogy az minden jelzés nélkül leálljon? Mi lett volna akkor, ha nincs aktív internet hozzáférésem? Az ellenőrzések során nem derült volna fénye erre? Talán az ellenőrzések egy során igen, de önmagukban nem biztos.

Visszatérek a PDFThing 7 telepítéséhez, és újra elindítom. Furcsa mód, ezúttal nem kér sorozatszámot a szoftver. Emlékezne rá az előző próbálkozásból? Nem tudom. Hogy jövök rá erre?
Egy ideig fut a telepítési folyamat, majd a végén felbukkan egy kérdés, hogy szeretném-e megvásárolni vagy aktiválni a terméket. Utóbbit választom, mivel már megvettem. Az aktivációs ablak a sorozatszámot kéri. Meg is adom, és rögvest egy hibaüzenettel szembesülök.

Érdemes megjegyezni, hogy az ablak címe „Információ”; azonban a program neve nincs feltüntetve. Az üzenetre tekintve pedig látszik, hogy milyen szedett-vedett. És a fenébe is, ez a MEGFELELŐ sorozatszám (amit korábban már elfogadott). Ezt akarták a program készítői?

Kinyomom az ablakot, erre az aktivációs ablak egy mozgó grafikát mutat, jelezve, hogy a szoftver vár valamire. Máskülönben úgy tűnne, hogy a program lefagyott. Biztos ami biztos alapon újból rákattintok az „Aktiválás” gombra. És újból előtűnik az „Információs” ablak. Egyéb lehetőség hiányában az ablakokat bezárva felhívom a technikai segélyvonalat, amitől már elég költséges lesz ez a móka.

Most mondhatnátok, ha a PDFThingnél dolgoznék, mint tesztelő, már a tesztelési folyamat megkezdése előtt megkaptam volna ezen információkat, és ezeknek megfelelően állítottam volna össze ellenőrzéseket a termékre vonatkozóan. Szép gondolat. De még ha a lehető legjobb tesztelői csapatban is dolgozunk, a lehető legjobban irányított projektben, amint elkezdünk tesztelni, rögvest olyan dolgokba futunk, melyekre előttünk senki – se a tesztelők, se a tervezők, se a programozók, se pedig a szoftver tulajdonosa – sem számított, vagy vett figyelembe, míg a tesztelés során fel nem tűntek.

Ostobaság azt feltételezni, hogy már az elejétől fogva tudja mindenki, hogy pontosan mit is várnak a szoftvertől. Még nagyobb ostobaság azt feltételezni, hogy ezt pedig tudniuk kéne. A szoftverfejlesztés egy bonyolult folyamat, melyhez nem jár lépésről-lépésre útmutató. Ez egy folyamat. Úgy, mint maga a tesztelés, kutatás, felfedezés, megfigyelés és tanulás.

Az ellenőrzés egy folyamat, egy megfigyelés, mely egy döntési szabályhoz van kötve. A szabály pedig egy alkalmazás egy alapelvén alapul. Az ellenőrzés egy jelet ad, ha a termék viselkedése vagy állapota ellentmondásos az alapelvvel. Az ellenőrzés szabályokat követ, nem heurisztikus. A tesztelés, mely akár több ellenőrzést is tartalmazhat, nem olyan korlátozott. A tesztelési folyamat adhat egy igen vagy nem választ, de előállhat egy megfigyeléssel, egy kérdéssel, egy kétellyel, egy dilemmával, egy új tesztelési ötlettel vagy egy új ellenőrzési ötlettel is. A tesztelés nem szabályok által irányított folyamat. Ez egy heurisztikus folyamat, melynek megfelelő alkalmazása komoly figyelmet és döntésképességet követel.

Az ellenőrzés egy olyan megközelítés, mely biztosítja, hogy a megfelelő válaszokat kapjuk azon kérdésekre és elképzelt válaszokra, melyeket már korábban meghatároztunk. Egy sikeres ellenőrzés nem biztosítja számunkra, hogy a program megfelelő. Legjobb esetben, ha egy ellenőrzés sikertelen, akkor tudhatjuk, hogy fennáll egy olyan hiba lehetősége, amely meggátolja a sikeres működésben.

Az ellenőrzés a tesztelés része, ami szerteágazó lehetőségeket rejt: szembenézhetünk az ismeretlennel, új megfigyeléseket végezhetünk, váratlan hibákba futhatunk bele és új kérdésekkel állhatunk elő. Mindezek ellenére a tesztelés sem arról szól, hogy igazolja: a program működőképes. A tesztelésnek lehet más célja is. Cem Kaner, a BBST kurzuson az alábbiakat hozta fel példának:

• Hibákat találni
• Maximalizálni a hibák számát
• A túl korai állapotban lévő termék kiadásának visszatartása
• Segíteni a menedzserek döntését, hogy szállítsák-e vagy sem
• Minimalizálni a technikai támogatás költségeit
• A specifikációk megfelelő értékelése
• A szabályozások megfelelő értékelése
• A biztonságos használattal kapcsolatos perek kockázatának csökkentése
• A program megfelelő használati területeinek lefedése (megoldások, melyek ellenállóbbá teszik a programot a lehetséges hibákkal szemben)
• Minőség értékelése
• A program rendeltetésszerű működésének ellenőrzése

Ezekhez adnám még hozzá a következőket:

• más termékekkel és rendszerekkel való kompatibilitás biztosítása
• belső felhasználásra való megfelelés
• biztosítani, hogy ami korábban működött, az később is fog
• design-orientált tesztelés, mint a felülvizsgáló vagy tesztelés alapú fejlesztés
• egy rosszul dokumentált termék vagy könyvtár működésének megértése
• egy új eszköz vagy szolgáltatás hasznosságának értékelése
• hibalehetőségek finomítása

Másrészt, gyakran azért tesztelünk, hogy eldöntsük, a termék alkalmas-e a kiadásra, vagy sem. Az erre vonatkozó döntések pedig a menedzserek, a programozók és a tervezők kezében vannak, akik elkészítik a terméket (ám végső soron, a termék jóváhagyásának joga a tulajdonos kezében van). A tesztelés a termék vizsgálatáról szól, hogy felfedjen olyan ismereteket, melyek segítik a jóváhagyási döntést. Néha ez az információ bináris formában jön, már ismert kérdésekre, ellenőrzésekre. Néha pedig ez az információ olyan felfedezés eredménye, mely új ötleteket ad, új veszélyeket hoz magával, és új kérdéseket vet fel azok számára, akik a termék fejlesztéséért és kiadásáért felelősek.

Forrás:http://www.developsense.com/blog/2011/12/

Szerző: Michael Bolton