Agile Testing 2.

"Ennek most semmi érteleme"

Ha mindenki egyetért abban, hogy a TDD a követendő a fejlesztés során, valószínűleg az első pillanatban mindenki azt fogja gondolni, hogy innentől a tesztelő már csak a tesztek írásával, majd a kész feature-ök tesztelésével fog foglalkozni (esetleg besegít egy-egy automata teszt megírásába), de az Agile itt is tud olyan feladatokat sorolni, amikkel a tesztelő hasznos tagja maradhat a projektnek az inaktívnak tűnő időszak alatt is.

A sprintek tervezésekor segíthet a követelmények pontosításában, foglalkozhat az ügyfél-csapat kommunikációval, és elkezdheti az első tesztesetek megírását is, szem előtt tartva, hogy felesleges munkát azért ne végezzen. A fejlesztők munkáját is segítheti azzal, hogy megfogalmazza a happy path-t, ami körülbelül annyit jelent, hogy az adott user storyt a user optimális esetben hogyan és mire fogja használni. A happy path megfogalmazásának nem célja, hogy olyan esetekre kitérjen, ahol például hibát kell kezelni, ugyanakkor egyértelműsíti, a “minimálisan elvárt funkcionalitást” (ami ebben az esetben azt is jelenti, hogy a user oldaláról is csak az elvárt magatartást vizsgáljuk), majd ha ez megvan, és működik, további kiegészítéseket is lehet hozzáadni. Valójában a happy path követése az egész projektre is vonatkozhat, hiszen a feature-ök prioritizálása is egyfajt happy path-meghatározás, mégha nagyobb léptékben is történik.

Mivel az Agile alapvetően a lehető legrugalmasabb változáskövetésre fókuszál, fontos, hogy mindenki - beleértve a tesztelőt is - át- és belássa az adott munka hozzáadott értékét; csak azért ne írjunk meg előre minden tesztesetet, mert "nincs jobb dolgunk", de az adott sprintbe tartozó feature-ök elkészülte után érdemes a felületes "happy path"-on túllépve komplikáltabb eseteket is végiggondolni, illetve akár felvázolni egy kezdetleges teszttervet is, ami ugyan egészbiztosan változni fog a termék végső átadásáig, de vonalvezetőként tökéletesen használható, akár a tesztelést, akár a későbbi dokumentálást nézzük.

“Tegyünk még oda plusz egy ikont, tudom, hogy nem fér el, de akkor tervezzük át a többit is!”

Hasonló kategóriába esnek a fejlesztés/tesztelés során “ki- és feltalált” hozzáadandó apróságok. Valószínűleg mindenkivel előfordult már, miközben egy adott szoftvert használt, hogy egy ponton eszébe jutott, milyen jó lenne, ha itt most egy kattintással meg lehetne csinálni azt, amihez mindig 3 kattintás és két oldal aljára görgetés kell, de valamiért az adott termék fejlesztésekor senki sem gondolt rá, hogy akkora hozzáadott értéke lenne a gombnak a user szempontjából, ami miatt megérné ráfordítani a fejlesztési időt, vagy szimplán csak fel sem merült. A manuális regressziók alól felszabaduló tesztelő erre is jó lehet, érdemes tehát kihasználni a tudását, tapasztalatát ilyen szempontból is. Természetesen mindenki máshogy működik, máshogy gondolkodik és más szempontok alapján érez szükségesnek és fölöslegesnek adott működési struktúrát, de a szakkönyvek, cikkek és kifejezetten erre specializálódott szakemberek mellett a józan paraszti ész sem elhanyagolható az ehhez hasonló problémák felmerülésekor. Az igazi veszélyt azonban pont ugyanez rejti, ha találunk egy apróságot, amivel szerintünk a felhasználói élményt növelni lehetne, önmagában még nem garancia arra, hogy meg is térül a lefejlesztése. Ráadásul az iterációnk elvileg előre meg lett tervezve, a happy path teljesüléséig pedig nem is foglalkozhatnánk mással. Arról nem beszélve, hogy meg kell még vizsgálni az üzleti oldalt is, így a ROI (Return On Investment) lesz a legfontosabb szempont. A befektetés megtérülésének megítélése persze ugyanúgy nehezen körülírható, de általános “szabályok” azért kimondhatóak róla. Elsőként például az, hogy kezeljük őket amolyan belső-scope change-ként. Nem becsültük előre, hisz nem tudtunk még róla, ugyanakkor szerintünk van értelme, tehát akár még valós scope change is válhat belőle.

Mi fér bele?

Optimális esetben a következő sarokpont az aktuális iteráció scope-jának meghatározása és a hagyományos értelemben vett tesztelés elkezdése, itt viszont már az Agile Testing is ködösen fogalmaz. A megrendelő igényeihez igazodva érdemes úgy meghatározni a scope-ot, hogy az ne akadályozza a projekt előrehaladását. Gyakorlati oldalról példát hozva, volt olyan projekt, ahol a scope az adott teljes feature-t jelentette (login + logout + jelszóemlékeztető + jogosultságok), máskor egy sprintbe csak a login került be, később pedig a user kezeléssel párhuzamosan készült el a jogosultságok kezelése is, holott mindkét esetben szerepelt a követelmények között a jogosultságok kezelése is, a böngészőspecifikus tesztelésről pedig még nem is esett szó. Az általánosan bevált módszer nálunk a sprint planning meetingek beiktatása a sprint megkezdése előtt, ezt lehet az ügyféllel közösen, amennyiben igénye van rá, illetve akár csak a fejlesztői csapat egymás közötti konszenzusa is, a lényeg itt mindig az, hogy legyen egy mindenki számára egyértelmű (és lehetőleg folyamatosan hozzáférhető helyen dokumentált) megegyezés arról, hogy minek kell teljesülnie ahhoz, hogy “tesztelhető” legyen az elkészült kód.

