Menü Bezárás

Time management a szoftvertesztelésben

A tesztelési szakirodalomban gyakran esik szó a tesztelők speciális megközelítéseiről, “skill-set”-ről, sőt, szélsőséges esetben akár a destruktív megközelítésről. Szintén olvashatunk a gyakori stresszhelyzetekről, amelyeket az olyan ─ más szakmákban ritka ─ helyzetek okoznak, mint a fejlesztőkkel való kommunikáció.

Kevés szó esik viszont a szoftvertesztelők időbeosztásáról, ami pedig átgondolást és gondos szervezést igényel, mind projekt-, mind pedig napi szinten.

Nagy általánosságban elmondhatjuk, hogy a tesztelő munkája mindig eltolódott fázisban van a fejlesztő munkájához képest, hiszen ahhoz, hogy tesztelhessünk egy szoftvert, annak előbb meg kell születnie. Valamilyen szinten ez még a test driven development esetében is igaz, hiszen hiába készülnek el tesztek hamarabb, ha nincs min lefuttatni, nincs mit kiértékelni.

Hiába vonják be a tesztelőt már a tervezési fázisban (ha ugyan bevonják, mert ez is ritkaság), a teszttervezési tevékenység ilyenkor csupán néhány meetingen való részvételre, utána pedig a jegyzetek feldolgozására korlátozódik. Ráadásul ebben a szakaszban minden annyira képlékeny még, hogy gyakran még az esetleges új technológiával való ismerkedést sem lehet igazán határozottan elkezdeni.

Az eltérés a waterfall metodológia esetében a legnagyobb. Itt az egyes fázisok akár hónapokig is eltarthatnak. Szerencsés esetben az ezekre rendelt tesztelők ilyenkor még az előző projekt tesztelésével elfoglalhatják magukat. Hallani viszont olyan cégekről, ahol kifejezetten erre a projektre vesznek fel új kollégákat akik sajnos ezen időszak alatt tétlenségre vannak kárhoztatva. A tesztidőszak végén ennek viszont megvan a böjtje a szoros határidők és a túlórák formájában. Az ehhez hasonló “tétlen” időszakokra érdemes egy listát vezetni, amely ilyenkor előkapható és viszonylag könnyen ütemezhető: csapatépítők, konferenciák, továbbképzések, tréningek. Érdemes a kiválasztott új technológiákkal is ebben az időszakban ismerkedni ─ már amennyire lehet, mert néha fontos technológiai döntések is csak az implementáció során dőlnek el.

Agile, scrum, Kanban és társai esetében torlódás figyelhető meg. Az aktuális sprint vagy egyéb fázis teszttervezése és a sorban elkészülő elemek tesztelése közben kell foglalkozni az előző sprintről átcsúszott elemek tesztelésével ─ vagy ami még zavaróbb, máshonnan beeső itemek ad hoc tesztelésével, mert mondjuk most készült el ezekhez egy modul, amit gyorsan meg kellene nézni. A sok-sok teendő rendszerezésében segíthet az ABC-lista, melyben az ábécé eleje jelenti a nagyobb prioritású feladatokat. Könnyen látható, hogy a fejlesztésben részt vevő bármilyen szerepben a legfontosabb feladatunk a production, vagyis a futó környezet optimálisan tartása (“Keep The Lights On”). Ezért nyilván a production-t támogató, support tevékenységet segítő feladatok élveznek A-s prioritást. Hasonló logikával kapnak B-t az előző sprint elemei, hiszen azok már a végső deployra, release-re várakoznak, gyakran a többi projekt résztvevő (projekt managerek, business analystek) figyelő tekintetétől kísérve. Sajnos ilyenkor kerül sor a fejlesztők “zaklatására” az adott itemmel kapcsolatos kérdésekre, ami kizökkentheti őket az adott (vagyis már a következő!) sprintbéli feladataikból. Ezen helyzeteken könnyíthet a rendszeres státusz kommunikáció, hogy az adott csapat tudja, a tesztelő mit és miért tesztel. Ilyen logika mentén kapnak C prioritást az aktuális sprint tesztelendő elemei.

