Tesztelés dokumentáció nélkül

Olyan szituációban már biztosan volt minden tesztelő, hogy dokumentumok nélkül kellett tesztelnie. Mit csinálhatunk ilyenkor? Választhatjuk azt, hogy hátradőlünk, feltesszük a kezünket és megvárjuk míg elkészül a specifikáció. De ha konstruktívan, aktívan részt kívánunk venni a projektben, akkor elkezdhetünk dokumentáció nélkül dolgozni a tesztelésen

Nem kell mindig a kész specifikációra várni ahhoz, hogy elkezdjük a tesztelést. Amikor egy ismeretlen alkalmazás tesztelésével állunk szembe, az olyan, mint amikor ismeretlen vizekre evezünk. Nem lehetünk benne biztosak, hogy mivel találkozunk az úton, de van már tapasztalatunk, hogy mire figyeljünk és merre haladjunk. Ha valami meglepőt, vagy váratlant tapasztalunk, írjuk fel, készítsünk jegyzetet! Ezek a felderítő képességeink és sokszor ez minden, amiből kiindulhatunk.

Jó néhány tapasztalt tesztelő szakember mondja, hogy soha ne kezdjünk tesztelésbe teljes és végleges specifikáció nélkül. Ez egy valóságtól elrugaszkodott tanács. Először is rengeteg olyan körülmény lehet, amikor a komplett specifikáció hiányában kérhetnek fel minket a tesztelésre:

• Amikor egy üzleti alkalmazást futtatunk, hogy kiderüljön, találkozik-e az a cég elvárásaival.
• Amikor egy alkalmazás túl régi és ráadásul toldozott-foldozott, az eredeti specifikáció – ha egyáltalán megtalálható valahol – gyakorlatilag használhatatlan.
• Ha egy Agile projekten dolgozunk. Amikor a projekt a távlatokon, a jövő eredményein és az eddigi tartalmakon múlik.
• Amikor a „kész” dokumentáció rengeteg további kérdést vet fel.

Az tény, hogy minél részletesebb egy dokumentáció, annál hosszabb és nehezebben értelmezhető, valamint kevésbé valószínű, hogy teljes körű az adott projektre li vonatkozóan. Sokszor bizonyos információk nem formális dokumentációkban, hanem e-mailekben, csevegésekben vagy a saját következtetéseinkből születnek. Egy gyors megbeszélés a vezetővel kombinálva az értékfelismerő, kockázatfelismerő képességünkkel, valamint az ismert problémák elénk tárnak minden olyan információt, amire szükségünk lehet ahhoz, hogy értékes és használható információt szolgáltassunk a menedzsmentnek.

Egy igazán hatékony tesztelő általában csupán felfedezési képességeivel fel tud tárni hasznos és értékes információkat még akkor is, ha a felfedezés éppen arra hivatott, hogy információkat szerezzünk egy hatékony terv kialakításához.

Pontosan úgy ahogy a történelmi felfedezők, felszerelés és műszerek nélkül az ismeretlen vizeken. Ismerték a napot és a csillagokat, volt iránytűjük, órájuk és szextánsuk, nem csupán a navigáláshoz, hanem a térképek készítéséhez is. Még fontosabb, hogy felfedezéseiket a széleskörű tudásuk és tapasztalataik alapján tették meg, olyan eszközök segítségével, mint számítások, következtetések, az égitestek és a józan paraszti ész. A felderítő, vagy kutató tesztelőknél a tudást a jóslási és a felfedezést megértő képesség jellemzi. A jóslási képesség arra hivatott, hogy rámutasson, hogyan kell (kellene) működni az alkalmazásnak. Egy jós az elvárásoknak megfelelően helyesen fogja meglátni a működésbeli kérdéseket. A felfedező egy ideiglenes ajánlást ad arra, mit kell tennünk, hol kell beavatkoznunk a probléma megoldásához. Ez egyben eszköz ahhoz, hogy megállapítsuk, mire érdemes figyelni, mit tanulhatunk a felfedezés tapasztalataiból.

A HICCUPPS (mozaikszó) egy nagyszerű eszköztár, ami James Bach nevéhez fűződik amely kimondja, hogyan legyen egy projekt konzisztens.

History (történelem): a programfunkcióknak és a szoftver viselkedésének a múlttal konzisztensnek kell lenniük, feltételezve azt, hogy nincs elfogadható indok a változtatásra. Ez leginkább egy régi szoftver új verziójának tesztelésekor nagyon hasznos.

Image (kinézet): A szoftver kinézetének olyannak kell lennie, amilyet a megrendelő és a felhasználók meg akarnak valósítani. Amennyiben ez egy „tucatáru”, akkor úgy is kell kinéznie, mint egy „tucatáru”.

Comparable product (összehasonlíthatóság): Nagy vonalakban képesek legyünk a meglévő szoftvert egy másikkal helyettesíteni. Tehát az általunk megvalósítandó (tesztelendő) szoftvernek összehasonlíthatónak kell lenniük a hasonló alkalmazásokkal.

