Agilis tesztelés: Módszertan és életciklus

Mi az agilis tesztelés?

Agilis tesztelés egy olyan tesztelési gyakorlat, amely az agilis szoftverfejlesztés szabályait és alapelveit követi. A Waterfall módszerrel ellentétben az agilis tesztelés a projekt elején kezdődik, és folyamatosan fut a fejlesztéssel együtt. Nem szekvenciális – csak a kódolási fázis után hajtódik végre –, hanem minden iterációba beépül, így a visszajelzés a hibák megjelenésének pillanatában elérkezik a csapathoz.

Az agilis tesztelés alapelvei

Az agilis tesztelés alapvető alapelvei a következők:

• A működő szoftver a fejlődés elsődleges mércéje.
• A legjobb eredményeket az önszerveződő csapatok hozzák.
• Az értékes szoftverek korai és folyamatos leszállítása a legfontosabb prioritás.
• A fejlesztők és a tesztelők a projekt során naponta együttműködnek.
• Az agilitás folyamatos műszaki fejlesztéssel és jó tervezéssel fokozható.
• A folyamatos visszajelzés biztosítja, hogy a végtermék megfeleljen az üzleti elvárásoknak.
• A tesztelés a megvalósítás során fut, ami csökkenti a teljes fejlesztési időt.
• A tesztelési folyamat következetes, fenntartható ütemben zajlik.
• A csapatok rendszeresen szünetet tartanak, hogy reflektáljanak és alkalmazkodjanak a hatékonyabb működéshez.
• A legjobb architektúrák, követelmények és tervek önszerveződő csapatokból születnek.
• A személyes beszélgetés a leghatékonyabb és legeredményesebb kommunikációs forma a csapaton belül.

Együttesen alkalmazva ezek az elvek növelik a szoftver termelékenységét és lerövidítik az ötlettől a működő funkcióig vezető utat.

Agilis tesztelési életciklus

Az agilis tesztelési életciklus öt fázisban zajlik, az alábbiak szerint.

A fázisok a következők:

• 1. fázis: Hatásvizsgálat. Gyűjtsön visszajelzéseket az érdekelt felektől és a felhasználóktól. Ezt a fázist visszajelzési fázisnak is nevezik, mert segít a tesztmérnököknek a következő életciklus céljainak kitűzésében.
• 2. fázis: Agilis tesztelés tervezése. Minden érdekelt fél közösen tervezi meg a tesztelés ütemtervét, hatókörét és a teljesítendő eredményeket.
• 3. fázis: Felengedésre való felkészültség. RevTekintse meg a megvalósított funkciókat, és döntse el, melyek állnak készen az éles üzembe helyezésre, és melyeket kell visszaállítani a fejlesztéshez.
• 4. fázis: Napi Scrumok. A reggeli álló megbeszélés, ahol a csapat átbeszéli a tesztelés állapotát és kitűzi a napi célokat.
• 5. fázis: Agility tesztelése Review. Heti rendszerességgel egyeztetett megbeszélések az érdekelt felekkel a célokhoz való viszonyítás érdekében, és a stratégia módosítására.

Agilis tesztterv

An agilis tesztelési terv leírja az iterációban végrehajtott tesztelés típusait, a szükséges adatokat és infrastruktúrát, a tesztkörnyezetek, és a teszteredményeket. A vízesés modellel ellentétben minden kiadáshoz agilis teszttervet írnak és frissítenek. Egy tipikus terv a következőket tartalmazza:

• Tesztelési hatókör.
• Új funkciók tesztelése folyamatban.
• A tesztelés szintje vagy típusa a jellemzők összetettsége alapján.
• Terhelési és teljesítménytesztelés.
• Infrastruktúra-megfontolások.
• Kockázat- és kockázatcsökkentési terv.
• Erőforrások.
• Teljesítendő eredmények és mérföldkövek.

Agilis tesztelési stratégiák

Az agilis tesztelési életciklus négy stratégiai szakaszból áll.

Iteráció 0

Az első szakaszban a kezdeti beállítási feladatokat kell elvégezni. Ezek közé tartozik a tesztelésre kijelölt személyek azonosítása, a tesztelési eszközök telepítése és az erőforrások, például egy használhatósági tesztelési laboratórium ütemezése. A 0. iteráció céljai a következők:

• Készítsen üzleti tervet a projekthez.
• Határozza meg a peremfeltételeket és a projekt hatókörét.
• Vázolja fel a tervezési kompromisszumokat előmozdító főbb követelményeket és használati eseteket.
• Vázoljon fel egy vagy több lehetséges architektúrát.
• A kockázatok azonosítása.
• Költségbecslés és előzetes projektterv elkészítése.

Építési iterációk