A listák kezelésére népszerű appok is rendelkezésre állnak, azonban érdemes minél egyszerűbbet, letisztultabbat használni, lehetőleg pár milliós letöltés fölöttit.

Az alapos tesztelés és a minél kevesebb production-beli hiba egy egyszerű módszerrel, a Pareto-analízissel is biztosítható. Az elvet Vilfredo Pareto 1906-ban fogalmazta meg, azóta széles körben használják 80/20-as szabály néven. Esetünkre ez úgy fogalmazható át, hogy a tesztelendő szoftver funkcióinak 20%-át fogják a felhasználók az esetek 80%-ában használni. Ennek segítségével már a tesztesetek tervezésekor érdemes átgondolni, mely funkció tesztelésére mennyi időt fogunk felhasználni a sokszor igen szűkös keretből.

Külön tervezést igényel, ha a tesztelő valamilyen új technológiát szeretne elsajátítani, márpedig a folyamatos tanulás rohanó világunkban megkerülhetetlen (ígérem, igyekszem minimalizálni cikkemben a közhelyek számát ─ ez utóbbival viszont kivételesen egyetértek). Ezt viszont a mindennapi feladatok közé beszuszakolni meglehetősen nehéz. Az egyik lehetőség a rutin megtörésére a horizontális foglalás: ebben minden nap ugyanazt az idősávot foglaljuk le az adott tevékenység elvégzésére. Ideális erre pl. az ebéd utáni kávé elfogyasztása: a youtube-on remek 8-10 perces oktatóvideók találhatók, amelyeket ezen időszakban saját tempónkban feldolgozhatunk. Személyes kedvencem a kora reggeli órákban (akár 5-től!), csöndben és nyugalomban végzett tanulás. Pár hónap alatt látványos haladást érhetünk így el az adott témakörben.

A másik módszer a vertikális foglalás, melynek során egy egész napot (vagy hasonló nagyságú blokkot) jelölünk ki. Előnye, hogy jobban el tudunk mélyedni az adott témakörben, hátránya viszont, hogy nehezebben megvalósítható a meetingek és egyéb rendszeres tevékenységek miatt.

Ha már a zavaró tevékenységeknél tartunk, érdemes megemlíteni a 2 perces szabályt, ami az irodai környezetben nem a földre esett szendvicsre vonatkozik, hanem arra, hogy a 2 percnél rövidebb időt igénylő feladatokat (pl. csapatépítőre ebéd rendelése, cafeteria utalványok átvétele stb.) érdemes azonnal elvégezni, így nem gyűlnek fel, nem fog az illetékes kolléga két nap múlva lejáró határidőkkel zargatni.

Természetesen a legnagyobb időrabló, ha olyasmin dolgozunk, ami nem a mi hatáskörünkbe tartozik — a tehetséges tesztelőket gyakran keresik meg ezzel. Ilyenkor sajnos nem tehetünk mást, mint gyakorolni a határok meghúzását, hacsak nem akarjuk magunkat 10-12 órás munkanapokkal végkimerülésbe hajszolni ─ ráadásul valamelyik “megrendelőnk” valószínűleg így sem lesz elégedett. A tesztelési scope szilárd meghatározása és a prioritási lista világos kommunikálása egyértelművé teszi az ilyen helyzeteket.

Végül szót kell ejteni a magánélet és a munka összehangolásáról az idő szempontjából. Ebben a népszerű naptár appok lehetnek segítségünkre, melyekkel összehangolhatjuk, mikor melyik területre kell jobban koncentrálnunk. Az ismétlődő események felvitelével és a megfelelő figyelmeztetések beállításával nem kell semmit észben tartanunk, összpontosíthatunk a kognitív tevékenységeinkre. Itt is érdemes integrált egyszerű eszközöket használni, hogy ne kelljen velük sokat bajlódni.

Szegedi László

A szerző tizenegy éve foglalkozik szoftverteszteléssel, kedvenc területe a tesztelés humán oldala. Debrecenben él, két kisgyermek édesapja.

Latest posts by Szegedi László (see all)

Vissza