Mi az agilis tesztelés? Folyamat és életciklus

Mi az agilis tesztelés?

Agilis tesztelés egy tesztelési gyakorlat, amely követi az agilis szoftverfejlesztés szabályait és elveit. A Waterfall módszertől eltérően az Agilis Tesztelés a projekt elején elkezdődhet, folyamatos integrációval a fejlesztés és a tesztelés között. Az agilis tesztelés módszertana nem szekvenciális (abban az értelemben, hogy csak a kódolási fázis után kerül végrehajtásra), hanem folyamatos.

Az agilis tesztelés alapelvei

Íme az agilis tesztelés alapelvei:

• Ebben az Agilis tesztelési modellben a működő szoftver a fejlődés elsődleges mércéje.
• A legjobb eredményt az önszerveződő csapatok érhetik el.
• Legfontosabb prioritásunk az értékes szoftverek korai és folyamatos szállítása.
• A szoftverfejlesztőknek a projekt során naponta össze kell gyűlniük.
• A mozgékonyság fokozása folyamatos műszaki fejlesztéssel és jó tervezéssel.
• Az agilis tesztelés biztosítja, hogy a végtermék megfeleljen a vállalkozás elvárásainak, folyamatos visszajelzést adva.
• Az Agilis Teszt folyamatban az implementáció során kell végrehajtanunk a tesztelési folyamatot, ami csökkenti a fejlesztési időt.
• Az Agilis tesztelési folyamatnak a következetes fejlesztési ütemben kell működnie
• Rendszeresen gondolkodjon el arról, hogyan válhat hatékonyabbá.
• A legjobb architektúrák, követelmények és tervek önszerveződő csapatokból születnek.
• Minden alkalommal, amikor a csapat találkozik, felülvizsgálja és módosítja viselkedését, hogy hatékonyabb legyen.
• A fejlesztőcsapattal folytatott személyes beszélgetés a leghatékonyabb és legeredményesebb módszer a csapaton belüli információtovábbításra.

Az agilis tesztelés különböző alapelveket tartalmaz, amelyek segítenek a szoftver termelékenységének növelésében.

Agilis tesztelési életciklus

Az agilis tesztelés életciklusa öt különböző fázisban zajlik, amint azt az alábbi képen is láthatjuk:

Íme az agilis folyamattesztelés lépései:

1. szakasz: Hatásvizsgálat: Ebben a kezdeti szakaszban az érdekelt felektől és a felhasználóktól gyűjtjük be az észrevételeket. Ezt a fázist visszacsatolási fázisnak is nevezik, mivel ez segíti a tesztmérnököket a következő életciklusra vonatkozó célok kitűzésében.

2. fázis: Agilis tesztelés tervezése: Ez az Agilis tesztelés életciklusának második szakasza, ahol az összes érdekelt fél összejön, hogy megtervezzék a tesztelési folyamat ütemtervét és az eredményeket.

3. fázis: Kiadási készenlét: Ebben a szakaszban áttekintjük a kifejlesztett/megvalósított funkciókat, hogy készen állnak-e az élesítésre vagy sem. Ebben a szakaszban az is eldől, hogy melyiknek kell visszatérnie az előző fejlesztési fázishoz.

4. Fázis: Napi scrumok: Ez a szakasz magában foglal minden standup reggeli megbeszélést, hogy utolérjük a tesztelés állapotát, és kitűzzük a célt az egész napra.

5. fázis: Agility tesztelése Revazaz: Az Agilis életciklus utolsó fázisa az Agility Review Találkozó. Ez magában foglalja a heti találkozókat az érdekelt felekkel, hogy rendszeresen értékeljék és értékeljék az előrehaladást a célokhoz képest.

Agilis tesztterv

Agilis tesztterv magában foglalja az adott iterációban végzett tesztelés típusait, mint például a tesztadat-követelmények, az infrastruktúra, tesztkörnyezetekés a vizsgálati eredményeket. A vízesés modelltől eltérően egy agilis modellben minden kiadáshoz tesztterv készül és frissítik. Az agilis teszttervek tipikus részei

• Tesztelés hatóköre
• Új funkciók, amelyeket tesztelnek
• A tesztelés szintje vagy típusai a szolgáltatások összetettsége alapján
• Terhelési és teljesítményteszt
• Infrastruktúra mérlegelés
• Mérséklési vagy kockázati terv
• Újrafeldolgozás
• Teljesítmények és mérföldkövek

Agilis tesztelési stratégiák

Az agilis tesztelés életciklusa négy szakaszból áll

Iteráció 0

Az első szakasz vagy a 0. iteráció során a kezdeti beállítási feladatokat hajtja végre. Ez magában foglalja a teszteléshez szükséges személyek azonosítását, a tesztelőeszközök telepítését, az erőforrások ütemezését (használhatósági tesztlabor), stb. A következő lépéseket kell elvégezni a 0. iterációban

