A tesztesetektől a mind map-ig: egy személyes tapasztalat

A tesztelési módszereknek és a teszteszközöknek összhangban kell lenniük egymással. Valójában a tesztelési módszertannak tartalmaznia kellene a teszteszközök listáját és használatának módját is. Projektenként változhat a tesztelési módszerünk, -folyamatunk ugyanúgy, mint az eszközkészletünk. Éppen ezért érdekelnek azok az írásokat, ahol a módszertan- és eszközválasztások személyes tapasztalatairól esik szóA tesztelési módszereknek és a teszteszközöknek összhangban kell lenniük egymással. Valójában a tesztelési módszertannak tartalmaznia kellene a teszteszközök listáját és használatának módját is. Projektenként változhat a tesztelési módszerünk, -folyamatunk ugyanúgy, mint az eszközkészletünk. Éppen ezért érdekelnek azok az írásokat, ahol a módszertan- és eszközválasztások személyes tapasztalatairól esik szó.

Ennek az ügynek az apropója egy komment volt az egyik blogomon (http://testingfuncional.wordpress.com), ahol egy kutatás eredményéről kérdeztek amiben teszteset menedzsment eszközöket teszteltem valamikor 2011 elején.

A kutatást néhány hónap után abbahagytam, mivel lassan rájöttem, hogy a teszteset menedzsment eszközök nem illeszkednek a jelenlegi munkafeladataimba, de ezt hivatalosan nem közöltem.

Most sem lezárni szeretném, talán majd megújítom valamikor a jövőben, de két évvel az említett kutatás után az a helyzet, hogy elég jól elboldogultunk és teszteltünk tesztesetek és teszteset menedzsment eszközök nélkül is. Most leírom hogyan csináltuk.

Mielőtt elkezdem, szeretném leszögezni, hogy nem akarom megmondani mi a legjobb vagy a legrosszabb, ez csak egy személyes tapasztalat, egy esettanulmány ha úgy tetszik. Csak egy kis elgondolkodtató anyag, ha ilyen helyzetbe kerülsz. Remélem segít 🙂

A környezetünk

Megpróbálom összegezni a környezetünket néhány szóban, lépj kapcsolatba velem ha esetleg nem látod át a teljes képet:

• 2 db web-alapú alkalmazás tesztelése.
• Mindkettő érett alkalmazás, több mint 3 éve léteznek külön-külön.
• Több, mint 500 use case (és növekszik!), egészen az egyszerű CRUD-től (create, read, update, delete) a hatalmas és összetett belső rendszerintegritás esetekig, melyekben nagyon sok feltételes értelmezést és üzleti logikai szabályokat találhatunk.
• 2 magányos farkas tesztelő részleg, amikhez 4-5 szuper okos fejlesztő társul.
• Átlagosan 2-3 kiadás havonta
• Nincs automatizálás (a vizsgálat elején)

Az első dolog ami eszembe jutott, hogy szükségünk lesz egy menedzsment eszközre ami kezeli ezt a +500 tesztesetet (mondjuk nyomon követi minden eset boldogságos útját), így ha azt várják tőlünk, hogy +500 tesztesetet fejlesszünk és ezeket karban is tartsuk anélkül, hogy új csapattagokat vennénk fel vagy lelassítanánk a release-ek gyorsaságát.

Mi nem tudtuk megtenni ezt a befektetést, mert a figyelmünk tulajdonképpen eltolódott volna a tesztelésről a tesztesetek létrehozása és karbantartása felé. Ez így egy végtelen feladat lett volna, mert minden hónapban van pár új eset plusz néhány régebbit is újra át kell nézni. Az új teszteseteket meg kell írni, a régebbieket pedig módosítani, ráadásul egy bizonyos pont után fel kellett volna kutatni a használaton kívüli utakat/teszteseteket is ha az idő engedi.

Mit csináltunk abban az időben?

Az első időkben, két évvel azelőtt ahogy a kutatás elkezdődött, megpróbáltam létrehozni a teszteseteket Excel formátumban a tesztelési fázis legelején (annak idején vízesés-modellt használtunk). A következő tanulságra jutottam:

• A tesztesetek a tesztelés közben fejlődnek ki, szóval az elmét és a felhasznált eszközöket ilyen hozzáállásra kell felkészíteni.
• A tesztesetek karbantartása és újra használata kényes téma, nehéz kezelni egy ilyen gyorsan változó környezetben mint a miénk, a fent említett okok miatt.

Ezzel a hozzáállással azt találtam, hogy több időt töltöttem az Excel táblás tesztesetek létrehozásával, szerkesztésével és módosításával mint magával a valós teszteléssel. Szépen lassan leadtam az ötletekből, először elhagytam a tesztesetek újra használatának ötletét, így a karbantartási gondok is eltűntek. Azután elvetettem azt az ötletet, hogy egy egész sor tesztesetet készítsek a tesztelés megkezdése előtt, inkább egy sokkal dinamikusabb teszt tervezést és végrehajtást pártoltam.

Egyfajta felfedező tesztelést végeztem anélkül hogy tudtam volna, de kényelmetlenül éreztem magam, mert nem volt teszt dokumentációm. Ezért kezdtem el kutatni a teszteset menedzsment eszközöket.

És … a mind map (elmetérkép) belép az épületbe!

Mialatt a eszközöket kutattam, megpróbáltam rájönni, hogy a többiek mit csináltak hasonló esetekben, ekkor fedeztem fel, hogy a felfedező tesztelés egy létező dolog, sőt számos befolyásos tesztelő nagyon is nagyra értékeli. Illetve ekkor bukkantam rá a mind map-re is.

A nem hivatalos felfedező tevékenységem során, megpróbáltam átváltani az Excel tábláról és a Notepadről, és elkezdtem az Xmind-ot használni, mint támogató eszközt.

Ekkor volt először egy aha-élményem, mivel a mind map a tökéletes eszköz a tesztelés közbeni tesztek fejlesztésére és végrehajtására, tulajdonképpen a tesztelési ötletek a tesztelés közben fejlődnek ki. A tesztelés nagyon élvezetes és kreatív lesz tőle és ezt érdemes egyszer megtapasztalni. Ehhez még az is hozzájön, hogy lehetőségünk nyílik arra, hogy a ’tesztelési ötletek mind map-et is elkezdjük kifejleszteni az új projektek legelején és ezt fejlesztettük tovább a használat során.

Bele tudunk mélyedni a tartalomba, ezt meg tudjuk osztani a fejlesztő csapattal és a döntéshozókkal, ezáltal a tesztelés elkezdése előtt létre tudunk hozni egy hatalmas tesztelési ötlet gyűjteményt. A tényleges tesztelés ideje alatt pedig ezt az alap tesztelési ötlet halmazt fogjuk továbbfejleszteni, kidolgozni.

A tesztmenedzsment eszközök kutatása ténylegesen lezárult

…abban a pillanatban amikor feltettem magamnak azt a kérdést, hogy miért is akarok egy csomó időt tesztesetek írásával tölteni, amikor tulajdonképpen egészen jól megvagyok nélküle is. A főbb indokok amik eszembe jutottam azok a tesztek végrehajtásának rekordjai, a lefedettség és az újrafelhasznáhatóság voltak. Szóval ezeknek néztem a mélyére.

Csak azért, hogy legyenek teszt végrehajtási rekordok, nem elég indok egy tesztmenedzsment eszköz használatára, így tovább gondolkoztam.

A lefedettség mivel kezdők voltunk a felfedező tesztelésben, kicsit bizonytalan voltam nehogy tesztelés nélkül hagyjunk egy fontos területet egy ilyen dinamikus közegben, de ezért beszerezni egy tesztmenedzsment eszközt nem lett volna érdemes.

Nekem jobban tetszett a legyél jobb a felfedező tesztelésben hozzáállás, másrészről ha lenne eszköz abba be kell vinni az adatokat, fel kell konfigurálni, stb… ami a tesztelés hatékonyságából vesz el időt. Ezáltal a lefedettség is sérülhetne.

És milyen lefedettséget ígér egy tesztmenedzsment eszköz? A tesztesetek lefedettségét a te általad bevitt adatok határozzák meg, így már egy kicsit másként nézhetünk a lefedettségre. Sokkal jobban éreztem magam, amikor a lefedettséget tesztelés közben növeltük a fontos területeknél.

Az újrafelhasználás egy fontos mérföldkő, eldöntöttük, hogy nem használunk fel újra semmit, így az érzékeinket és a felfedező képességünket kell jól hasznosítanunk mindenkor. De valószínűleg át fogjuk még ezt gondolni hamarosan

Mint látható nem találtunk olyan okot amiért a most gyümölcsöző kísérletünket át kellene alakítani egy forgatókönyves változatra.

A következő lépések (néhányat már végre is hajtottunk)

Amikor hivatalosan is eldöntöttük, hogy a felfedező tesztelést mind map segítségével csináljuk, elkezdtük ezt az ötletet továbbfejleszteni, hogy javítsunk a teljesítményünkön.A következő dolgokat végeztük el:

• Időt fektettünk az automatizált ellenőrzésekbe, hogy kombináljuk a mi mélyreható felfedező tesztelési teljesítményünket egy pár általános és egyszerűbb funkcionális ellenőrzéssel más területeken is.
• Szkriptet készítettünk a legkritikusabb tesztesetekről (kb. 5 darabról beszélünk) és létrehoztunk egy mini teszteset halmazt, melyet minden tesztelési ciklus elején lefuttatunk. Ez a teszteset halmaz soha nem lesz automatizált mivel a végrehajtása csak 15 percig tart és szükségem van a gondolkodó tesztelő mind a 7 érzékére, amit egy robot nem tud megtenni. Ezek egyszerű bizonyítékok arra, hogy a felfedező és szkript tesztelés tud egymás mellett is létezni.

Mit tervezünk a közeljövőben:

• Át kell gondolnunk az újrahasználhatóság ötletét. Lehet hogy ki tudnánk fejleszteni egy mind map ellenőrző listát a tesztelési ötletek gyűjteményéhez.
• Ki kell fejlesztenünk egy nagyon egyszerű dashboard-ot, hogy könnyebben tudjunk kommunikálni a tesztelések állapotáról a más helyszínen lévő csapatokkal is.

Befejezés

Ez az. Egy 4 éves folyamatot foglaltam össze kevesebb mint 1500 szóban. Remélem a következő 4 évben is fogok tudni írni még erről. Nézzük meg, hogy még jobbá tudunk-e válni ezen a végtelen és fantasztikus területen.

Szerző: Maurio Edo