Az agilis tesztelés második fázisa a Konstrukciós Iterációk, amelyek során a tesztelés nagy része történik. Ez a fázis olyan iterációk halmaza, amelyek lépésről lépésre építik fel a megoldást. Minden iteráción belül a csapat az XP, a Scrum, az agilis modellezés és az agilis adatok hibrid gyakorlatait alkalmazza.

A csapatok a priorizált követelményrendszert követik: minden iterációval kiválasztják a legfontosabb elemeket a várólistából, és megvalósítják azokat. A konstrukciós iterációk két kiegészítő tesztelési típusra oszlanak:

• Megerősítő tesztelés ellenőrzi, hogy a rendszer megfelel-e az érdekelt felek szándékainak. Ezt maga a csapat végzi.
• Vizsgálati tesztek olyan problémákat keres, amelyeket a megerősítő tesztelés esetleg nem vett észre. A tesztelők hibatörténetek formájában vetik fel a potenciális problémákat. A vizsgáló tesztelés az integrációs, a terheléses és stresszes, valamint a biztonsági tesztelést is magában foglalja.

A megerősítő tesztelésnek további két aspektusa van – fejlesztői tesztelés és a agilis átvételi tesztelés – és mindkettő automatizált, hogy lehetővé tegye a folyamatos regressziós tesztelést a teljes életciklus során. A konfirmator tesztelés a specifikáció szerinti tesztelés agilis megfelelője.

Az agilis elfogadási tesztelés ötvözi a hagyományos funkcionális és az elfogadási tesztelést, mivel a fejlesztőcsapat és az érdekelt felek együtt végzik. A fejlesztői tesztelés a hagyományos egységtesztelést a szolgáltatásintegrációs teszteléssel ötvözi, és mind az alkalmazáskódot, mind az adatbázis-sémát ellenőrzi.

Megjelenés, Végjáték vagy Átmeneti Fázis

A kiadási fázis célja a rendszer sikeres éles üzembe helyezése. A tevékenységek magukban foglalják a végfelhasználók, a támogató személyzet és az üzemeltetési csapatok képzését; a termékkiadás marketingjét; a biztonsági mentési és visszaállítási gyakorlatokat; valamint a rendszer- és felhasználói dokumentáció véglegesítését.

Az agilis tesztelés utolsó szakasza teljes rendszertesztelést és átvételi tesztelést foglal magában. A problémamentes befejezéshez a terméket szigorúan kell tesztelni a konstrukciós iterációk során. A végső játék során a tesztelők a ciklus korábbi szakaszában felmerült hibatörténetek megoldására összpontosítanak.

Termelés

A kiadási szakasz után a termék gyártásba kerül, ahol figyelemmel kísérik az éles viselkedését, és az esetleges problémákat visszacsatolják a következő tervezési ciklusba.

Az agilis tesztelési kvadránsok

Az agilis tesztelési kvadránsok négy területre osztják a teljes folyamatot, és segítenek a csapatoknak megérteni, hogyan történik az agilis tesztelés.

Agilis I. kvadráns

Az I. kvadráns a belső kódminőségre összpontosít, technológiavezérelt tesztekkel, amelyek támogatják a csapatot:

• Egységtesztek.
• Komponens tesztek.

Agilis kvadráns II

A II. kvadráns üzleti célú teszteket tartalmaz, amelyek támogatják a csapatot és a követelményekre összpontosítanak. A kvadránsban végzett tipikus munka a következőket foglalja magában:

• Lehetséges forgatókönyvek és munkafolyamatok tesztelési példái.
• Felhasználói élményt nyújtó artefaktumok, például prototípusok tesztelése.
• Páros tesztelés.

Agilis Kvadráns III

A III. kvadráns visszajelzést ad az I. és II. kvadránsnak. Az itt elvégzett tesztesetek gyakran képezik az automatizálás alapját, és a többszöri iterációs felülvizsgálat bizalmat épít a termék iránt. A tipikus feladatok közé tartozik:

• Használhatósági tesztelés.
• Feltáró tesztelés.
• Páros tesztelés ügyfelekkel.
• Együttműködésen alapuló tesztelés.
• Felhasználói elfogadási tesztelés.

Agilis Kvadráns IV

A IV. kvadráns a nem funkcionális követelményekre, például a teljesítményre, a biztonságra és a stabilitásra összpontosít. Ez a kvadráns biztosítja, hogy az alkalmazás a várt nem funkcionális tulajdonságokat nyújtsa. Tipikus feladatok a következők:

• Nem funkcionális tesztek, mint például a terhelés- és teljesítményteszt.
• Biztonsági tesztelés, amely kiterjed a hitelesítésre és a behatolási kísérletekre.
• Infrastruktúra tesztelés.
• Adatmigrációs tesztelés.
• Skálázhatósági tesztelés.
• Terheléses tesztelés.