• A projekt üzleti alapjainak kialakítása
• Határozza meg a peremfeltételeket és a projekt hatókörét
• Vázolja fel azokat a kulcsfontosságú követelményeket és felhasználási eseteket, amelyek a tervezési kompromisszumokat eredményezik
• Vázoljon fel egy vagy több jelölt architektúrát
• A kockázat azonosítása
• Költségbecslés és előzetes projekt készítése

Építési iterációk

Az agilis tesztelési módszertan második fázisa a konstrukciós iterációk, a tesztelések nagy része ebben a fázisban történik. Ezt a fázist iterációk halmazaként figyeljük meg a megoldás növekményének felépítéséhez. Ennek érdekében minden iteráción belül a csapat végrehajtja az XP, a Scrum, az Agilis modellezés és az agilis adatok gyakorlatainak hibridje, és így tovább.

Az építési iteráció során az agilis csapat a prioritási követelmény gyakorlatot követi: minden iterációnál kiveszik a munkaelem-halomból megmaradt leglényegesebb követelményeket és megvalósítják azokat.

Az építési iteráció két csoportra osztható, a megerősítő tesztelésre és a vizsgálati tesztelésre. Megerősítő vizsgálati koncentrátumok annak ellenőrzésekor, hogy a rendszer teljesíti-e az érdekelt felek azon szándékát, amelyet a csapat eddig leírt, és azt a csapat végzi. Míg a vizsgálati tesztelés azt a problémát észleli, amelyet a megerősítő csapat kihagyott vagy figyelmen kívül hagyott. Az oknyomozó tesztelés során a tesztelő hibatörténetek formájában határozza meg a lehetséges problémákat. Az oknyomozó tesztelés olyan gyakori problémákkal foglalkozik, mint az integrációs tesztelés, a terhelési/feszültség-tesztelés és a biztonsági tesztelés.

A megerősítő tesztelésnek ismét két szempontja van fejlesztői tesztelés és a agilis átvételi tesztelés. Mindkettő automatizáltak, hogy lehetővé tegyék a folyamatos regressziós tesztelést az életciklus során. A megerősítő tesztelés a specifikáció szerinti tesztelés agilis megfelelője.

Az agilis átvételi tesztelés a hagyományos funkcionális tesztelés és a hagyományos elfogadási tesztelés kombinációja, amelyet a fejlesztőcsapat végez, és az érintettek együtt végzik ezt. Míg a fejlesztői tesztelés a hagyományos egységteszt és a hagyományos szolgáltatásintegrációs tesztelés keveréke. A fejlesztői tesztelés az alkalmazáskódot és az adatbázissémát is ellenőrzi.

Engedd ki a játék végét vagy az átmeneti fázist

A „Release, End Game” célja a rendszer sikeres üzembe helyezése a termelésben. A tevékenységek ebben a szakaszban a végfelhasználók, a támogató személyek és az operatív személyek képzését foglalják magukban. Ezenkívül magában foglalja a termék kiadásának marketingjét, biztonsági mentést és visszaállítást, valamint a rendszer és a felhasználói dokumentáció véglegesítését.

Az agilis módszertan tesztelésének utolsó szakasza teljes rendszertesztelést és átvételi tesztelést foglal magában. Annak érdekében, hogy az utolsó tesztelési szakaszt minden akadály nélkül befejezze, szigorúbban kell tesztelnie a terméket az építési iterációk során. A játék végén a tesztelők a hibatörténeteken dolgoznak majd.

Termelés

A kiadási szakasz után a termék a gyártási szakaszba kerül.

Az agilis tesztelési kvadránsok

Az agilis tesztelési kvadránsok az egész folyamatot négy kvadránsra választják el, és segítenek megérteni, hogyan hajtják végre az agilis tesztelést.

Agilis I. kvadráns

Ebben a kvadránsban a belső kód minősége a fő hangsúly, és olyan tesztesetekből áll, amelyek technológia által vezéreltek és a csapat támogatására vannak implementálva.

• Egységtesztek
• Alkatrész tesztek

Agilis kvadráns II

Olyan teszteseteket tartalmaz, amelyek üzletileg vezéreltek, és a csapat támogatására vannak megvalósítva. Ez a kvadráns a követelményekre összpontosít. Az ebben a fázisban elvégzett teszt típusa az

• Lehetséges forgatókönyvek és munkafolyamatok példáinak tesztelése
• A felhasználói élmény, például a prototípusok tesztelése
• Páros tesztelés

Agilis Kvadráns III

Ez a kvadráns visszajelzést ad az első és a második kvadránsnak. A tesztesetek alapul szolgálhatnak automatizálási teszteléshez. Ebben a kvadránsban számos iterációs felülvizsgálatot hajtanak végre, ami növeli a termékbe vetett bizalmat. Az ebben a kvadránsban végzett tesztelés típusa

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

Agilis Kvadráns IV