Claims (igények): A terméknek úgy kell viselkednie, ahogy azt a dokumentáció vagy a megrendelők mondják. Az igények a specifikációk, help fájlok, e-mail üzenetek, vagy folyosói pletykák alapján születnek. Az igények készítőinek, rendszerezőinek meg kell bizonyosodniuk arról, hogy azok mindenki számára egyértelműek.

Users’ expectation (felhasználói igények): A funkciók és kiegészítéseknek annak megfelelően kell viselkedniük, ahogy feltételezzük, hogy a felhasználók akarják.

The Product itself (az alkalmazás önmaga): Az alkalmazás funkcióinak úgy kell viselkedniük, ahogy ez az adott funkcióktól elvárható egy hasonló alkalmazásban attól függetlenül, hogy van-e speciális oka, amiért nem konzisztens.

Purpose (cél): Az alkalmazás viselkedése a megalkotási céllal konzisztens kell, hogy legyen.

Statutes (szabályok): Az alkalmazásnak a szabályozásoknak és törvényi megfeleléseknek eleget kell tennie.

Emlékezzünk vissza, hogy James Bach eszköztára egy ajánlás csupán, mert nem csalhatatlan, nem univerzális. Rengeteg lehetőségünk és eszközünk van arra, hogy eldöntsük az alkalmazás elfogadható-e vagy sem. Vannak felfogásbeli átfedések a pontok között ugyanúgy, ahogy egy felfedezésben is vannak.

Ezzel az eszköztárral felfegyverkezve, képzeljük el a munkát egy start-up vállalkozásnál, ahol a cég a saját szoftverét tervezi kiadni egy CD-n. Az induló vállalkozás behatárolt anyagi lehetőségekkel rendelkezik, ezért a vezetőség azt kéri, írjuk meg a programot a CD-re a népszerű Nero szoftverrel. A CD borító is elvárás, ezért azt kérik, hogy készítsünk pár tervet a Nero Cover Designer-rel, hogy el tudják dönteni megfelel-e az a vállalkozás elvárásainak. Mindenféle terv nélkül egyszerűen csak elindítom az alkalmazást, dolgozok vele és csak a kilépés után hozom meg döntéseimet a működéséről. Az 1-es ábra mutatja a képernyőt, amikor elkezdtük a feladatot.

Yogi Berra-nak igaza volt, rengeteget figyelhetünk meg csupán azzal, ha nyitva tartjuk a szemünket. Az első észrevétel, hogy a betűtípus Arial, és a betűméret 16-os. A vezetőség ehhez a feladathoz nem adott meg betűtípust és méretet. Ha nem csak teszt, hanem konkrét feladat lenne, hogy nyomtassuk is ki a CD borítót, ábrákat és szöveget, akkor valószínűleg a betű méretet és betűtípust is megadják majd. Gondolkodnunk kell tehát most a betűtípuson és a méreten? Lehet,de ez ráér később is, egyelőre el tudunk végezni egyéb feladatokat is. De azért jegyzetelhetünk, hogy kérdéseket tehessünk fel a még pontosabb eredmény érdekében.

Fel kell még tennünk valamit a CD borítóra, ezért tehát válasszuk az új objektum beszúrását (Insert a new object) Object, Insert, Text Box. Ezután dupla klikk, és az új objektum megjelenik, valamint felugrik a következő ablak (2-es ábra).

Valami már így is nagyon furcsa. A betűtípus neve eltűnt és a méret most 8-as. Ha konzisztensek akarunk maradni, akkor a betűtípusnak és a méretnek a szövegdobozban, meg kell egyeznie a borítóéval. Nos, megtaláltuk az első hibát? Azt mondom igen, de természetesen ezt még le kell ellenőrizni. Készítsünk feljegyzést erről is!

Nincs specifikációnk, de ismereteink alapján a Windowsos alkalmazások általában rendelkeznek help menüvel. Az alkalmazások követelmények alapján készülnek. A help fájl általában ezeket a követelményeket tartalmazza, azt hogy hogyan kell működnie az adott alkalmazásnak. Nyomjuk tehát meg az F1-et!

Miért az F1-et? A Windows felhasználóként az F1 hatására a Help fájl megjelenését várjuk el. A Cover Designer egy Windows alkalmazás és így a viselkedésének is olyannak kell lennie. Amennyiben nincs olyan valamirevaló információ, hogy miért működne másképp, úgy kellene működnie, mint egy szabványos alkalmazás. Ez a konzisztencia időt takarít meg és megkönnyíti a program használatának elsajátítását a felhasználók részére, mert nem kell egy újabb módszert megtanulnia ugyanarra a feladatra.

Az F1 hatására egy úgynevezett tooltip jelenik meg az egér kurzornál.