QA kihívások az agilis szoftverfejlesztésben

Az agilis megvalósítás valódi előnyökkel jár, de új kihívásokat is teremt a minőségbiztosítási csapatok számára:

• A dokumentáció alacsonyabb prioritást kap, így a hibalehetőségek kockázata megnő, és a nyomás a minőségbiztosítási csapatra helyeződik át.
• Az új funkciók gyorsan érkeznek, így a tesztelőknek kevesebb idejük van a legújabb funkcióknak a követelményeknek és az üzleti szándéknak való megfelelésének ellenőrzésére.
• A tesztelők gyakran félig fejlesztői szerepet töltenek be.
• A tesztvégrehajtási ciklusok erősen tömörítettek.
• A tesztterv elkészítésére korlátozott idő áll rendelkezésre.
• A regressziós tesztelés költségvetése szűkössé válik.
• A tesztelők a minőség kapuőreiből a minőség partnereivé válnak.
• Az agilis módszertan velejárója a gyakori követelményváltozás, ami a minőségbiztosítás egyik legnagyobb kihívása.

Az automatizálás kockázata az agilis folyamatokban

Az automatizálás elengedhetetlen az agilis módszertanban, de olyan kockázatokkal jár, amelyeket a csapatoknak aktívan kell kezelniük:

• Az automatizált felhasználói felület tesztjei nagyfokú megbízhatóságot kínálnak, de lassúak, törékenyek és költségesek a karbantartásuk. A termelékenység növekedése csak akkor jelentkezik, ha a tesztelők tudják, hogyan kell jó teszteket tervezni.
• A megbízhatatlan tesztek komoly aggodalomra adnak okot. A törékeny tesztek és a téves pozitív eredmények javításának továbbra is kiemelt prioritásnak kell lennie.
• A manuálisan, nem pedig konfigurációelemzésen (CI) keresztül futtatott automatizált tesztek azzal a kockázattal járnak, hogy észrevétlenül sodródnak és elavult eredményeket produkálnak.
• Az automatizálás nem helyettesíti a feltáró manuális tesztelést. A várt minőség eléréséhez a tesztelési típusok és szintek keverékére van szükség.
• A rögzítésre és visszajátszásra szolgáló eszközök felhasználói felület-vezérelt, törékeny és nehezen karbantartható szkripteket ösztönöznek. A verziókövetésen kívül tárolt tesztek szükségtelenül bonyolulttá teszik a rendszert.
• A rosszul megtervezett automatizálás, amelyet az „időmegtakarítás” érdekében végeznek, gyakran teljes kudarcot vall.
• A tesztbeállítás és a lebontás folyamata könnyen elsiklik automatizáláskor, míg a manuális tesztelés természetes módon kezeli ezeket.
• Az olyan termelékenységi mutatók, mint a „napi tesztesetek száma”, félrevezethetik a csapatokat, és emiatt haszontalan teszteket futtathatnak.
• Az automatizálási csapatnak hatékony tanácsadóknak kell lennie – megközelíthetőnek, együttműködőnek és találékonynak –, különben a gyakorlat kudarcot vall.
• A folyamatos, intenzív karbantartást igénylő megoldások meghaladhatják az általuk nyújtott értéket.
• Az automatizált tesztek esetleg nem rendelkeznek a hatékony megoldások szállításához szükséges szakértelemmel.
• A sikeres automatizálás során kifogyhatnak a megoldandó fontos problémákból, és kevésbé értékes feladatokra sodródhatnak.

A hatékony agilis tesztelés legjobb gyakorlatai

A következő gyakorlatok biztosítják az agilis tesztelés gyorsaságát, megbízhatóságát és értékességét a csapat számára:

• Shift bal: A tesztelést a követelmények időpontjában kell elkezdeni, ne az iteráció végén.
• Párosítsd a fejlesztőkkel: Tekintsék át együtt az elfogadási kritériumokat, hogy a hibákat kitervezzék, ne pedig belekódolják.
• Rétegautomatizálás: Építs fel egy egészséges piramist az egység-, szolgáltatás- és felhasználói felület-tesztekből.
• A tesztek függetlenségének megőrzése: izolálja az egyes teszteket, hogy a hibák egyetlen kiváltó okra mutassanak.
• Track egyenetlen tesztek: karanténba helyezni és a bizonytalan teszteket azonnal kijavítani, hogy megakadályozzuk a csomagba vetett bizalom megrendülését.
• Használjon mesterséges intelligenciával támogatott elemzést: Hagyja, hogy az eszközök megjelöljék az érintett teszteket, csoportosítsák a hibákat, és minden egyesítés után stabil helymeghatározókat javasoljanak.

GYIK