Egy kellemetlen igazság az agilis szoftvertesztelésről

Az elmúlt nyolc évben Jeff Patton az agilis szoftverfejlesztéssel foglalkozott. Ennek egyik jellegzetessége, hogy a fejlesztésbe folyamatosan bevonják a tesztelőket. A tesztelők munkája nehéz és mozgalmas. És az előző évben Jeff végre kezdte megérteni, hogy a tesztelés jelentősen eltér az agilis szoftverfejlesztés során.

Azon vállalatoknál, melyek bevezették az agilis szoftverfejlesztést, gyakran szembesültem a tesztelők és a csapat többi tagja közötti nézeteltérésekkel. A tesztelők termékspecifikációkat fognak kérni a tesztelés megkezdéséhez, hogy kiderüljön, az adott fejlesztés megfelel-e a vele szemben támasztott követelményeknek, ami mellesleg egy teljesen logikus kérés. A csapat gyakran hivatkozik felhasználói visszajelzésekre és átvételi kritériumokra, melyekben egy jó tesztelő semmi perc alatt meglátja a hibákat. „Ezt a szoftvert így nem adhatjátok ki”, mondhatja a tesztelő. „Ezekben a mezőkben hiányoznak a jóváhagyási paraméterek. És mi fog történni, ha nagyobb mennyiségű adatot helyezünk ide?”

 „És ez csak az első visszajelzés”, mondhatnám „Később olyannal is fogunk találkozni, melyek jóváhagyási feltételeket és határokat fog beállítani azokra a mezőkre. És hogy őszinte legyek, ezek a mezők még sok változáson eshetnek át, miután bemutattuk őket a megrendelőnek – ezért is halogatjuk jelenleg e funkciók hozzáadását.”

„Tehát akkor jelenleg nincs is értelme tesztelni”, mondaná a tesztelő. „Ha a kód változik, akkor amúgy is újra kell tesztelnem az egészet. Akkor hívjatok, ha már nincsenek változtatások.”
Meg tudom érteni a kételyeiket, de azt is tudom, hogy le kell tesztelni azt, ami eddig elkészült – még akkor is, ha nem teljes és változni fog. És ekkor döbbentem rá, hogy miről is szól a tesztelés agilis szoftverfejlesztés esetén. Hadd szemléltessem egy történettel:

Képzeld el, hogy egy autógyárban dolgozol. Te vagy a tesztpilóta, és a futószalagról leguruló autókat kell tesztelned. Először végigmész egy akadálypályán, majd egy körpályán száguldasz nagy sebességgel, végül pedig az autót vásárlásra alkalmasnak nyilvánítod. Mindehhez pedig fekete bőrkesztyűt és napszemüveget viselsz. (Persze biztosan nem így megy ez az egész, de a poén kedvéért képzeljük el.)

Az utóbbi egy hétben igazi kínszenvedés volt a munkád. Amikor az aznapi tizenötödik kocsidat indítod, az döcögősen fut, majd pedig 100 méterre a gyár hátsó kijáratától lefullad. Már előre tudod, hogy az üzemanyagpumpa lesz a hibás, mivel az előző öt autónál is az okozta a problémát. Az autót hibásnak jelölöd, majd visszaküldöd, hogy diagnosztizálják a felmerült problémát és javítsák ki. Lehet, holnap ismét tesztelni fogod ezt az autót.

Most néhányotok biztos azt gondolja, „Miért nem tesztelték le az üzemanyagpumpákat mielőtt beszerelték az autóba?” És milyen igazatok van, ez egy remek ötlet lenne. A való világban valószínűleg minden egyes alkatrészt külön-külön letesztelnek, mielőtt összeszerelésre kerülnek. Majd a végén ismét tesztelik a már összeszerelt járművet. Az alkatrészek egyéni tesztelése nagyban hozzájárul a minőség javításához, egészen az autó elkészültéig.

