A PDCA-elv alkalmazása a tesztelésben

Dr. W. Edwards Deming munkásságából merítvén, kísérletet teszek 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 tesztcsapat meg ilyenkor áll, néz, hogy mi történt. Felkészülni, teszteseteket frissíteni, tesztfuttatá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 hibajaví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. Tesztesetfrissí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 buildtervben 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 buildtartalom 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 tesztfuttatá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 tesztkö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 tesztfuttatás során talált tesztesethibá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 teszttervezés, programtervezés, a kódolás és a tesztesetí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.

Szerző:
Schaffhauser Balázs

<< Vissza