Kezdjünk beszélgetni a teszteredmények ismeretében

Vajon hányan dolgozunk Agile-ban ami nagyrészt követi az előírásokat? Vagy hányunknak van tapasztalata olyan Agile-ban, ami egy hibrid, vízesés modellhez közelít?

A legutolsó tapasztalatom egy ilyen. A projekt, amin dolgoztam, vízesés modellen alapult. Kezdetben mérföldkövekkel, ismétlődő ciklusokkal dolgozunk, de elmozdultunk az Agile felé és a leadáshoz közeledve kéthetes sprintekre tértünk át. A legnagyobb kihívás a két modell összehangolásában a tesztcsapat és a fejlesztői csapat közötti „ők és mi” mentalitás felszámolása volt. Ennek leküzdése érdekében a teszteredmények ismeretében kezdtünk egyeztetni a további munkáról és a következő futtatások elősegítéséről.

Háttér

Amikor a projekt a hibrid irányba kezdett átmenni az új megközelítés első modulján dolgoztam. Az első szakaszban a rendszerkövetelményeket tanulmányoztam a felhasználói estetek létrehozása érdekében, hogy minél világosabb képet és terveket tudjak a vezetőségnek megmutatni. Ezek segítségével létrehoztunk egy tesztelési követelményekből álló mindmap-et, amelyet (nem kevés harc után) a fejlesztői csapat számára is elérhetővé és használhatóvá tettem.

Bár fel tudtam mérni, hogy az algoritmus-motor – ami az egész projekt alapja volt – miképpen tesztelhető a fejlesztők számára, mindig gondban voltam ez egyes permutációk eredményével. A fejlesztők sosem látták, hogy mit kell igazából tesztelni, de ez a vizuális tesztelési terv segített nekik az unit tesztek elkészítésében.

A kihívás

A funkcionalitás mindig változott a fejlesztés során. A fejlesztők sosem tudtak egy pontos képet adni a készülő megoldásról. Valahányszor hibát rögzítettem, azt vagy azonnal kijavították, vagy érvénytelen hibának minősítették. Továbbra is szükségét éreztem annak, hogy visszajelezzek a fejlesztői csapatnak kiemelve azokat a hibákat amelyek javítása a modul általános minőségének javulásához vezetne még a hivatalos tesztelési időszak előtt. A változó funkcionalitást is figyelembe kellett vennem, hogy ne okozzak nagy fejtörést a fejlesztés folyamán a fejlesztőknek.

A megoldás

A felfedező megközelítést követve, valamint a homályos részek feltárását figyelembe véve egy tiszta képet alkottam a funkcionalitás állapotáról.

Minden scrum eseménynél meg kellett kérdeznem a fejlesztőket, hogy a legutolsó build-ben vannak-e újonnan tesztelhető modulok. Amennyiben voltak, abban az esetben ezt egy JIRA bejegyzésben rögzítenem kellett. Az összes érintett funkció vizsgálatára kiterjedő tesztelés hatókörét mindmap-ben elkészítettem, majd csatoltam a JIRA bejegyzéshez. Minden további jegyzetet is a bejegyzéshez csatoltam.

A tesztkörök nem voltak időhatárhoz kötve, de akkor mindenképp véget értek, amikor a JIRA bejegyzésben leírt összes funkció le lett tesztelve. A tesztelés hatókörétől függően a futtatás néhány óra alatt megtörtént, vagy útközben kiderült, hogy a funkcionalitás az aktuális build-ben valamilyen hiba miatt nem tesztelhető.

A tesztelés folyamán a megjegyzéseket a JIRA-ban rögzíteni kellett és egy előtaggal jeleztük, hogy az ISSUE, vagy QUERY. Például:

·ISSUE: Nincs kész. Hiba a BackgroundProcessingServices.log fájlban. E-mail értesítés kiküldve, de az eredmény hibás.

·QUERY: A hibaüzenet nincs definiálva.

Az ISSUE egy olyan találat, ahol a felhasználói igények és a funkcionalitás nem egyezik, vagy hiba van az alkalmazás működésében. A QUERY pedig a tesztelésből adódó kérdés, ami rendszerint olyan hiányosság, ami nincs definiálva a tervdokumentumokban.

A futtatások eredményét (illetve egy linket a JIRA bejegyzésre) a vezető fejlesztőnek el kellett küldeni, melyről természetesen az üzleti elemző és a termékfelelős kapott egy másolatot.

