Szenior tesztmenedzserként csatlakoztam a divíziómhoz. Alacsony szintû tesztelési kultúrát találtam, a tesztelõk többféle módon veszélyeztették az iterációk sikerét. Krónikus túlvállalás, nem teljesített ígéretek, tesztelési dokumentáció hiánya, a tesztfuttatás ad-hoc megközelítését mondhattuk el a hétköznapokról. Alacsony munkamorál és a hétköznapi túlfeszítés, a jól végzett munka feletti öröm teljes hiánya jellemezte a tesztelõket.

A helyzet jobb megértése érdekében ejtsünk pár szót a szervezeti struktúráról. A szoftverfejlesztõk termékdivíziók szerint kerültek felosztásra. Minden egyes szervezeti egységben több fejlesztõi csapat dolgozott a közös célok érdekében.

Az átlagos csapatsturktúra

• fejlesztési csoportvezetõ, feladatai:
  • felel a csapat általános mûködtetéséért
  • scrum master
  • a programozók vezetõje (szakmai és munkaügyi értelemben is)
• programozó, szenior programozó
• product owner
• architekt
• tesztelõ, szenior tesztelõ

A csapatokat általában a (rész-) termékek szállítására hegyeztük ki – ezalatt jellemzõen a funkcionális értelemben megvalósított részterméket értjük.

Mind a funkcionális, mind az egyéb nem funkcionális rétegei a tesztelésnek instabilan, hiányosan kerültek megvalósításra, kivitelezésre, ezzel az éles környezeteink biztonságát veszélyeztetve.

A tesztmérnökök bár a külsõs tesztmenedzser vezetése alatt álltak, a kirendelt csapatnak tartoztak felelõsséggel, amely elsõsorban a sikeres (-nek mondott) iterációt, és az abban végzett munkát jelentette. Ennek nyomán tesztszakmai továbbfejlõdési lehetõség, önképzés, egyéb tanulási lehetõségek idõ hiányában kifejezetten korlátozottak voltak.

A termékfejlesztési terveink karbantartása a Microsoft Team Foundation Serverben a következõ struktúra szerint történtek: A hosszabb távú fejlesztési tervet epic-ben vettünk fel egy vagy több fejlesztési csapat körülbelül 2-4 hónapnyi munkájaként. Az epic-eket lebontottuk feature-szintre, ami jellemzõen pár héttõl két hónapig terjedõ idõszakban jelentett munkát egy-egy fejlesztési csapatnak. Legvégül beszélgettünk a Requirement szinten lévõ elemekrõl, amelyek egy csapat által, egy iterációban elvégezendõ feladatokat jelöltek.

A fenti dokumentumelemekre változtatási kérelemként (change request) kell gondolni. Az adott termék 1.0-ás változatának tervezése, fejlesztése és leszállítása után, némi idõ elteltével, ugyanazon termék 1.1-es változata kapott egy (vagy több) Epic-et, Feature-t, Requirement-et, de ezen dokumentumok csak az igényelt változást írták le.

Ez a mód önmagában nem lett volna probléma, de a teszteseteket, ha egyáltalán rögzítésre kerültek, egy requirement-hez kapcsolták õket, és a tesztesetek tervezési és futtatási állapotjelzõit félreértetten alkalmazták. Amikor a requirement lezárásra került, a tesztesetek is eltûntek. Eltûntek, mivel a használt tesztmenedzsment eszköz lehetõvé tette a teszteset létrehozását úgy, hogy az egyetlen az eszköz által biztosított felhasználói felületen nem jelent meg, megtalálni csak lekérdezésekkel, a tesztesetekre aggatott címkék segítségével lehetett. Ráadásul a címkéket sajnálatosan rendszertelenül használták.

Ha a fentiek nem jelentettek volna elegendõ kihívást, az agilis fejlesztési megközelítés egy tipikus félreértelemzése is a hétköznapok része volt: “agilisek vagyunk, nincs szükség tesztdokumentációra”.

A szervezeti változtatás megkerülhetetlenné vált.

További, a folyamatot korlátozó tényezõket azonosítottunk: a használatban lévõ eszközrendszer, a fejlesztõkkel kialakult együttmûködési megközelítés megváltoztatásáról szó sem lehetett. A fentiek áttekintése, megértése után, a hosszútávú hatás elérése érdekében a csapatommal úgy döntöttünk, hogy kis lépésekben kezdjük el a munkát.

A regressziós tesztelés: a hozzá szükséges dokumentáció érdekében új kapcsolati nézetet definiáltunk a requirement-ek és tesztesetek közé. Új fogalmat hoztunk létre: az “üzleti funkciót”, amely nem epic-hez, hanem a felhasználók által elérhetõ funkciókhoz kötött.

