Agile Testing 1.

Aki dolgozott már életében kisebb vagy nagyobb szoftverfejlesztői csapatban, egész biztosan találkozott már a különböző módszertanokkal, amik mind a csapatmunka koordinálását, a produktivitást igyekeztek segíteni.Jó pár éve az egyik legelterjedtebb ilyen módszertan az Agile, azon belül is a Scrum, aminek sok-sok előnye közül leginkább a rugalmasságot, a folyamatos kommunikációt és ezek közös eredményeképpen a hatékonyságot szokás kiemelni.

Ezernyi könyv és publikáció, tanfolyam, eszköz hozzáférhető bárki számára, akit érdekel a téma, én itt most egy olyan területtel szeretnék kicsit bővebben foglalkozni, ami több szempontból is perifériának számít, és talán emiatt mégiscsak érdekesebb lehet minden "Agile-csapattag" számára.

Van egy tesztelőnk, mit kezdjünk vele?

Kezdetnek tételezzük fel, hogy az ügyfél, a projekt menedzser, a fejlesztők és a tesztelő is nagyjából egyetért abban, hogy tesztelésre szükség van, abban viszont egészen biztos vagyok, hogy a mikor, mit és mennyit kérdésekre mindenki más választ adna. Az Agile Testing c. könyv egy jó kiindulópont lehet ezeknek a szempontoknak a közelebb hozásához, vonalvezetőként használva nulláról is fel lehet építeni egy teljes Agile folyamatot, ugyanakkor - mint azt a könyv szerzői is folyamatosan hangsúlyozzák - az Agile egyik legnagyobb előnye abban rejlik, hogy az építőkockák külön-külön is beépíthetők már meglévő folyamatokba is. Azt azonban nem érdemes figyelmen kívül hagyni, hogy mint minden koncepció, leírva sokkal jobban hangzik, mint ahogy aztán ez a gyakorlatban általában megvalósítható.

Az Agile négy alapgondolatra épül, amiket biztosan mindenki ezerszer hallott már, emlékeztetőül azért álljon itt is:

  1. az emberek és a kommunikáció fontosabb, mint a folyamatok és az eszközök
  2. a működő szoftver fontosabb, mint a dokumentáció
  3. a folyamatos együttműködés az ügyféllel fontosabb, minthogy mindenáron ragaszkodjunk az előzetes tervekhez
  4. kövessük a változásokat és alkalmazkodjunk hozzájuk, ne ragaszkodjunk az első elképzelésekhez

A fent felsoroltak nem jelenthetnek újdonságot senkinek, aki dolgozott már Agile csapatban, ugyanakkor a munkafolyamatok közepén előfordul, hogy kényelmesebb nem tudomást venni ezekről az alapelvekről.

Azt hiszem, senki sem tagadhatja le, akármelyik oldalon is áll, hogy dokumentációval, félrekommunikációval, szerződéssel, requierementekkel próbálta védeni az álláspontját, amikor olyan helyzetbe került, ahol kofliktust kellett volna feloldani az Agile-csapat többi tagjával szemben; leginkább talán a fejlesztő vs. tesztelő kapcsolatok lehetnek nehézkesek ebből a szempontból. Az Agile Testing pont ezekre próbál megoldási stratégiákat bemutatni, amiket a könyv több száz oldalon végig is vesz, lefedve a teljes fejlesztési folyamatot.

én is kérek meeting meghívást!

Az első kritikus pont saját tapasztalat és a módszertan szerint is a tesztelők bevonása, illetve sokkal inkább a nem-bevonása a projektek tervezésébe. Sokszor elvesztegetett időnek tűnhet - és nem állítom, hogy tesztelőként nem fordult elő még velem is, hogy az első gondolatom valami ilyen legyen: "ne már, megint egy meeting, van jobb dolgom is" -, de a projekt egészére nézve is nagyon fontos problémák kerülhetnek elő, amik komolyan befolyásolhatják akár az esztimációt is, illetve annak pontosságát. Valószínűleg a tesztelő lesz az, akinek először eszébe jut a tesztkörnyezet, vagy a valódihoz legközelebb álló tesztadatokkal összefüggő nagy kérdéskör, és kiderülhet, hogy például egy zárt rendszerbe integrálandó rész-feature tesztelése sokkal több biztonsági és integrációs problémát vet fel a tesztelésnél, mint ami például a fejlesztők fejében felmerül a kódolás során; ugyanúgy az is kiderülhet, hogy olyan mennyiségű inputra lesz szükség a megrendelő oldaláról ahhoz, hogy a tesztelésnek érdemi eredménye is legyen, aminek az előállítása a megrendelői oldalról is komoly munkaórákat kíván. Ha ezzel megvagyunk, és mindenki átgondolt mindent, jöhet a következő fázis, a tényleges becslés, projekt-tervezés.

