A PDCA elv alkalmazása a tesztelésben
Dr. W. Edwards Deming munkásságából merítvén, kísérletet szeretnék tenni arra, hogy az általa híressé tett PDCA elvet a programozók és tesztelők közötti munka ütemezésére, egymás megértésére alkalmazzuk.
A klasszikus út
Örök probléma, hogy mikor, milyen tartalommal, milyen céllal érkezik a tesztelésre a fejlesztés alatt álló alkalmazás új buildje; folyamatos a késés, állandóan előfordulnak jelentős, utolsó pillanatban a buildbe tett módosítások.
A teszt csapat meg ilyenkor áll, néz, hogy mi történt. Felkészülni, teszteseteket frissíteni, teszt futtatásokat ütemezni jellemzően már nincs idő. A helyzetet nem egyszer nehezebbé teszi ha az adott build “release candidate” állapotban érkezik, tehát még a teszteléshez alapvetően nem értő termékgazda / projektmenedzser is a tesztcsapat sarkában lohol, követelvén a mielőbbi kibocsátást.
Egy-két ehhez hasonló szituáció - és átvirrasztott éjszaka - nyomán kezdtem el keresni valami egyszerű, kézzelfogható, megvédhető megközelítést a fenti helyzet megismétlődésének elkerülése érdekében.
Deming PDCA elve egyszerűen átlátható, minden oldal által megérthető megoldási javaslatot nyújtott.
Alábbiakban nézzük át hogyan is lehetne a PDCA elvet alkalmazni főként a programozás és a tesztelés kapcsolatában:
PLAN
A programozók feladata az új build tartalmának meghatározása, beleértve a hiba javítási, új fejlesztési feladatokat is. Az ütemezési kérdések tisztázása a projektvezető aktív részvételével. Egyeztetés a dokumentáció írásért felelőssel. A build tartalmának publikálása egy a projekt összes részvevője által elérhető helyen (erre leginkább a hibajegy-, feladatkövető rendszerek alkalmasak, ahol fel kell állítani egy közös, globális szűrő feltételt, amelynek használatával mindenki "ugyanazon az oldalon" van)
A tesztelők feladata a közös területen elérhető tervezett build tartalom alapján, bárhol és bármilyen struktúrában is található, a teszteset “vagyon” frissítendő részének azonosítása; egyeztetés a programozói oldallal, a tervezett funkciók minél szélesebb körű megértése. Nagyon fontos, hogy a tapasztaltaktól eltérően, mindenképp kell, hogy legyen a tesztcsapatban erre szabad kolléga, aki nem az előző build elhúzódó tesztelésén dolgozik. Teszteset frissítés alatt jobb esetben az automatizált tesztek frissítését is érteni kell.
Projektvezetési kérdés, hogy a PLAN fázisnak mikor van vége, illetve van-e egyáltalán definiált vége. Tesztelői szempontból erőteljesen javasolt, hogy legyen.
DO
A programozók feladata a build tervben meghatározott feladatok kivitelezése, hibajavítás, új funkciók fejlesztése. Kisebb mértékben, egyeztetve a teszteléssel, projekt vezetéssel a build tartalom változása is elképzelhető.
A tesztelőknek fel kell készülniük az új build tesztelésére: a meghatározott teszteset frissítési feladatok kivitelezésére, a tesztkörnyezet felállítására és a teszt futtatás ütemezésére.
A projektvezetőnek lehetőség szerint ezt az időszakot minél zártabbnak kell kezelnie, és meg kell védenie a csoportot az utolsó pillanatos módosításoktól.
CHECK
A programozók az elkészült fejlesztési munkákat ellenőrzik, a unit teszt, code review stb. után buildbe fordítják, majd átadják a tesztelésnek.
A tesztelők az előre elkészített teszt környezeten, frissített teszteseteket futtatnak az alkalmazás új buildjén. Hibajegyeket rögzítenek, kommunikálnak a programozókkal a legjobb közös megértés érdekében.
ACT
A programozók a projektvezetéssel közösen priorizálják a talált hibajegyeket, a fontosnak, javítandónak talált jegyeket javítják.
A projektvezető a projekt helyzete és a hibajegyek milyensége alapján dönt a javító build gyors összeállításáról, vagy a következő standard build ütemezésének megkezdéséről.
A tesztelők az esetleges javító build tesztelését végzik. A teszt futtatás során talált teszteset hibákat javítják, belső folyamatokat vizsgálnak, javítanak. Szükség szerint együttműködnek a programozókkal a hibajegyek megfelelő reprodukálása, javítása érdekében.
Az agilis világ
A fentiek talán kicsit követhetőbbé, élhetőbbé teszik a tesztelők mindennapi munkáját egy klasszikus felfogású szervezetben. A 10 éve zászlót bontott agilis szoftverfejlesztési megközelítés a fenti elveket gyúrja össze. A programozók, tesztelők együtt fejlesztik a terméket, nincs lényegi időbeni különbség a teszt tervezés, program tervezés, a kódolás és a teszt eset írás között; az iteráció alatt a scrum master feladata a csoport megvédése a jelentős változtatásoktól. Dinamikus, határok, átadás átvételi pontok (és akár rögzített hibajegyek) nélküli, minden nap érvényesülő PDCA szerinti munkavégzés jellemzi az agilis projektet.
--
Ezen bejegyzés a Tesztelés a gyakorlatban magazin 2011-2 számában is olvasható.
--
Ezen bejegyzés a Tesztelés a gyakorlatban magazin 2011-2 számában is olvasható.