Független mapparendszer a tesztmenedzsment rendszerben: ezen mappákból minden egyes mappa egy specifikus üzleti funkciót jelenített meg. A fenti rendszer “tulajdonjoga” egy két igen egyszerû szabály szerint az elsõ naptól a tesztelõknél volt:

• A struktúra üzleti funkció alapú: az áttekinthetõség miatt fontos, hogy minden, az adott üzleti funkciót tesztelõ teszteset egy mappában legyen. Nem szabad specializált almappákat létrehozni.
• A mapparendszer részletezése a tesztelõk feladata: olyan szinten kell lebontani a mappákat, teszteseteket, amilyen szinten várhatóak a teszteset-igények a jövõben.

A fentiek mûködtetése érdekében két kiegészítõ szabályt kellett hozni:

• Le kell írni a teszteseteket ez bármennyire is alapfeltétel, ki kellett mondani.
• Amennyiben egy teszteset újra felhasználásra kerülhet, akkor kapcsolni kell a megfelelõ üzleti funkció teszteset mappájába.

A rendszerünket üzleti funkció teszteset-mappáknak, angolul röviden BFTS-nek neveztük el. Ezek után a hosszú, esetenként fájdalmas folyamat, a hétköznapi szokások megváltoztatása következett. Mindennapi, ugyanakkor a munkát legkisebb módon zavaró, finom, de határozott emlékeztetõket alkalmaztunk, miszerint körülbelül 5 másodperc egy tesztesetet bekapcsolni az újrafelhasználás zálogát jelentõ BFTS mappába, viszont ezt könnyû elfelejteni, ellenben mindannyiunk érdeke.

Elkezdõdött a tesztesetek felvétele, és BFTS-be sorolása. Pár hónap elteltével a termékeink fejlesztésében elérkeztünk a következõ nagyobb verziókhoz, és ekkor már a tesztelõk maguk kezdték élvezni, felhasználni a saját igényeik alapján rendezett, áttekinthetõ, könnyen megérthetõ teszteset-könyvtárat.

A BFTS alapú teszteset-katalógus mellett ún. magas szintû teszttervezést (high level test designs, HLTD) kezdtünk alkalmazni, amelynek keretén belül a tesztmérnök a megkapott requirement-et átnézte, megértette, és az adott requirement-re értelmezett tesztelési célokat laza, informális módon leírta.

A HLTD feljegyzéseinket a tesztelõink csapattárs programozókkal és más tesztelõkkel átnézették, közös munkában javították, ezzel az ebbõl létrejövõ tesztesetek kezdeti minõségszintjét növelve.

Összefoglalva a fenti munkafolyamat-változásokat: amikor egy tesztelõnk új igényt kapott, létrehozott egy requirement-alapú tesztkészletet, amelybe szöveges módon rögzítette a magas szintû teszttervet (HLTD). A folyamat során a tesztelõ megértette az esetleges újrafelhasználási lehetõséget, és az ezzel együttjáró BFTS belépési pontot, ahova a tesztkészlet alatt létrejövõ teszteseteket csatolni kellett.

Ezt követte a tesztesetek futtatása, az iteráció és a teszt lezárása, majd a tesztesetek átnézése, a futtatási eredmények beállítása, és végül a szükséges riportok elkészítése.

Ezzel a tesztelõk megértették és megélték, hogy a teszteset jól megírva, visszakereshetõen az õ hozzájárulásuk a termékfejlesztés sikeréhez. A fent vázolt módszerek (BFTS, HLTD) a tesztelõk saját, közös eredménye, amely többek között az együttmûködést és a termékszemlélet minõségét is emelte.

Mélyebben átláttuk saját munkánkat, ebbe beleértve a tervezéshez, kivitelezéshez szükséges idõt, valamint tesztjeink újrahasznosíthatóságára is jobban tudtunk koncentrálni.

Összességében az iterációs vállalások biztonsági szintje emelkedett, kockázataink csökkentek, elkezdtük újraépíteni a bizalmat.

Egy iteráció átlagos tesztelési erõforrásának csökkentésével új utak nyíltak meg elõttünk, többek között a felszabaduló idõt tesztautomatizálás tanulásával és gyakorlással töltöttük.

Két hónap kellett a közös probléma elemzésre és a technikai, módszertani lehetõségeink feltérképezésére, kilenc hónap szükségeltetett a hétköznapi szokások megváltoztatására. Körülbelül két év után a BFTS teljes mértékben önállóan mûködik, több mint 6000 tesztesettel a mappáiban.

Forrás: Requirements Mapping Using Business Function Test Suites
Szerző: Schaffhauser Balázs