Ki, mit, mikor, miért (és mennyiért)?

Ezen a ponton újabb kritikus kérdéshez ér az Agile-csapat, általában itt következik az ügyfél és projekt menedzser közötti első összecsapás, amikor el kell dönteni, mi fér bele a keretbe és mi nem. A tesztelő ilyenkor is kényelmetlen helyzetbe kerülhet, hiszen ha nagyon megvágja a konszenzus a fejlesztési időket, a tesztelésre is kevesebb marad, illetve minél kevesebb a fejlesztésre szánt idő, annál rosszabbul jár a tesztelő, ha csúszás alakul ki bármi miatt is. Természetesen az Agile sem tud minden tényezővel előre számolni, mégis van egy ajánlott stratégia, amivel a kockázatot jelentősen lehet csökkenteni, ez azonban sokkal komolyabb bizalmat kíván mind az ügyféltől, mind pedig a csapaton belül mindenkitől.

Ez a stratégia a TDD, vagyis a Test Driven Development, ami leegyszerűsítve a következőt fedi le: a fejlesztő addig nem ír kódot, míg az adott kódrészletre nem írta meg az automatizált tesztjét. Ahogy kész a teszt, megírja a kódot, ami nyilvánvalóan átmegy a teszten, majd ezt a kettőt egyszerre helyezi be a kódbázisba. Elsőre talán túlzott óvatosságnak és bonyolításnak tűnhet, de olyan komoly előnyei vannak a projekt egészére nézve, amik egyáltalán nem elhanyagolhatók. Vegyük csak a regresszió-tesztelést, vagy egy szimpla refaktorálást fél évvel később; mikor nincs szükség az összes függőség áttekintésére ahhoz, hogy egy szimpla teszt lefuttatásával kiderüljön, a változtatás hatással van-e bármire a kód egyéb területein, arról nem is beszélve, hogy a fejlesztő rákényszerül, hogy logikusan végiggondolja, mit és hogyan szeretne programozni. A kezdeti megnövekedett kódolásra költött idő a későbbiekben több szinten is megtérül; a tesztelő mentesül a regressziós tesztek manuális végrehajtásától, vagy éppen magától a regresszió-teszírástól, miközben a "felszabadult" idejét olyasmivel töltheti, ami a projekt egészének érdekeit szolgálja, de erről később még lesz szó. Emellett a TDD másik nagy előnye, hogy a csapatban mindenki egyformán "teszt-infected" lesz, tehát nem csak a tesztelő lelkiismeretén és munkáján múlik a kész termék minősége, hanem mindenki egyformán hozzáteszi a teszteléshez is a maga részét. A TDD önmagában nem biztosíthatja a kódminőséget, mégis fontos belátni, hogy a fejlesztő lelkiismeretén kívül ez az egyetlen eszköz a biztosítására. A tesztelőnek a kódminőségre semmiféle ráhatása nincs, hiszen optimális esetben már csak az adott kész feature-rel találkozik, a unit teszteket nem ő írja, és mégha bele is fut olyan bugba, ahol egyértelmű, hogy egy rosszul strukturált kódrészlet miatt jelentkezik hiba, a leggyakoribb megoldás egy gyors patch, ami megint nem a kódminőség javulására szolgál, pusztán az adott pillanatban felold egy konfliktust. Minél több ilyen patch kerül a kódba, annál nehezebb lesz minden hibát megtalálni, ráadásként egy-egy ilyen patch általában csak az “elsőre jó ötletnek tűnt”-kategóriába fér be, a kód pedig minden alkalommal egyre jobban hasonlít majd egy kártyavárra, és lehet, hogy csak az 50. user belépésével derül ki, hogy a fél évvel azelőtti sebtapasz hirtelen már nem a legjobb megoldás.

és hogy miért is fontos, hogy az 50. user is elégedett legyen? Mert ha nem az, és talál más alternatívát a szoftverpiacon, nagyon nehéz lesz meggyőzni arról, hogy fusson neki a miénknek mégegyszer...