Az agilis fejlesztés és vele együtt a tesztelés teljesen más szemléletet kíván meg. A tesztelés is ugyanolyan ciklusban működik, mint a fejlesztők esetén, nincs is különbség, egy csapatba kell hogy tartozzanak. Ugyanis a teszteknek és tesztelőknek ugyanolyan rugalmasnak kell lennie, mint a fejlesztőknek a fejlesztés során. A “whole team” szemlélet megköveteli, hogy a csapat egy-egy tagja ne csak egy területen legyen specialista, hanem legyen általánosságban véve specialista. Így a csapatból többen fognak érteni a programozáshoz, az adatbázis tervezéshez, de akár a teszteléshez is. Ezáltal a folyamatos kis lépésekben történő fejlesztés része lesz a tesztelés is.
A tesztelők szempontjából megkülönböztethetünk két szemléletet. A teljesen független és a párhuzamosan független tesztelést. A teljesen független tesztelést a tesztelők a user story-k alapján végzik el. Kérdéses, hogy mennyire hatékony ez a módszer ugyanis sokszor nem elegendő a story-k ismerete ahhoz, hogy újrafelhasználható teszteket írjanak. Ehelyett inkább előnyben kéne részesíteni a párhuzamosan független tesztelést, amelynél a tesztelő az agilis csapathoz szorosabban fog tartozni és az adott rész tesztelését akár egy fejlesztővel együtt végzik. Ilyenkor a tesztelő jobban átlátja a tesztelendő rendszer működését és könnyebben ír hatékony teszteket, a fejlesztő segítségével pedig újrahasználható formában tudják megvalósítani.
Agilis tesztelés követelményei:
- Gyors tesztelési automatizálás, nagy fokú rugalmasság a változásoknál.
- Gyors visszajelzés a megfelelő szemlélettel rendelkező fejlesztők felé.
- Csökkentenie kell a kiadásokat a gyors és hatékony hibakeresés segítségével.
- Időben kiadott, magas minőségű rendszert kell biztosítania.
Az első szint, ami a fejlesztőket érint az a Test Driven Development ( TDD ). Külső függőségek nélküli kódhoz kell kis lépésekben teszteket írniuk, hogy a fejlesztés és legfőképpen a tervezés kis, folyamatos és biztonságos lépésekben történhessen. A gyakorlat azt mutatja, hogy sokan nem képesek a TDD által megkívánt fegyelemre (például betartani, hogy először a tesztesetet írják meg és utána a kódot), ezáltal a TDD-től eltérően a kód elkészülte után egyből írják meg a tesztet. Ez is jobb, mintha pár héttel később írnák meg a tesztet. A kódolás utáni teszt írás egyik oka lehet például a tesztek általi kódlefedettséget mérő eszközök, amelyek jelzik, hogy a kód hány százalékát érint teszt, és egyes fejlesztőket az motiválja, ha elérik a 90% feletti értéket. Ez a szemlélet csak a kód érvényesítését szolgálja.
A következő szint az integration teszt. Agilis környezetben nehéz feladat, arra kell törekedni, hogy a tesztelők és a fejlesztők megtalálják annak a módját, hogy minél több újrahasználható tesztet tudjanak írni.
Agilis integration teszt lépései:
- Azonosítani kell az egyes szoftverelemeket.
- Újrahasználható, környezetfüggetlen teszt eseteket kell kitalálni.
- A még nem automatizálható részekhez szimulátorokat kell írni.
- Illesztők elkészítése a tesztet végrehajtó modulba, hogy kezeljék a szimulátorokat vagy közvetlenül az egyes szoftvermodulokat.
Fontos, hogy használjunk illesztőket agilis tesztelés esetén. A tesztesetek megfogalmazásánál úgy járjunk el, hogy csak az ügyfél szempontjából fontos paramétereket tartalmazza. Például, ha egy API-t akarunk tesztelni, akkor adjuk meg a kívánt lekérdezés paramétereit ügyfél szempontból és írjunk hozzá egy illesztőt, ami elvégzi a REST-es hívásokat. A technikai háttér megváltozásakor, például REST helyett SOAP lesz, csak egy új SOAP illesztőt kell írni a tesztekhez, ezáltal a legtöbb teszteset ugyanúgy használható lesz.
Fontos, hogy az agilis tesztelést, csak fokozatosan kéne bevezetni, ha egyszerre akarunk mindent bevezetni, akkor sehova nem jutunk. Lépésről lépésre kéne kipróbálni az egyes módszereket, ami hatékony azt megtartani, ami nem azt elvetni.
No comments:
Post a Comment