A tooltip azt mondja „Módosíthatod a szöveg tartalmát” és nem azt, hogy „Módosíthatod a szöveg tartalmát a szövegdobozban”. Lehet, hogy szőrszálhasogatásnak tűnik, de vegyük fel ezt egy újabb hibának! Ha ez az én alkalmazásom volna, kínosnak érezném a pontatlan megfogalmazást, amely veszélyezteti az alkalmazás konzisztenciáját. Az alkalmazásnak konzisztensnek kell lennie azzal a képpel, amit a vállalat az alkalmazással mutatni akar. Egy másik dolog: Az F1-nek a help ablakot kellene megjelenítenie, nem egy tooltip-et. A Windows konvenciók alapján a tooltipnek akkor kellene megjelennie, amikor az egérkurzorral egy objektum, vagy elem felett állunk. Jegyzeteljük le ezeket is, melyek valószínűleg egy vagy két újabb hibát eredményeznek majd.

Nyissuk meg a help fájlt egy másik módon: Klikkeljünk a help gombra a megnyitáshoz, majd a keresés panelre és keressünk rá a „text box” kifejezésre (3. ábra). Semmit sem találunk ami a keresett kifejezésre utalna.

Keressünk rá a „Cover Designer” szóra! Minden, amit találunk, a Nero CD-ROM szoftverre vonatkozik. Ez azt jelenti, hogy vagy nincs help fájl a Nero Cover Designerhez, vagy azt jelenti, hogy az F1 megnyomásával nem jelenik meg az alkalmazáshoz. Ez is egy konzisztencia probléma. A felhasználó azt várja, hogy amikor egy alkalmazáson belül lenyomja az F1-et, akkor az adott alkalmazás help fájlja jelenjen meg, ne egy másiké.

Úgy tűnik, hogy fel kell adnunk a Help további tesztelését. Térjünk vissza az első feltételezett hibához és foglalkozzunk részletesebben vele! Nem tudjuk pontosan, hogy mit szeretne a vállalat a CD borítóra pontosan, de ez nem is fontos most. Írjunk be néhány szöveget olyan módon, ahogy feltételezzük, hogy az alkalmazás működik. (4. ábra)

Amikor begépeljük, hogy „Beatles Compilation”, érdekes módon a B beírásánál a betű mérete 8-asról 16-osra változik valamint a legördülő lista betűtípusa Arialra. A felhasználó arra számít, hogy ha beír egy szöveget, akkor nem változik meg a betűtípus és méret, csak akkor, ha azt a felhasználó kezdeményezi. Jelöljük ki a szöveget és válasszunk Comic Sans MS, 26-os méretet! (5. ábra)

Most zárjuk be a dialógust. Rögtön klikkeljünk és nyissuk meg újra! (6. ábra)

A betűtípus visszaállt Arialra és a méret 16-osra. Ez is az alkalmazás konzisztenciáját veszélyezteti. Azt várjuk, hogy ha kiválasztunk egy másik betűtípust és jóváhagyjuk (nem a Cancel gombbal), akkor a beállítások úgy maradnak, ahogy legutóbb kiválasztottuk. Az alkalmazásnak az eredeti céljának megfelelően kellene működnie, és mivel ez nem így van, jegyezzünk fel egy újabb hibát!

Láthatjuk, hogy a dialógus ablakban különböző tab-ok – toll, ecset, kép és szöveg – vannak. Próbáljuk ki! Azt vesszük észre, hogy minden alkalommal, amikor megpróbáljuk újra megnyitni a szövegdobozt és megváltoztatni valamelyik beállítást, a font információk eltűnnek. Ez bosszantó és zavaró hiba, ráadásul emlékszem rá, hogy az előző verzióban ez a funkció működött. Ez veszélyezteti az alkalmazás használhatóságát. Az alkalmazásnak úgy kell működnie, ahogy a korábbi verziókban is működött.

Ezeket a hibákat kifejezetten könnyű volt megtalálni és az utolsóként fellelt hiba további következtetések levonására késztet. Most már elmondhatjuk a cégvezetőnek, hogy nem a Nero-val kellene megoldani a CD borító megszerkesztését, valamint adjunk hálát az égnek, hogy nem készítettünk részletes teszt tervet egy hiányos specifikáció alapján.

Ez egy nagyszerű példa volt, de ha még mindig hajthatatlanok vagyunk abban, hogy tesztelést nem kezdünk specifikáció nélkül, fontoljuk meg a következő két kérdést. Kell ahhoz specifikáció, hogy értékes információkkal szolgáljunk egy alkalmazásról? A specifikáció elkészítése vagy az arra való várakozás tényleg hozzáadott értéket képvisel az elkészítendő riportban?

Ahogy látjuk a legtöbb tartalom nemhogy nincs teljesen rendben, de tesztelhető a specifikáció nélkül is. A tapasztalatunk a Windows GUI-val segített számos hiba felderítésében, továbbá abban is segített, hogy a felhasználó bőrébe bújjunk. Néhány perces kutatás és a fent említett eszköztár figyelembe vételével sikerült számos hibát feltárni. A módszer segített annak a megválaszolásában is miért gondoljuk, hogy az adott működés hiba, úgy hogy nem volt komplett specifikáció a kezünkben. Habár nem volt tervünk, képesek voltunk felfedezni és összegyűjteni a hibákat ezen a módon.

Szerző: Michael Bolton