Létezhet tesztautomatizálás agilis környezetben?

Mára már az agilitás szó annyira divatossá vált, hogy az emberek nem tudnak nélküle élni. A z az érdekes, hogy szinte minden álláshirdetés tar talmazza, hogy agilis szer vezet keres agilis tesztelőt agilis projektre. A z agilitás hiánya a lemaradást jelenti, a „régi vágású iskolát ”.

Vannak agilis fejlesztő csapatok, agilis tesztelők, agilis projektek, agilis
szer vezetek, stb. Sajnos az agilis szó sokak számára egyenlő a követelmények és dokumentációk hiányával, valamint a teljes káosszal.
Ezzel szemben az agilitás nem több, mint egy módszertan, mellyel csökkenthető a menet közben bekövetkező változások és a bizonytalanság költsége.

Az agilis módszertan mellett létezik egy rendkívül jól átlátható, a fejlesztési
feladatok kezelésére is remekül használható módszertan a Kanban1. Kanbannal láthatóvá tehetők mind a folyamatok (munkamenet), mind a folyamatokon végig haladó tényleges feladatok.

Hogyan vonjuk be a tesztelést az agilis környezetbe?

Tesztelés Vezérelt Fejlesztés (Test-Driven Development (TDD))

A hagyományos tesztelés rengeteg dokumentáción alapul. Az agilis tesztelés az agilis szoftver fejlesztés elveit követi, különösen ahol:

• Gyakoribb a tesztelés.
• A teljes csapat tudja, hogy mit és hogyan kell tesztelni, és meg lehet osztani a feladatokat.
• Tesztelés kevésbé a dokumentáción, hanem inkább a csapattagok együttműködésén alapul.

A Tesztelés Vezérelt Fejlesztés egy nagyszerű példája annak, hogyan vonjuk be a tesztelést az agilis folyamatba. A Tesztelés Vezérelt Fejlesztés (továbbiakban TDD) egy olyan szoftver fejlesztési folyamat, amely nagy hangsúlyt fektet a szoftverek minőségére. Hagyományosan a fejlesztő megírja a kódot, ezután a tesztelési részleg megvizsgálja azt, és jelenti a hibákat.

Sőt, A TDD-ben a fejlesztők azok, akik először unit teszt2-eket írnak mielőtt még bármilyen kódot megírnának, amely kiegészítené a User Story-kat. Természetesen minden feladatban lehetséges az együttműködés, így vannak olyan esetek, amikor a fejlesztő együtt dolgozik a minőségbiztosítóval és lehetséges teszteseteket fogalmaznak meg.

Addig a teszt sikertelen lesz, amíg a fejlesztő meg nem írja azt a minimális kódot, ami sikeres teszthez kell. Következő lépésként a kódot refaktorálják, hogy az megfeleljen csapat minőségi elvárásainak.

A TDD-t alkalmazható Scrum vagy Kanban módszertan esetében is. A lényeg, hogy a középpontban a tesztelés és az általános minőség álljon. Emellett ezzel a módszerrel a tesztelés agilisabbá tehető, mivel a tesztelési3 folyamatokat közelebb viszi a fejlesztési életciklus korai stádiumaihoz. Minden story elején, amikor a teszt forgatókönyveket megírjuk, a fejlesztőknek is ismerniük és érteniük kell a követelményeket és együtt kell működniük a csapat többi tagjával. Ezzel minimálisra csökkenthető a felesleges kódok írása, és már a fejlesztési életciklus elején tisztázható minden félreértés.

Regressziós tesztek automatizálása

A regressziós tesztelés a tesztelésnek egy olyan típusa, amellyel ellenőrizhető, hogy a korábban fejlesztett, és letesztelt szoftver még most is megfelelően működik, miután változások történtek és más szoftverrel össze lett kapcsolva. A változások tartalmazhatnak szoftver javításokat, patch-eket, konfigurációs változásokat, stb.

Amennyiben a regressziós tesztelésnek az adott szoftveren bármi értelme is van, akkor azt olyan gyakran le kell futtatni, amilyen gyakran csak lehet, legalább minden sprintben, de ideális esetben naponta. Hogy miért? Mert ez egy stabil tesztkészlet, ami minden rendellenes rendszer működést kimutat, és reagál a nagyobb változásokra.

Felmerül még egy kérdés – mekkora a rendszer? Kis rendszerek esetében általában cecklist-ekkel érdemes dolgozni, és nem tesztkészletekkel a nagyobbak esetében pedig inkább tesztkészletekkel. Annak eldönté se, hogy mit automatizáljunk mindig nehéz kérdés, mivel az automata szkriptek nem minden esetben mutathatók meg az ügy félnek. Ebből adódik a kérdés, hogy egyáltalán MIÉRT automat iz áljunk le bár mit is?

A probléma az, hogy az automata tesztkészlet megbízhatatlan és nem is mindig hiteles, valamint igen nagy energiába ker ül a folyamatos ak tualiz álása. Ezeket a tesztkészleteket folyamatosan kar ban kell tartani, és folyamatosan bővíteni kell. Az automatizálás remek megoldás, de ez is csak egy eszköz nem a projekt célja.

És a legfontosabb még agilis környezet ben is a gyakori felülvizsgálat és priorizálás. Senkinek sem hasznosak a sokáig futó tesztkészletek, ugye? Az automat izált regressziós tesztek nek hatékonynak kell lenniük, és a fejlesztés korai szakaszában figyelmeztetniük kell a problémákra, így érhetünk el ténylegesen magasabb minőséget és így lehetünk igazán agilisek.

Tesztelési feladatok megjelenítése

Az egyik legjobb példa erre a Kanban tábla működése, itt nemcsak a fejlesztői feladatok, hanem az összes feladat megjeleníthető.

Egy nagyszerű ötlet a csapat számára, hogy kisebb, ismétlődő manuális tesztelési feladatokat tudnak kiválasztani automatizálásra. Ezek a feladatokat is mind fel lehet vezetni a Kanban táblára, és a megfelelő módon lehet ezeket kezelni. Ez nem azt jelenti, hogy a tesztelők a kizárólagos felelősei ennek a feladatnak.

Ezen kívül a kereszt funkcionális agilis csapatokban, ez nagyszerű lehetőség ad a tesztelők számára, hogy kódolni és automatizálni tanulhassanak valamint a fejlesztők számára, hogy több figyelmet szentelhessenek a kód minőségének.

Kommunikáció

Nem számít, hogy a projekt Scrum, Kanban, vagy más agilis módszertan szerint működik-e, a siker kulcsa a csapatok közötti kommunikációban rejlik.