Hasonló okokból van tesztelés agilis szoftverfejlesztésben is. Egy agilis fejlesztőcsapatban lévő tesztelő tesztelhet olyan alkalmazást, amely félkész, hiányosak az érvényesítések, vagy éppen hiányzik néhány mező. Még csak félkész – a szoftver egészének egy része – de már ebben a félkész állapotban lévő tesztelés is segít csökkenteni a minőségromlás veszélyét. Ez nem arról szól, hogy bizonyítsuk a szoftver elkészültét, hogy most már teljes, szállításra kész. Ehhez az kéne, hogy vezessük az „egész autót”, amit csak akkor fogunk megtenni, ha az már teljesen elkészült.

Azzal, hogy a szoftvernek egy részét készítjük el, és bemutatjuk, hogy működik is, el tudjuk végezni a tesztelés egyik legnehezebb típusát: a jóváhagyást.

Már nem is emlékszem, mikor hallottam először az ellenőrzés és jóváhagyás szavakat. Annyira nonszensz volt számomra; a két szó úgy hangzott, mintha egymás szinonimái lennének. Most már értem a különbséget, ami igen fontos. Ellenőrzés alatt a specifikációknak való megfelelést vizsgáljuk, más szóval, a szoftver azt teszi, amit tennie kell, hiba nélkül. A jóváhagyás annyit tesz, hogy a szoftver használatra kész, ellátja a kijelölt feladatát. Végtére is, a szoftver értéktelen, ha nem teljesíti a megadott feladatát, amit nehéz biztosítani egészen addig, amíg valójában el nem kezdik használni a kiszabott feladatára. És a jóváhagyásra leginkább alkalmas személye az, aki számára a program készül. Még ha a célfelhasználó nem is tudja pontosan meghatározni, hogy megfelel-e számára a szoftver, azt már gyakran meg tudják mondani, ha nem felel meg, ahogy azt is, hogy mit lenne érdemes változtatni rajta, hogy nagyobb eséllyel feleljen meg a követelményeknek.

Kis részekből felépíteni egy szoftvert és azokat a részeket idejekorán tesztelni, lehetőséget ad nekünk arra, hogy korábban fogjunk hozzá a jóváhagyási folyamathoz. Ezzel az eljárással viszont elkerülhetetlenek a szoftverben bekövetkező változások. Ezek a változások vagy kis léptékben érkeznek, vagy folyamatosan egy agilis szoftverfejlesztési projekt során, amiről az agilis fejlesztők úgy gondolják, jobb, mintha egyszerre kapnák meg egy nagy adagban a projekt végén, amikor már idő szűkében vannak és nagy a feszültség.

Egy agilis környezetben lévő tesztelő feladata a termék minőségének javítása, mielőtt az elkészül. Továbbá azt is, hogy a fejlesztői csapat szerves és fontos tagjává válik. Segítenek biztosítani, hogy a szoftver – minden egyes apró része, mely elkészült – már ellenőrizve van, mielőtt a felhasználó jóváhagyná. A tesztelőket már korán bevonják, hogy segítsenek meghatározni az elfogadási kritériumokat, még mielőtt elkezdődne a szoftver megírása. A tapasztalatuk felbecsülhetetlen olyan hibák felkutatásában, melyek nagy valószínűséggel jóváhagyási problémákat okoznának a megrendelőnél.

A nap végére egy agilis tesztelő valószínűleg sokadjára fogja ellenőrizni ugyanazt a funkciót, hogy a hozzáadott vagy megváltoztatott részekkel is biztosan működjön. Egy tipikus agilis termékre sokkal több tesztelési időt kell fordítani, mint egy nem-agilis fejlesztés során. A kellemetlen igazság, mellyel az agilis tesztelők szembesülnek, hogy ez az egész folyamat kemény munkával és ugyanazon funkció sokszori újratesztelésével jár. Az én szememben ez a tesztelők szerepét sokkal fontosabbá és kritikusabbá teszi, mint valaha. 

Szerző: Jeff Patton