Ragadós helyzet
A tesztelői szakma néha elájul a fejlett és költséges eszközöktől, melyek célja a menedzserek segítése lenne, hogy naprakészek legyenek. Ám sokszor szükségtelen ilyen nagy tudású eszközök használata. Michael Bolton bemutatja, ahogy Paul Holland senior tesztmenedzser kis költségű eszközöket használva közelíti meg a problémát, és illusztrálja a tesztelési eljárást.
Kis tudású teszteszközök jönnek segítségül
Paul Holland senior tesztmenedzser (aki a modemtesztelés felelőse az Alcatel-Lucent-nél) egy problémába futott. Egyrészt rendelkezik egy tapasztalt, négy főből álló tesztelő csapattal, ahol a legújabb tag két éve érkezett 5 éves tapasztalattal a cég egy másik területéről. Paul tisztában volt a cégben zajló eseményekkel, és a rá váró feladatokkal.
Másfelől pedig egy kihívással nézett szembe: hogyan adja át az elképzeléseit a csapatáról a projektmenedzsereknek úgy, hogy ne csak informálja őket, de figyelmüket a legfontosabb hibák és projektproblémák felé irányítsa.
Excel és OneNote
A tesztlefedettségi jelentés készítéséhez Paul próbálkozott a munkamenet alapú tesztmenedzseléssel (session-based test management – SBTM) – James és Jonathan Bach leírása alapján (http://www.satisfice.com/sbtm)–, 90 perces időszakaszokat és egyszerű eszközöket használva. Két akadályba ütközött: mivel magasan képzett tesztelői voltak, gyakran volt rájuk szükség speciális projektek esetén, programozók, más tesztelők és termékmenedzserek támogatásához. („kiemelt fontosságú megszakítások”, ahogy Paul hívta őket). Telefonhívások, személyes asszisztencia, válasz email-ek nehezítették meg a tesztelők teszteléssel töltött idejét. Paul arra is felfigyelt, hogy a szakaszok során keletkezett tesztadatokat, eredményeket a résztvevők gyakran rosszul értelmezték.
Először egy Excel-táblázatot próbált a követésre használni. Ami jól is működött volna, ha csak Paulnak kellett volna hozzáférnie. Mivel több embernek kellett hozzáférnie a táblázathoz ellenőrzés és frissítés miatt, a fájl módosítása problémás volt. A táblázatot az emberek figyelmetlenségből nyitva (és ezáltal zárolva) hagyták, akik pedig a zárt fájlhoz nem fértek hozzá, azok nem tudták frissíteni, később pedig el is feledkeztek róla. Ennek eredményeként a tényleges munka és a projekt nyomon követése elcsúszott. Közel másfél évig Paul egy egyszerű fájlt használt a OneNote alkalmazásban, hogy ott kezelje a kezdetleges tesztelési terveket – a tesztelési szakaszok céljait – és az eredményeket. Ez még elfogadhatóan is működött volna egy tesztelő csapaton belül, de valami hibádzott. Paulnak a terveket, a projekt állapotát meg kellett osztania a csapattal, de a csapaton kívüli hozzáférhetőség szegényes volt.
Agilis fejlesztés indul
A cég nemrégiben agilis módszertanokat kezdett el adaptálni, de ezek nagyrészt a programozókat és a termékmenedzsereket érintették. Egyik nap Paul bepillantott egy Scrum-értekezletre, ahol egy whiteboardra lett figyelmes tele post-it cetlikkel. A tábla egy projektről szóló beszélgetés középpontjául szolgált a programozók és projektmenedzserek között. Az értekezlet végeztével a tábla ott maradt, mint egyfajta emlékeztető az összeszedett információkról (http://alistair.cockburn.us/Information+radiator).
„És akkor rájöttem, hogy ha nekik sikerült, nekem is menni fog” – mondta Paul. Felosztotta a táblát három oszlopra: Elvégezni, Folyamatban és Kész. Az egyes szakaszokat cetlikkel jelölte fél napos munkaegységek alapján, ahogy az 1. ábrán is látható. „Fél napokat egyszerű feltüntetni a táblán és könnyen lehet számolni velük. Ennél részletesebb követésre nincs is szükség. Rájöttem, hogy minden más teendőjük mellett a tesztelők másfél, két órát tudnak tesztelésre szánni délelőtt és délután is. Óránként is mérhetnénk az időt, de minek? Csak felesleges nyűg lenne. Ezért is választottuk a munkamenet- és a szálalapú tesztmenedzsment-megközelítések keverékét.”(http://www.satisfice.com/blog/archives/503).
Post-it
Paul minden egyes cetlire írt egy rövid leírást arról, hogy mit kell elvégezni az adott szakaszban, egy adott terv vagy egy felvetett ötlet formájában. Sorba rendezte a cetliket, hogy a legfontosabbak kerüljenek az egyes oszlopok tetejére.
A színek pedig további felosztásra adtak lehetőséget. „Két nagyobb területet kellett lefednünk ebben az adott ciklusban. (Először tesztelnünk kellett az új fizikai réteg átviteli tulajdonságát, másodszor pedig a változó zajszintek stabilizálását.) Ezeket a terveket kék és zöld cetlikre írtuk. A tesztek kidolgozása után a futtatásukhoz szükségünk volt egy működő tesztelési környezetre. Ennek létrehozása egy teljesen más jellegű munka volt, ezért világos sárga cetlit kapott. Lila színt kapott a modem új firmware-verziójának tesztelése, mely független volt az eddigi feladatoktól. Ezek után kezdtünk hozzá a teszteléshez.”
Ahogy a tesztelők munkához láttak, felírták a nevüket a cetlikre, majd átrakták őket az Elvégezni oszlopból a Folyamatban oszlopba. Minden egyes elkészült feladat után a cetli a Kész oszlopba került.
A tábla szinte azonnal rendelkezésre bocsátotta a szükséges információkat. Mivel négy tesztelő volt a csapatban, és 10 félnap egy hétben, Paul hetente olyan negyven cetli átmozgatásával számolt. De nem ez történt. Az első hét végeztével alig 13 terv lett teljesítve. „Úgy tűnt, hogy el vagyunk maradva a munka háromnegyedével! Az emberek el voltak foglalva a dolgaikkal, de ez nem látszódott a táblán, se én, se a csapat, se az ügyfelek nem látták. Kérdésekkel álltunk elő.”<
Továbbgondolt post-it
Az első, amire felfigyeltünk, hogy az előkészületek sokkal több időt igényeltek, mint gondoltuk – nem egy, hanem hat munkanapot.„Tanakodtunk erről. Az egyik javaslat az volt, hogy hat munkanapot szánunk egy újabb tesztelési körre, de amint ezt átbeszéltük, rájöttünk, hogy első alkalommal csináltuk ezt, és sokat tanultunk belőle. Így ezt betudtuk egy egyszeri eseménynek. De a feladat nagyon jó volt, mivel a folyamat láthatóvá tétele (vagy annak hiánya) rávilágított problémákra, melyek nem kerültek látótérbe elég korán.”
Ezzel bővült a cetlik színe. „Most már ha egy tesztelő belefut egy hibába – bármi, ami lassítja vagy nehezíti a folyamatot –, akkor azt egy világos rózsaszín cetlire írja. Amint egy ilyen megjelenik, a hiba azonnal láthatóvá válik az egész csapat számára, köztük a programozóknak vagy a betérő menedzsereknek is. A világos rózsaszín cetlikkel jelezzük azokat a tesztelési terveket is, amikben hibákat találtak. Ezek a tervek a Folyamatban oszlopban maradnak, amíg a hiba ki nincs javítva vagy újra nincs tesztelve.”
A programozók vagy menedzserek látogatásai többnyire a korábban említett magas prioritású megszakítások (pl. váratlan vagy nem tervezett feladatok) miatt történtek. „Eleinte nem mértük a megszakítások idejét, de a kieső munka jó részét kitették. Úgy döntöttünk, kezelésbe kell venni ezeket a feladatokat. Immáron, ha egy termékmenedzser megszakít valakit a munkában, vagy igény érkezik az ügyféltől, akkor ahhoz készítünk egy új cetlit. Ezek először majdnem mindig az Elvégezni oszlopba kerültek, de ha kellően magas prioritásúak voltak, akkor a tesztelők azonnal hozzákezdtek, és a Folyamatban oszlopba helyezték őket. A megszakítások megkülönböztetésére bevezettük a halvány sárga jelölést, így ezeket is azonnal látni lehetett. Jogos a kérdés, hogy miért ne egy világos sárga cetlit használjunk, ami mind a sürgősséget, mind a feladat váratlan megjelenését jelezné. Egyszerű: a világos sárga szín már foglalt volt.”
Ellenőrzés és újratervezés
A hiányzó és „megszakított” cetlik kombinációja még több információt biztosított. ”Az egyik tesztelőt még mindig további feladatok elvégzésére kérték egy korábbi projekten, és nem számoltak azzal, hogy ezt is jeleznie kellett a táblán. Arra is rájöttünk, hogy körülbelül két napnyi sürgős munkát kaptunk hetente. Ennek tudatában rendszerezhettük az esedékes feladatokat, és ennek megfelelően állíthattuk fel a munkafolyamatot. Újra ellenőriztük a fontossági sorrendeket, és heti egy-három alkalommal frissítettük a táblát.”
A csapat arra is felfigyelt, hogy bizonyos tervek néha a vártnál több munkával járnak, így ahogy a feladatok a Kész oszlopba kerültek, a tesztelők azonnal jelezhették a cetliken az adott szakaszra fordított időt. „Nem tudhatjuk mindig előre, hogy mennyi időbe fog telni egy adott tesztelési terv teljesítése. De még így is nagy segítségünkre volt a tábla az adott szakaszokra fordítandó munka kiszámításában.“
A tábla egy vázat adott a munka felosztásáról szóló beszélgetésnek. „A tesztelők időnként páros tesztelést végeztek, ha olyan teszttervvel dolgoztak, ami ismeretlen volt számukra, vagy úgy érezték, két tesztelő figyelme szükséges hozzá. Ilyen esetekben mindkét tesztelő nevét felírták a cetlire, és a megszokott módon haladtak tovább.” Ez elősegítette a lefedettségben való gondolkodást. „Mindig szeretem látni az Elvégezni oszlopban lévő lehetséges feladatok listáját. Ha nem látom, akkor kezdek aggódni, hogy nem használjuk a képzelőerőnket új tesztötletek tekintetében.”
Látható határidők
„A feladatlista továbbá segít sorba állítani a tesztelést a határidőkkel. Mint a legtöbb fejlesztői csapat, mi is kötve vagyunk a határidőkhöz. A projektmenedzserekkel való beszélgetések sokkal könnyebbek, amikor megvitatjuk az Elvégezni oszlop tartalmát a tervezett határidőkkel. A projekt végéig az a célunk, hogy csak alacsony prioritású tesztötletek maradjanak hátra. Ezért a fontos dolgokat amint tudjuk, átmozgatjuk a Kész oszlopba. Bár elmondjuk a véleményünket a projektmenedzsereknek, a végén így is ők szabják meg a prioritásokat és a kiadási dátumot.”
A projekt vége felé Paul a menedzserekkel együtt átnézi a tesztelési törekvéseket. „Van egy táblázatom, amelyben listába foglaltam az összes szakaszt, amihez tesztterv készült. Ezen belül megtalálható az elvégzett szakaszok egy csoportja a felfedezett hibákkal és problémákkal együtt, melyek még mindig nyitottak. Senkit se érdekelnek a lezárt hibák és problémák, így ezekről nem is érdemes beszélni. Ami viszont sokkal érdekesebb a csapat számára, az a teszttervek listája, melyekkel még nem foglalkoztunk; a velük járó kockázatok, ha figyelmen kívül hagyjuk őket. De ezek tipikusan olyan problémák, melyek már jó ideje a táblán voltak, és korábban beszéltünk is róluk. Az emberek már gondolkodtak rajtuk, ezért hamar végzünk az ellenőrzésekkel.”
Összefoglalás
Paul és a csapata már közel egy éve használják a táblát. „Mióta ezt a táblát használjuk, sokkal tisztábban látjuk, mi van előttünk, és így fel is tudunk készülni, jöjjön bármi is. Amikor pedig „Nem”-et vagy „Még nem”-et kell mondanunk, az emberek rögtön láthatják, hogy miért.”
A szoftveriparban gyakran gondolunk úgy az eszközökre, mint magas minőségű automatizáló technológiák. Ugyanakkor egy eszköz lehet bármi, ami kibővíti a lehetőségeinket. Néha a legegyszerűbb, kis tudású eszközök – mint kis post-it cetlik – adják meg azt a segítséget, amire szükségünk van.
Forrás: http://www.developsense.com/articles/2012-02-AStickySituation.pdf
Szerző: Michael Bolton
A szerző
-
12 éve foglalkozik szoftver- tesztelők oktatásával, öt kontinensen. Ő a társszerzője - James Bach mellett - a Rapid Software Testing című kiadványnak, amely bemutatja a bizonytalan körülmények és extrém határidők között végzett szakszerű szoftvertesztelés módszertanát.
Elérhetősége:
michael@developsense.com
http://www. developsense.com