Agilis szoftvertesztelési stratégiák menedzserek részére

Egy agilis projekt tesztelésének irányítása egyedi kihívásnak bizonyulhat: egy- vagy kéthetes iterációk, egymást átfedő tesztek, megérteni, mit jelent a csapat számára a „kész” jelző, és megtalálni az egyensúlyt funkcionális tesztelés és minden más kritéria (teljesítmény, biztonság, stb.) között. Végigveszünk néhány gyakori hibát, melyekkel agilis tesztelés során találkozhatunk, és adunk néhány tippet a megoldásukra.

Ebben a cikkben túlnyomórészt a Scrum keretrendszerre mutatok példákat. Nem azért, mert a Scrum jobbnak bizonyul, hanem mert sok tapasztalatom van vele. Ezzel könnyen tudok dolgozni. A Scrum egy inkrementális folyamat, mely során egy keresztfunkciós csapat egy vagy több termék teendőlistájából származó esetek sorozatán dolgozik.

Az egyes iterációkat „sprint”-eknek nevezzük. A saját sztorid tartalmazza a te elvárásaidat, a termék teendőlistája pedig a termékre vonatkozó sztorikat. A Scrum híres a napi megbeszéléseiről, melyeket „scrum”-nak hívnak. A Scrum-ról többet megtudhatsz a cikk alján lévő linkekből, melyek segíthetnek jobban megérteni az itt leírtakat.

Megbirkózni az időhiánnyal

Akár most ismerkedsz a teszteléssel, vagy csak az agilis projekten való tesztelés új számodra, az első kihívás, amivel találkozni fogsz, az a tesztelésre szánt rövid idő. Az agilis projektek többsége, melyeken dolgoztam, úgy voltak kialakítva, hogy kéthetes iterációk során készüljenek el. De dolgoztam már egyhetes és háromhetes ismétlési ciklusokkal is. Ismerek olyan embereket, akik hosszabb ismétlési ciklusokkal is dolgoznak.