Ez a kvadráns a nem funkcionális követelményekre koncentrál, mint például a teljesítmény, a biztonság, a stabilitás stb. Ennek a kvadránsnak a segítségével az alkalmazás a nem funkcionális tulajdonságokat és az elvárt értéket nyújtja.

• Nem funkcionális tesztek, például stressz- és teljesítményteszt
• Biztonsági tesztelés tekintetében hitelesítés és a hackelés
• Infrastruktúra tesztelés
• Adatmigrációs tesztelés
• Skálázhatósági tesztelés
• Terhelési tesztelés

Minőségbiztosítási kihívások az agilis szoftverfejlesztéssel

• A hibalehetőségek agilisabbak, mivel a dokumentáció kevésbé prioritást élvez, ami végül nagyobb nyomást gyakorol a minőségbiztosítási csapatra
• Az új funkciók gyorsan bevezetésre kerülnek, ami csökkenti a tesztcsoportok rendelkezésére álló időt annak megállapítására, hogy a legújabb funkciók megfelelnek-e a követelményeknek, és valóban megfelel-e az üzleti igényeknek.
• A tesztelőknek gyakran félig fejlesztő szerepet kell betölteniük
• A tesztvégrehajtási ciklusok erősen tömörítettek
• Nagyon rövidebb idő a tesztterv elkészítésére
• A regressziós teszteléshez minimális időre van szükségük
• Szerepük megváltozása a minőség kapuőréről a minőségi partnerré
• A követelmények változásai és frissítései az agilis módszer velejárói, és ez a minőségbiztosítás legnagyobb kihívása

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

• Az automatizált felhasználói felület magas szintű biztonságot nyújt, de lassúak a végrehajtásuk, törékeny karbantartásuk és költséges a felépítésük. Előfordulhat, hogy az automatizálás nem javítja jelentősen a tesztek termelékenységét, hacsak a tesztelők nem tudják, hogyan kell tesztelni
• A megbízhatatlan tesztek komoly problémát jelentenek az automatizált tesztelés során. A sikertelen tesztek kijavítása és a rideg tesztekkel kapcsolatos problémák megoldása elsődleges prioritás kell, hogy legyen a téves pozitív eredmények elkerülése érdekében
• Ha az automatizált tesztet manuálisan kezdeményezik, nem pedig CI-n (folyamatos integráción) keresztül, akkor fennáll annak a veszélye, hogy nem futnak rendszeresen, és ezért a tesztek sikertelenségét okozhatják.
• Az automatizált tesztek nem helyettesítik a feltáró kézi tesztelést. A termék elvárt minőségének eléréséhez különböző vizsgálati típusok és szintek keveréke szükséges
• Számos kereskedelmi forgalomban kapható automatizálási eszköz egyszerű funkciókat kínál, mint például a kézi tesztesetek rögzítésének és visszajátszásának automatizálása. Az ilyen eszköz ösztönzi a felhasználói felületen keresztüli tesztelést, és eredendően törékeny és nehezen karbantartható tesztekhez vezet. Ezenkívül a tesztesetek verziófelügyeleti rendszeren kívüli tárolása szükségtelen bonyolultságot okoz
• Az időmegtakarítás érdekében az automatizálási tesztterv sokszor rosszul van megtervezve vagy nem tervezett, ami a teszt sikertelenségét eredményezi
• A teszt-beállítási és lebontási eljárások általában kimaradnak a tesztautomatizálás során, míg a kézi tesztelés, a tesztbeállítás és a lebontási eljárások zökkenőmentesen hangzanak
• A termelékenységi mutatók, mint például a naponta létrehozott vagy végrehajtott tesztesetek száma, rettenetesen félrevezetőek lehetnek, és jelentős befektetéshez vezethetnek haszontalan tesztek futtatásához.
• Az agilis automatizálási csapat tagjainak hatékony tanácsadóknak kell lenniük: megközelíthetőnek, együttműködőnek és találékonynak, különben ez a rendszer gyorsan meghibásodik.
• Az automatizálás olyan tesztelési megoldásokat javasolhat és szállíthat, amelyek túl sok folyamatos karbantartást igényelnek a biztosított értékhez képest
• Előfordulhat, hogy az automatizált tesztelésből hiányzik a szakértelem a hatékony megoldások kidolgozásához és szállításához
• Az automatizált tesztelés olyan sikeres lehet, hogy kifogynak a fontos megoldandó problémákból, és így lényegtelen problémák felé fordulnak.

Következtetés

A szoftvertesztelés agilis módszere magában foglalja a lehető legkorábbi tesztelést szoftverfejlesztés életciklusa. Amint elérhetővé válik, magas szintű vásárlói részvételt és tesztelési kódot igényel. A kódnak elég stabilnak kell lennie ahhoz, hogy elvigye a rendszerteszthez. Kiterjedt regressziós teszteléssel lehet megbizonyosodni arról, hogy a hibákat kijavították és tesztelték. Főleg a csapatok közötti kommunikáció teszi sikeressé az agilis modelltesztelést!!!