Ezzel pedig elérkeztünk a legkritikusabb pillanathoz egy tesztelő életében, ami maga a tesztelés, a bugkezelés és a fejlesztő vs. tesztelő összecsapások professzionális menedzsmentje.

Bug! Feature! Bug! Feature! BUG!!! FEATURE!!!!!

Bizonyára mindenki találkozott már fejlesztési folyamatok közepén a "bug vagy feature?"-alapproblémával, ami sokszor a legnagyobb összecsapások kirobbantója fejlesztők és tesztelők között, igazságot tenni pedig sokszor valóban nehéz. Az Agile Testing azonban erre egy frappáns választ ad, miszerint nem biztos, hogy bármit is számít, ha egyébként mindenképpen meg kell csinálni.

Természetesen ott, ahol mérőszámok, bónuszok függhetnek attól, hogy az adott fejlesztő munkáját a bugok számával próbálják megítélni, kicsit problémásabb lehet ez a kérdéskör - és bár az Agile Testing is több oldalt szentel a mérőszámok használatának -, de megint a rugalmasságra, változáskövetésre lehet visszautalni; amennyiben láthatóan nem lesz használható az adott kód a tervezett célra, a változtatás elkerülhetetlen.

Egy ideális világban

Ha feltélezzük, hogy a csapat minden tagja az Agile módszertan követésére törekszik, akkor következő felállással szembesül a tesztelő egy-egy sprintben:

- kap egy adag friss kódot, ami szükségszerűen egy adott feature előzőleg meghatározott done definíciójának megfelel, ráadásként teszteseteket is, amiket a buildfolyamatba a fejlesztő a kód becsekkolásával egyidejűleg beillesztett

- a tesztelő ilyenkor nekiesik, és minden lehetséges módon megpróbál túljárni a fejlesztő és a technika eszén, az előzetesen már jó alaposan végiggondolt teszteseteket végrehajtva, igény (ami jöhet a csapaton belülről, illetve az ügyfél felől is) esetén pontosan dokumentálva

- optimális esetben minimális számú ticketet nyitva a fejlesztőnek a javítások, illetve az adott sprint végéig tesztel, demo meetingen az ügyfél felé a csapat prezentálja az eredményt, majd részt vesz a következő sprint tervezésében

Mire kell akkor a (manuális) tesztelő?

Jogosan merülhet fel a kérdés, hogy mégis mi az, amit a tesztelő tesztel, ha a fejlesztő előre megírt tesztesetekkel lefedi a kódját? Azon felül persze, hogy különböző böngészők különbözőképpen viselkednek adott kód lefuttatásakor van azért még jópár olyan terület, ami ilyenkor előtérbe kerül. Az Agile Testing a TDD legnagyobb előnyeként pontosan ezt emeli ki: amint automatizált tesztek fedik le a kódbázist, nincs szükség arra, hogy a tesztelő próbálja meg kicsikarni a technikai jellegű hibákat, vagy írja meg a regressziós teszteket. Az így felszabaduló időt és energiát pedig jóval fontosabb tesztelésre lehet fordítani, például usability vagy exploratory-tesztelésre, amikre jellemzően kevés figyelem irányul, mégis talán az egyik legfontosabb területei a tesztelésnek. A fejlesztőktől túlzás lenne elvárni, hogy miközben a saját kódjukat írják folyamatosan tartsák szem előtt a "big picture"-t és a feature-öket is, mindenközben figyeljenek rá, hogy a kódjuk rendezett és a lehető legáttekinthetőbb legyen, a felhasználó számára egyértelmű, ugyanakkor stabil és minden egyéb szempontnak megfeleljen. A tesztelő tehát azon felül, hogy megpróbálja a felhasználó fejével és lehetőségeivel élve "romba dönteni" a fejlesztő munkáját, a felhasználó szemszögéből is vizsgálja az elkészült részeket, a termék egészére nézve, a megrendelő szempontjait és kívánságait is szem előtt tartva. Nem nehéz belátni, hogy mindez összetett feladat; a tesztelő egyszerre van jelen mindkét oldalon, technikai oldalról minőséget biztosít, megrendelői oldalról a felhasználói élményre fókuszál. Az egyik kedvenc mondatom az Agile Testing könyvből szabadfordításban nagyjából így hangzik: a felhasználók szokása, hogy egészen furcsa és csodálatos módokon használják a terméket. Azaz bőven nem elég, ha végigkattintjuk az adott feature-t, és megelégszünk azzal, hogy működik, aminek működnie kell, és elromlik, amitől azt vártuk, hogy elromoljon. Ki kell cselezni a fejlesztőket és ki kell cselezni saját magunkat is, a legnehezebb része pedig pontosan az, hogy minél régebb óta tesztelünk, annál nehezebb lesz saját magunkat és a megszokást kicselezni.