Az agilis csapatok pontosan emiatt az időhiány miatt támaszkodnak nagyban az automatizálásra, amikor tesztelésre kerül a sor. Sok más oka is lehet a tesztek automatizálásának, de a kód változásairól mihamarabbi visszajelzések megkapása kiemelten fontos. Vegyük példaként az Expected Behavior által összeállított tesztelési csomagot (http://www.expectedbehavior.com/blog/2010/01/13/our-testing-stack).

Ők egy Ruby on Rails webalkalmazásfejlesztő cég, és többek között az alábbi eszközöket használják teszteléshez:

• Cucumber: egy viselkedésalapú fejlesztői teszteszköz
• HtmlUnit: egy teszteszköz a böngésző szimulálására
• Celerity: egy keret a HtmlUnit-hoz
• Culerity: integrálja a Cucumber-t és a Celerity-t
• Bootstrapper: segít a “bootstrap” folyamatban és az adatbázisok feltöltésében
• Factory Girl: keretrendszert és DSL-t biztosít a tesztcsomagok kezdeti beállításainak meghatározására és használatára

Egy kódsor megírása előtt mindig gondolnak a tesztelésre. Az eszközök ennek csak egy részét képzik. A folyamat is támogatja ezeket az eszközöket. Ha egy agilis csapatban dolgozol, akkor a csapatodnak kell egy tesztelési módszertan és a megfelelő eszközök annak támogatására. Milyen teszteket fogsz készíteni? Egység, integrációs, elfogadás, teljesímény alapút, stb. ? Milyen típusúak lesznek? Tesztelésalapú, viselkedésalapú, elkészültségre összpontosító, stb.? Milyen módszereket és eszközöket fogsz használni ezek elkészítéséhez?

Bár gondolhatsz ezekre csak mint „programozási” elfoglaltság, ha egy agilis csapat tesztmenedzsere vagy, akkor tisztában kell lenned a dolgokkal. A stratégiád nagy részét a tesztek azon részének lefedésére fogod összpontosítani, amivel a fejlesztőid még nem foglalkoztak. Ez azt is jelenti, hogy meg kell értened, mit és hogyan csinálnak. Továbbá sok esetben alapozhattok arra, amivel már korábban foglalkoztatok. Nemcsak a teszteszközeiknek (adatbázis feltöltése mintaadatokkal, szolgáltatások szimulálása, stb.) veheted hasznát, de még ki is bővítheted a tesztjeiket a sajátjaiddal.

Az automatizálás mellett a sikerhez vezető út következő állomása az, hogy megértsd, miként lehet keretrendszert készíteni gyors teszteléshez. Számomra ez gyakorta egy felderítésen alapuló tesztelési megközelítést jelent. De ismerek néhány tesztmenedzsert, akik a tradicionálisabb eljárásokkal is sikereket értek el. A trükk az, hogy a tesztelés során minimalizálni kell a dokumentációt, a felállási időt és az egymás feje fölött való elbeszélést, mialatt maximalizáljuk a tesztenkénti lefedettséget, és hogy mennyit hasznát vesszük a hallgatólagos tudásnak.

Kitalálni, hogy hova passzol a tesztelésünk

Ha kapsz egy keresztfunkciós csapatot, akik kéthetes ciklusokban dolgoznak, hamar káosz lesz. Nem fogod tudni kellően letesztelni azt a szoftvert, amit a sprint utolsó napját megelőzően írtak. Ez egy érdekes problémát vet fel az agilis tesztcsapatok számára. Ki kell találniuk, hogy hová passzol a tesztelésük. Lentebb megosztok néhány tippet, melyek segítettek nekem az agilis csapatok tesztelésének irányításában. Viszont nem kell szorosan követni a leírtakat – nyugodtan kombinálj, és használd azokat a megközelítéseket, melyek legjobban kielégítik az igényeidet.

Beágyazott tesztelők

A legtöbb agilis csapatban azt szeretnék, ha a futamban dolgozó teszterek együtt haladnának a fejlesztőkkel. Ezt nevezem beágyazott tesztelésnek. A tesztelők a futam részei, a tesztek pedig a fejlesztéssel egyidőben folynak. A futamban lévő sztori addig nincs „kész”, amíg nincs tesztelve és nincs kijavítva az összes hiba. Ebben az esetben a tesztelők az első héten annyi tesztet írnak, amennyit csak tudnak, és amint elérhető a szoftver, megkezdik a tesztelését. Itt nagy nyomás alatt vannak.

Ennek a megközelítésnek megvan az az előnye, hogy minőségi termék lesz a végeredmény. A programozók folyamatos visszajelzéseket kapnak a szoftverről, és ha ki kell javítani egy hibát, akkor a kódrészlet még ott lebeg előttük. Továbbá egy közös célt állít fel – a kész azt jelenti, hogy letesztelt és hibamentes. És mindenki ezen cél elérésén dolgozik. Nincs sok szöszölés a hibákkal, a döntéseket gyorsan hozzák, és gyorsan teljesítik is azokat.

Másrészt viszont hihetetlen nyomás alakul ki a sprint utolsó napjaiban. A sztorik nagy részének már a futam elején kész kell lennie, különben nem marad idő tesztek futtatására és a hibák javítására. Ezért a csapatnak nagyon ott kell lennie a szeren, amikor az előzetes becslésekre kerül a sor, és okosan kell felépíteniük a futamok struktúráját. Mindenki hibázik, így könnyű elképzelni, hogy ebben a felállásban sok sprint végén lesz fennakadás.

Fejlesztéstől független tesztelés

Az alternatíva, hogy a tesztelő csapat nagy részét a sprinten kívülre helyezzük. Gyakori eset, hogy a tesztelő csapat egy futammal a fejlesztők mögött van. Ezzel ugyan csökken a futam végi stressz, viszont az időben és helyben való elzártság klasszikus problémáit veti fel. Az egyik legnagyobb, amikor megtalálják a hibát, és ki kell találni, hogyan fogják kijavítani.

Amikor a tesztelés el van választva a fejlesztéstől, gyakori, hogy a tesztek megtervezése és végrehajtása egyidejűleg történnek. Ha én lennék a tesztelő, akkor minden bizonnyal az adott sprintre terveznék teszteket, és az előző futamból kikerült szoftvert tesztelném a korábban írt tesztekkel. Ez megköveteli a tesztelőktől a futamok közötti egyensúlyt. Ha nem éreznek rá, akkor vagy lemaradnak a tervezéssel, vagy a tesztek végrehajtásánál lesznek gondok.

Verziókra fókuszáló tesztelés

Újabb alternatíva az előző két megközelítésre, ha visszanyúlunk egy sokkal tradicionálisabb tesztelési eljáráshoz, és csak a futószalagról lekerülő végleges verziókat teszteljük. Ennél az eljárásnál teljesen figyelmen kívül hagyják a sprinteket, kivéve talán a tesztek tervezésénél. És minden egyes tesztet a végleges verzión futtatnak. Ez a megközelítés még használható is a köztes verziók esetén – ahol például a szoftverből két-három hetente érkezik új verzió – ám hiba lenne a főbb verziók esetén is használni. Ugyanazok a problémái, mint a vízesésalapú tesztelésnek.

Mindemellett a végleges verzió esetén érthető, hogy egy adott minőségi elváráshoz mérten tesztelnek. Példaképpen a teljesítmény, a használhatóság és a biztonság talán csak a végleges változatban tesztelhető igazán. Bár ez nem mindig igaz, de mindenképp vannak olyan tesztesetek, melyek a végleges verziót részesítik előnyben. Ezért kell mindent elkövetni annak érdekében, hogy a végleges verzió esetén minimális szükség legyen a tesztelésre. A legtöbbet kell kihozni belőle, amit csak így lehet. Általános szabály, hogy minél közelebb van a tesztelés a kód megírásához, annál jobb lesz a szoftver.

Megérteni, hogy mit, és mikor kell tesztelni

Én úgy tapasztaltam, hogy a legtöbb iteráció sztorik egyvelegét tartalmazza, melyek potenciálisan gyártásra kerülnek, eltérő időben. Példaként vegyünk egy átlagos verziómenetrendet, ahol kéthetente kerül ki új verzió. A hétközben kiadott változatok nagyrészt csak kisebb verziók, és minden harmadik hónapban jön egy főbb verzió. Ha pedig közben kell kiadni valamit, azt gyorsjavításnak nevezzük.
Ez a következőképpen néz ki:

Ebben a felállásban úgy tapasztaltam, hogy nem ritka az olyan sprint, ahol egyszerre több verzió fejlesztése folyik. Például hibajavításokat írhatsz a következő alverzióhoz, mellette apróbb funkciók fejlesztése folyik az ezt követő alverzióhoz, és mindezek mellett még néhány komolyabb funkció is fejlesztés alatt van a következő főbb verzióhoz. Ebben az esetben ha a fentebb látható 1. sprintben dolgozol, és a sprintet 20 sztorira osztották, az az alábbi módon nézhet ki:

Ebben a felállásban a csapatodnak egyszerre négy különbő verzión kell dolgoznia. Hogy itt sikeresek legyetek, erős konfigurációkezelési gyakorlat, szoros verziókövetés és az egyes verziók tesztelési lefedettségének pontos ismerete szükséges.

Az erős konfigurációkezelés igen fontos, hiszen egy agilis környezetben gyakran kevés idő van manuális regressziós tesztelésre. Úgy tapasztaltam, hogy a regressziós problémák a rossz konfigurációkezelés okán jönnek elő. Ellenben, ha egy erős KK terved van és mindenki tisztában van az elvégzendő feladatokkal, a regressziós hibák felbukkanása drámaian lecsökken. Egy korábbi csapatommal, miután újragondoltuk a konfigurációkezelési tervünket, lehetőségünk nyílt több verzión dolgozni az egyes sprintek során, és csökkenteni tudtuk a regressziós és a kódkezeléssel kapcsolatos hibákat közel 90%-kal az egyes verzióknál.

Meglepődnék, ha első olvasásra követni tudtad volna az iménti diagrammon és táblázaton bemutatott példát. Azt javasolnám, hogy fuss át rajtuk még néhány alkalommal, hogy követni tudd a kódot a fejlesztés során. Amikor négy különböző verzió kódját kell követned, fontos a jó verziókövetés. A legtöbb verziókövető alkalmazás képes erre, de igen nagy előny, ha a forráskódhoz még ticketeket is tudsz rendelni. Ehhez olyan verziókövető alkalmazást keress, mely együttműködik a konfigurációkezelő alkalmazásoddal.

Végezetül, ez az egész arról szól, hogy kiderítsd az egyes verziók esetén mit és mikor kell tesztelni. Az eltérő futamok és verziók más-más módon terhelik le a tesztelői csapatodat. Ezen terhek elosztása komoly feladat. Keress vagy fejlessz ki olyan alkalmazást, mely segít követni a lefedettséget és a folyamatot az adott időben, több verzión keresztül, és még legalább egy, a felhasználóknak szánt verzió tesztelésének irányításáért is felelős. Így a sprint tesztelési kötelezettségei mellett még követhetnék a lefedettségét egy verziónak, miközben segíthetnek másoknak a tesztek futtatásában.

Gondolj másképp a hibákra

Ahogy a tradicionális fejlesztési módszertanok esetén, a tesztelés során érezhető nyomás a verziókon is meglátszik. A leginkább érezhető, ahogy a csapat reagál, ha hibát találnak. Egy vízesés projektben a fejlesztők gyakran csak várakoznak, hogy hibába fussanak, miközben a tesztelés teljes gőzzel folyik. Tudják, hogy hibákba fognak futni és várnak rájuk. Ezzel szemben agilis projektnél a fejlesztők már minden bizonnyal a következő sztorival foglalkoznának. Ők már elkészültek a kóddal, mely el lett fogadva a sprint során. És már vannak egyéb feladataik, amikre fókuszálhatnak.

Ha a sprint során hibát találnak, a válasz gyakorta egyszerű – kijavítják a hibákat vagy a sprintnek nincs vége. Ám mi történik a sprint után? Mi van akkor, ha a végleges verzió tesztelése során, egy köztes sprint során találnak egy hibát, vagy a tesztelési sprint során egy olyan funkcióban találnak hibát, amely nem ebbe a sprintbe tartozik?

Az eltérő csapatok másként közelítik meg ezt a problémát. Egyes csapatok minden egyes hibához kötnek egy sztorit. A teendőlistára kerülnek, épp úgy, mint bármilyen más sztori, prioritást kapnak, és azzal az eljárással dolgoznak rajtuk, mint a többi sztorin is. Más csapatok break-fix ciklusokban dolgoznak, mint egy tradicionális csapat. Ha a verzióhoz kapcsolódó hibát találnak, a fejlesztők azonnal nekilátnak kijavítani, és a tesztelők újra tesztelik, ha kell. Ebben az esetben rendelkezned kell megfelelő fejlesztői kapacitással erre a feladatra. De honnan lesz rá kapacitásod, ha az összes fejlesztő a sprinten dolgozik?

Gyakori válasz erre az átmeneti sprint. Az átmeneti sprint gyakorta a kód véglegesítése előtti sprint. Ekkor a fejlesztők csak kis munkaigényű feladatokat látnak el, számolva a végleges verzió esetén felbukkanó tesztelési és/vagy fejlesztési feladatokkal. Ez a stratégia jól működik nagyobb verziók esetén, de mi van akkor, ha a csapat több kisebb verzión dolgozik? Ebben az esetben nehezebbé válik időt szakítani egyetlen verzióra.

Mint a csapat vezetője, hamar dűlőre kell jutni, hogy a vállalkozásod miként fogja kezelni a problémákat. El kell dönteni, hogyan lesznek kezelve: a teendőlistára kerülnek, vagy külön-külön lesznek követve. A végleges verzió tesztelése során fellépő problémákra is kell megoldás: átmeneti sprintek lesznek, vagy valami más félretett hibajavítási kapacitás a fejlesztőknek? És mindezek után, hogyan fogod ezt az egész folyamatot nyomon követni, figyelni az időre, és tudni, mikor készültél el?

Végezetül

Az előbbiekben sokmindenről esett szó. Ha számodra új az agilis tesztelés, remélhetőleg világossá vált, hogy a tesztelés itt nem mehet a saját ütemében, mint például a tradicionális metodikák esetén. Agilis projektnél a tesztelők számtalan tesztet futtatnak, a tesztelők a munkafolyamat részei a sztorik teljesítésében, ám a tesztelés nagyja felesleges lehet, ha nincs jó konfigurációkezelésed, és a verziótervezés sincs a helyén.

Ha már egy gyakorlott agilis tesztmenedzser vagy, akkor ezek többségével tisztában vagy, így inkább a sprint és verziók lefedettségének a követését rendszerezd, priorizáld, és egyenlítsd ki a terhelést a túlterhelt csapaton, találj módot az automatizálás áthidalására, melyet a fejlesztők használnak naponta.

További technikákért a tesztek lefedettéségnek kezeléséről, kockázati és végrehajtási tesztekről agilis projekteknél látogass el a következő oldalakra:•    Szofvertesztelés agilis projekten: Hogyan kezdjünk hozzá (http://searchsoftwarequality.techtarget.com/tip/Software-testing-on-an-agile-project-How-to-get-started)
•    Kétperces útmutató a szoftver tesztelési lefedettségének megállapításához (http://searchsoftwarequality.techtarget.com/tip/Two-minute-guide-to-determining-software-testing-coverage)
•    A felderítésalapú tesztelés előnyei agilis környezetben (http://searchsoftwarequality.techtarget.com/tip/The-benefits-of-exploratory-testing-in-agile-environments)
•    A tesztelés szerepe agilis projektekben (http://searchsoftwarequality.techtarget.com/news/1243805/Role-of-testing-in-agile-projects) 

Forrás:https://searchsoftwarequality.techtarget.com/tip/Agile-software-testing-strategies-for-managers
Szerző: Michael Kelly