Jó agilis tesztelőnek lenni egészen összetett dolog. Az agilis szoftverfejlesztésnél idális esetben alapvetően két csapatot határozhatunk meg, a “customer team”-et valamint a “developer team”-et, melyek mindegyikébe beletartozik a tesztelő. Ügyfél oldalról segíti a projekttel kapcsolatos igényeket tesztesetekre bontani, a fejlesztői oldalról pedig a tesztek sikeres futását, újrafelhasználhatóságát, kis lépésekben történő folyamatos fejlődését kell biztosítania. Ehhez rengeteg kommunikációra és megfelelő technikai képzettségre van szükség.
Mindez még csak a kezdet, ha az adott tesztelő specialista még nem találkozott az agilis szoftverfejlesztés világával. Nem elég, hogy merőben újfajta szemléletek és helyzetek végelláthatatlan seregével kell megismerkednie, azt jól is kell alkalmaznia, kezelnie. Egyik nagy kihívás nem csak a tesztelőnek, de minden egyes új az agilis szemlélettel ismerkedőnek, hogy felvegye a csapattal a tempót. Ez nem azért van így mert az agilis csapattagok az életüket félredobva feláldozzák magukat a minőségi szoftverfejlesztés oltárán, hanem mert ők már sikeresen alkalmazzák az agilis elveket. Nem dolgoznak többet csak sokkal hatékonyabban teszik mindazt az olyan projektekben, amelyeknél alkalmazható az agilis módszertan.
Az a tesztelő aki ahhoz szokott, hogy egy tesztelő csapat tagjaként részletes útmutatás segítségével (például hónapok alatt elkészült specifikáció alapján) írja a teszteket, az meglepődhet, hogyan lehet elérni, hogy minden teszt sikeresen elkészüljön két-három hetes ciklusban, folyamatosan változó funkcionalitás mellett. A tesztelés egyik céljaként hozzá kell segíteni a csapatot, hogy minden egyes kiadásnál értéket adjon a szoftverhez. Egyik kulcsa ennek, hogy a jelentkező hibákról azonnali visszajelzést adjon annak a csapattagnak, aki javítani tudja azt. Így előfordulhat az, hogy a tervezettnél kevesebb új funkció kerül bele a soron következő kiadásba, mert a hibajavítás időt vesz el, de cserébe magasabb minőségű funkciók kerülnek kiadásra. Ezáltal elkerülve a következő iteráció elején a sok hibajavítást, ami csak feszültséghez vezet.
Ezeknél a visszajelzéseknél fel kell készülnie a tesztelőnek, hogy gyakran heves ellenállásba fog ütközni, főleg olyan fejlesztőknél, akik még nem tudták, vagy nem is nagyon akarják elsajátítani az agilis fejlesztéssel járó szemléleteket, valamint nem értik a tesztelés célját. Ilyenkor a fejlesztők nem igazán örülnek, hogy találtak hibát a munkájában, hiszen jobb azt hinni, hogy tökéletesek vagyunk, arról nem is beszélve, hogy sok fejlesztő úgy gondolja, hogy a tesztelő inkább alsóbbrendű szolga mint munkatárs (egy-két pofont ilyenkor ki kell osztani). :) Ebből a szempontból az egyik oldalról tudatosság és bátorság kell, a másik oldalról pedig további fejlődés szükséges ahhoz, hogy a csapat munkáját elősegítsék ezáltal a szoftver minőségét biztosítsák. Amennyiben a két fél között emiatt tartós feszültség lép fel, akkor ahhoz is bátorság kell, hogy a tesztelő jelezze a menedzser felé a munka akadályozásának tényét, ami azért is nehéz kérdés, mert a nem a tesztelő hatásköre, hogy a csapat minden tagja megfelelően végezze a munkáját.
A tesztelőnek ( többek között a fejlesztőknek is amikor pl. a TDD-t alkalmazzák ) fel kell készülniük arra, hogy többször is el fognak bukni. Ilyenkor erő és kitartás kell ahhoz, hogy tanuljunk a hibáinkból, ne pedig feladjuk és azt mondjuk, hogy ez nem is működik, csak mert nem sikerült elsőre. Például megtanulni görkorcsolyázni hasonló dolog. Nem lehet úgy elkezdeni, hogy elsőre ne szántsd fel a betont, aki ennek ellenére is folytatja, az megtanul görizni, aki nem az pedig nem állíthatja, hogy nem jó dolog, csak azt hogy neki sikerült elég hamar feladnia. Aki fél az eséstől, annak hamar elmegy a kedve a teszteléstől. :)
Fel kell készülni a folyamatos automata tesztek kialakítására és fejlesztésére is. A cél: a lehető legkisebb költséggel karbantartható környezetet kialakítása, amely alkalmazkodik a gyakran változó igényekhez, és amely biztosítja a gyors visszajelzés lehetőségét. Ez sok kutatást, utánajárást, fejtörést vagy akár fejlesztést igényel. Például ha van egy egyelőre nehezen tesztelhető része a szoftvernek, amire nem igazán illeszkedik egyetlen meglévő megoldás sem, akkor előfordulhat, hogy írni kell egy saját szimulátort, amivel tesztelhető a működés a teljesítmény stb. Ilyenkor együtt kell tudni működni a fejlesztővel. A tesztelőnek folyamatosan fejlesztenie kell a tesztelő rendszert, hogy a tesztelés minden területén a lehető legjobb és legegyszerűbb eszközt használják. Ami beválik azt alkalmazni kell, ami nem azt nem kell erőltetni, el kell dobni hamar.
A két hetes ciklusokban folyamatosan változik a funkcionalitás, ezáltal törekednie kell a tesztelőnek, hogy tudjon alkalmazkodni ezekhez a változásokhoz, ezért újrafelhasználható teszteket kell alkalmazni ott ahol csak lehet. Képesnek kell lennie arra, hogy az adott ciklusban történt változásokat összeszedje, ha kell, akkor megbeszélje a fejlesztővel, hogy mi is változott, majd a meglévő teszteket átírja a változásoknak megfelelően. Itt is fontos, hogy a tesztelő ne hagyja magát elhessegetni, mert pl. a fejlesztő úgy gondolja éppen nem ér rá.
A fejlesztők azt szeretnék, ha a tesztelő jártas lenne a technikai dolgokban, amik alkalmazva vannak az adott projektben minden apró részletére kiterjedően. Sokan közülük nem tudnak vagy nem is akarnak tanítani. Így idegbetegek lesznek, ha olyan dolgot kell elmagyarázni a tesztelőnek, amely ahhoz szükséges, hogy megértse azt a másik témát amiről éppen beszélni akarnak. Annak ellenére, hogy többnyire (tisztelet a kivételnek) elég szűk látókörrel rendelkeznek más téren, de hát ha egyszer hazai pályán vannak, akkor büszkék a tudásukra (na már megint kell egy kicsit pofozkodni). :) Ez a technikai tudásbeli különbség csökkenthető folyamatos önfejlesztéssel, valamint egy kis hozzáállás javítással a fejlesztői oldalról.
Ezután jön a meglepetés, amikor az ügyfél oldali csapatban van teendő. Az ügyfél vagy annak képviselője szeretné, ha értenék azt amit mond, és a fejlesztőkkel sok órányi megbeszélés is szükséges lehet ahhoz, hogy megértsék egymást és akkor is mást fognak lefejleszteni, mint amit az ügyfél akart. Ilyenkor a tesztelőnek kell lennie a két oldal közötti kapocsnak, és közös nyelvként a teszteseteket kell használni. Itt fontos szerepe van a tesztelőnek, hisz olyan példákat kell találnia, ami az egyik oldalról lefedi az igényeket a másik oldalról meg technikailag kivitelezhető esetet jelent.
Vannak olyan ügyfelek, akik nem tudják pontosan megfogalmazni mit is akarnak igazán. A fejlesztés közbeni folyamatos visszajelzéssel lehet ezen segíteni, de a másik megoldás lehet, hogy a tesztelő segít megfogalmazni az igényt. Ilyenkor látni kell a "big picture"-t, teljesen ellentétben a fejlesztői oldalon lévő kommunikációval, ahol kis részekre vonatkozóan is kell tudni gondolkodni. Sokszor megérzésekre vagy fantáziára van szükség ezekben az esetekben. Ezáltal a tesztelőnek kétféle látásmóddal is kell rendelkeznie, ami nem igazán egyszerű.
A fentiekből látszik, hogy nem feltétlenül a tesztelőnek van a legkönnyebb dolga a csapatban. Bár a nehézségek közül egyszerre ritkán van jelen az összes, de tudni kell kezelni mindegyiket. A lényeg, hogy a tesztelő is a csapat teljes értékű fontos része, aki segíthet, hogy egy igazán jó szoftver készüljön. Az agilis tesztelő olyan munkát végezhet, ami minden területen változatosságot és fejlődést igényel.
