Agilis fejlesztési modell

Agilis megközelítésben a csapat rövid munkaszakaszokban készít értékelhető eredményt, majd a visszajelzés alapján módosítja a következő feladatokat. A tesztelés nem külön végső állomás: a követelmény tisztázása, a megvalósítás és az ellenőrzés gyakran egymással párhuzamosan zajlik. A tesztelő, a fejlesztő és az üzleti szereplő közösen tudja megbeszélni, milyen viselkedést várnak a kész résztől.

Az agilis munkát nem egyetlen kötelező ceremónia vagy eszköz határozza meg. A lényeg itt az, hogy a változó igényekről időben érkezzen visszajelzés, és minden elkészült rész ellenőrizhető állapotba kerüljön. Ha a csapat csak az iteráció utolsó óráiban kezdi a tesztelést, a hibákra és a javítások ellenőrzésére már kevés idő marad.

Egy felhasználói történet önmagában lehet túl tág: „Diákként szeretnék kurzust keresni, hogy könnyen megtaláljam a megfelelőt.” A tesztelhetőséghez tisztázni kell, mi számít találatnak, mi történik üres keresésnél, látható-e a betelt kurzus, és hogyan kezeljük az ékezeteket. Az elfogadási feltételek konkrét, megfigyelhető eredményt fogalmaznak meg; ezek tesztet inspirálnak, de nem feltétlenül fednek le minden kockázatot.

Jó közös munka, ha a három nézőpont – üzleti igény, fejlesztői megvalósítás és tesztelhetőség – még a kódolás előtt példákat ír. Például: ha a keresett szó „adat”, csak azok a kurzusok kerülnek az eredménybe, amelyek neve megfelel az elfogadott keresési szabálynak. A példák közben gyakran kiderül, hogy a „megfelel” szó pontosítása még hiányzik.

A fejlesztő gyors komponenstesztjei visszajelzést adhatnak a belső logikáról. Az integrációs tesztek ellenőrizhetik, hogy a kereső megfelelő adatot kap a tárolóból. A felületi próbák az egész folyamatot vizsgálhatják. A tesztelő felderítő tesztelése különösen hasznos ott, ahol az ismert példák mellett váratlan állapotok is előjöhetnek. Az automatizálás segíthet a gyakori ismétlésben, de nem dönt önmagában az elvárás helyességéről.

Ha új szűrőt vezetnek be, a korábbi keresési és jogosultsági eseteket is érdemes ismét ellenőrizni. Ez regressziós vizsgálat, amelynek mélységét a változás kockázata határozza meg. Egy kör végén a csapat azt is áttekinti, hogyan működött a közös tesztelés: időben voltak-e tesztadatok, érthető volt-e az elvárás, és melyik hiányt kell a következő ciklusban megszüntetni.

Tegyük fel, hogy a csapat feladata a diákoknak elérhető szabad helyek megjelenítése. A felhasználó képviselője tudja, melyik helyet számítják szabadnak; a fejlesztő látja, milyen adatok tárolódnak; a tesztelő azt kérdezi, milyen eredménynek kell látszania két egyidejű jelentkezés után. Az egyeztetés eredménye lehet pontosabb szabály és több megelőző teszt, mielőtt a kód elkészül.

Egy jól megfogalmazott elfogadási példa meghatározott kiinduló helyzetből indul ki. Például 20 férőhelyből 19 foglalt, és egy jogosult diák sikeresen jelentkezik. Ezután 0 szabad hely látszik. A példa az ismert működést rögzíti, de külön kérdés, hogy mi történik, ha ugyanabban a pillanatban ketten jelentkeznek. Az utóbbit kockázat alapján kell hozzáadni.

A fejlesztő által futtatott kis tesztek gyorsan észreveszik a számolási hibát. Az API ellenőrzése a részek közti adatátadást vizsgálja, a böngészős próba pedig a teljes felhasználói folyamatot. Ezek eltérő felbontású visszajelzések; az egyik sikeréből nem következik automatikusan a másik sikere. A tesztelő felderítő munkája olyan helyzetet tárhat fel, amire a rögzített példák nem gondoltak.

Az iteráció végén érdemes megnézni, melyik visszajelzés érkezett túl későn. Ha a tesztadat csak a bemutató előtt állt rendelkezésre, a következő körben korábban kell előkészíteni. Az ilyen folyamatjavítás nem maga a termék hibajavítása, de segít abban, hogy a következő inkrementum gyorsabban és biztosabban értékelhető legyen.