Ezt utána a felelős fejlesztővel közösen át kellett nézni, megbeszélni minden találatot és az ehhez kapcsolódó JIRA megjegyzést. Meg kellett tudnunk egyezni abban, hogy miket kell azonnal javítani, miket javítunk majd később és mik adódnak a folyamatban lévő fejlesztésből. A megbeszélés eredményét a JIRA-ban rögzíteni kellett.

A következő build-nél a kijavított ISSUE-kat ellenőriztük. Ha egy ISSUE továbbra is fennállt, létrehoztunk rá egy hibabejegyzést, hogy ne kerülje el a későbbiekben a figyelmünket.

Amikor az összes ISSUE kijavításra került és minden QUERY-re választ kaptunk, az aktuális ide kapcsolódó JIRA bejegyzést lezártuk. Ezt a folyamatot minden sprintben újra megismételtük a végső verzióig, a formális teszt fázis előtt.

Mit tanultunk?

Mi, mint scrum csapat, a sprinteken keresztül folyamatosan tanultunk. A következő felfedezéseket tettük:

• Nincs bejáratott út az ISSUE-k átnézésére a fejlesztőkkel.
• Nincs idő hozzárendelve a sprintekhez.
• Nincs semmilyen időkorlát arra, hogy az ISSUE-kat és a kérdéseket mikorra vezessük át hibaként.
• Néhány ISSUE bejegyzés elveszik és csak később, a funkcionális tesztelésnél jelentkezik hibaként.

Fejlesztések

Amikor egy modul elkészült vagyis le lett fejlesztve és tesztelve, akkor át kell nézni minden érintettet bevonva. Különösen a fejlesztő-tesztelő viszonyát elemeztük, hogy kellően jó volt-e a sprintekben a megfelelő teszteredmények elérése érdekében.

Ezeket jegyeztem fel:

• Hozzuk létre a JIRA bejegyzéseket és határozzuk meg a hatókörét úgy, hogy mindmap-be összeszedjük a tesztelendő funkciókat, vagy csak egyszerűen szövegesen leírjuk őket.
• A tesztek szorosan a fejlesztéshez kapcsolódjanak.
• Üljünk össze a fejlesztőkkel, hogy egyetértsünk milyen funkcionalitást kell szállítaniuk.
• A JIRA bejegyzést használjuk arra, hogy megvilágítsuk vele az általunk eltervezett tesztelési feladatokat a fejlesztők számára.
• A funkcionális tesztek eredményét és az ISSUE-kat a közvetlenül a JIRA bejegyzéshez kell csatolni. Legjobb ezt az esti release-ek után reggel megcsinálni.
• Az új ISSUE-kat a fejlesztővel a délután folyamán át kell nézni. Meg kell beszélni, hogy melyik lesz kijavítva, melyikkel nem foglalkoznak és mik a tényleges hibák.
• A kijavított ISSUE-k újbóli tesztje, és az eredmények rögzítése a JIRA-ban.
• Hibák bejegyzése – ahogy előre egyeztettük, vagy olyan ISSUE-k jelentése, amelyek nem javultak ki a következő esti release-ben.
• A JIRA bejegyzés lezárása.

Ezzel azt is meg tudom mutatni, hogy pontosan mely sprintben miket teszteltünk a felhasználói tesztelési fázis előtt. Valamint a felhasználói teszten is sokkal kevesebb hiba várható majd.

Sokkal fontosabb a talált hibák számának a csapaton belüli kapcsolatokra gyakorolt hatása. Két csoportból egy csoporttá váltunk, ennek eredményeként sokkal rövidebb határidőket tudtunk tartani. A fejlesztők tiszta képet kaptak arról, hogyan dolgozunk és miket nézünk a tesztelés során.

Képesek voltunk kiterjeszteni ezt a gondolkodást a hibák javításakor, az újratesztelések idején és egyéb területeken is ugyanezzel a csapattal. Amikor egy fontos hibát találtunk, akkor kiegészítettük azt egy regressziós teszttel, amit jeleztünk a fejlesztőknek is, miként fogunk meggyőződni arról, hogy az adott hiba kijavult. Ezt a fejlesztők a saját munkájuk ellenőrzésekor is használták. A szorosabb együttműködés a projektek felgyorsításában is nagy szerepet játszott.

Forrás: http://www.ministryoftesting.com/2014/12/using-test-output-start-conversation/
Szerző: Iain Bright