A felderítő tesztelés irányítása
Egy munkafolyamatnál az átláthatóság, mérhetőség mindig nagyon fontos. Bármelyik pillanatban is kérdezik meg az vezetőtől, hogy hogyan áll a feladatvégzéssel, korrekt választ kell tudnia adni. Az ad-hoc teszteléssel leginkább ez a baj. Képtelenség pontosan meghatározni az elvégzett tesztelési munkák nagyságát. De mi a helyzet a felderítő tesztelésnél? Hogyan lehet az eredményeket riportálni?
Az örök kihívás, amivel találkozom a felderítő szemléletű tesztelésben az, hogyan lehet irányítani a tesztelési folyamatot és utána hogyan lehet eredményeket felmutatni a megrendelők felé.
Kipróbáltam rengeteg különböző rendszert az évek alatt, de egyik sem hozta a számomra kívánt eredményt.
A legtöbb tesztelés, amit a csapat itt a NewVoiceMedia-nál végez, felderítő tesztelés, ezért meg kellett találnom a módját, hogy megértsem pontosan mennyi munkát végeztünk el és a termék melyik részével töltöttük a legtöbb tesztelési időt és energiát. A számok önmagukban nem mutatják meg, hogy teljesen lefedtük-e a dolgot, de ha kombináljuk azokkal a mérőszámokkal, amelyek a teljes fejlesztési ciklusból adódnak, akkor elkezdhetjük részenként összerakni, hogy mire fókuszál a tesztelésünk és hol van szükség esetleges változtatásokra a termékben.
Egy elgondolás
Egyik hónapban egy gondolat ötlött a fejembe, amiről úgy éreztem, hogy helyes. Kikértem a csapatom néhány tagjának a véleményét a kérdésben. Azt a következtetést vontam le, hogy érdemes volt foglalkozni vele. Azt gondoltam, hogy hagyom egy pár hétig, majd megírom. Nos, íme itt van. Faragtam a rendszeren, hogy képes legyek riportálni a felderítő tesztelésünket.
A kezdetek
Annyi tesztelést automatizáltunk a munka folyamán, amennyit csak tudtunk. Bár az egyeztetéseken a tesztelők rajzoltak, mind-map-eket készítettek vagy jegyzeteltek, hogy mit teszteljünk. Az ötletek minden esetben garantáltak egy felderítést. Ezek lettek a felderítő tesztelési alapszabályaink.
Az alapszabályokat a következő formában írtuk le: DERÍTSEN ki [valamit] [valamivel] együtt, hogy MEGTALÁLJON [valamit], ahogy Elisabeth Hendrickson írja az Explore IT book írásában.
Ezek a szabályok ebben a pillanatban még csak vágyak – még nem futottak és az igazság az, hogy nem is mindegyikük fog lefutni. Még keresünk további szabályokat, vagy kiveszünk néhány meglévőt, éppen ahogy az élet alakul.
Felderítő munkafázis menet
Minden tesztelő a saját sorrendjében és stílusában hajtja végre az adott munkafázisokat. A feljegyzéseiket is különböző helyen és módon tárolják. A csapatban a legtöbben Rapid Riporter-t használnak, én személy szerint EverNote-ot, és néhányan Word-öt vagy Notepad++-t. Nem számít, milyen eszközzel készítenek részletes feljegyzéseket a munkafázisban. Ezek a feljegyzések személyesek számukra, de publikusak mindenki számára az üzleti felhasználók közül. Lehet, hogy nem is mondanak semmit mások számára, addig amíg nem tudják, ki készítette őket. Ez jól is van így!
Ezek a feljegyzések a munkafázisokban bármilyen formában is keletkeznek, a végén összefutnak a belső wiki rendszerünkben a Confluence-ben. A Confluence-ben van a felfedező tesztelésnek egy külön erre dedikált helye. Ezen a helyen van egy egyszerű hierarchiánk: Év->Hónap->Teszt szabály.
A szabályok a következőképpen kapnak nevet: [Tesztelő monogramja][NNHHÉÉÉÉ][Szabály száma]. Például: RL_16062013_1 és RL_16062013_2.
Sablont használunk, amikor ezeket a szabályokat készítjük, ezért a Confluence-ben minden szabály konzisztens és könnyű közöttük a navigálás és a keresés. A Confluence-nek van egy oldala, ahol egy táblázat formájában látjuk a szabályokat. A kötelező mezők a szabály neve, a tesztelő neve és a dátum.
A lap további része üres, hogy szabadon másolhassunk a munkafázis feljegyzésekből, vagy állományokat csatolhassunk a teszteléshez, mint CSV vagy TXT fájlok. Ez a Confluence oldal lesz a végleges eredménye a felderítő munkafolyamatnak. Egy referenciaponttá válik a Pivotal Tracker story-k számára és az audit elengedhetetlen része lesz (verziók és hozzáférések szabályozva). Lehet, hogy soha nem olvassuk újra ezeket a feljegyzéseket de rögzítjük a biztonság kedvéért, ha egyszer szükségünk lesz rá.
Az első résznek vége a munkafázis dokumentálva van az elvárt módon. Most a metrikákat kell kigyűjtenünk.
Riportolás
Egy nagyon egyszerű Google formot csináltam az eredmények rögzítéséhez.
Amikor a csapat kész a Confluence oldallal, megnyitják a Google formot és kitöltik azt.
Az űrlap alapadatokat kér, mint tesztelő neve, fő terület, a szabály címe, és a Confluence link elérési útja. Hány óráig tesztelt (a legközelebbi órára kerekítve), valamelyik story linkje, böngésző típusa, operációs rendszer és környezet. Minden mező kötelező.
Amennyiben ez a Google dokumentum elmentésre kerül, meg is vagyunk az alap riportolással.
Most meg tudom nézni, mennyi munkafázison dolgoztunk, mely főbb területeket teszteltük a terméken. Látom a Confluence linkeket, dokumentumokat, látom, milyen böngészőkkel dolgoztunk, és hogy hány különböző munkafázist indítottuk különböző időintervallumokban. Csináltam egy grafikont, ami mutatja a munkafázisokat tesztelőként, a munkafázisokat böngészőnként, funkcionális területenként és a napi átlagokat is.
A következő lépés, hogy ezeket az adatokat áttoljuk a felettesünk asztalára és láthatóvá tegyük számára. Az összes adattal láthatóvá válnak a minták és a trendek, amelyek a jövőre nézve információval szolgálnak. Biztos, hogy az egész terméket lefedtük a teszteléssel? Túl gyorsan haladtunk, vagy inkább túl lassan? Minden olyan böngészőt teszteltünk amit kell? Hogyan tudjuk fejleszteni, még hatékonyabbá tenni a tesztelést? Az adatok önmagukban adnak használható információt a döntéshozóknak?
A számok magukban semmit sem jelentenek de összességében elég információt adnak, hogy meggyőződjünk, hogy azt csináltuk, amit az ügyfél akart.
Súrlódások
Ez nem egy tökéletes rendszer, de ezt használjuk és pofon egyszerű a feladatok elvégzéséhez. Eddig egy bonyolult rendszerrel bajlódtunk és ahelyett, hogy különféle programokat próbálgattunk volna, hogy megtaláljuk azt ami teljesen megfelel a mi munkánkhoz, most így dolgozunk és ez egyáltalán nem jelent hatalmas pluszköltséget. Ez a rendszer változni fog, ebben teljesen biztos vagyok, de most teszteljük és meglátjuk, hogy milyen eredményeket fog hozni.Te milyen rendszert használsz? És működik is?
Forrás: http://thesocialtester.co.uk/managing-exploratory-testing/
Szerző: Rob Lambert
A szerző
-
Több éve szoftvertesztelőként dolgozom. Érdeklődési körömbe tartozik a kommunikáció, kreativitás, közösségi oldalak, webes megjelenés, néprajz- kutatás (több más dolog között).
Kreatív vezetője és a Tesztelési felület szerkesztője vagyok a Software Testing Club oldalnak (www.softwaretestingclub.com).
Tesztvezetőként munkálkodom a New Voice Media-ban(www.newvoicemedia.com).