Mi az az agilis tesztelés?
Az AGILE TESTING olyan tesztelési gyakorlat, amely követi az agilis szoftverfejlesztés szabályait és elveit. A Vízesés módszerrel ellentétben az agilis tesztelés a projekt kezdetén elkezdődhet, folyamatos integrációval a fejlesztés és a tesztelés között. Az agilis tesztelési módszertan nem szekvenciális (abban az értelemben, hogy csak a kódolási fázis után hajtódik végre), hanem folyamatos.
Ebben a cikkben megvitatjuk
- Agilis tesztterv.
- Agilis tesztelési stratégiák.
- Az agilis tesztelési negyed.
- Minőségbiztosítási kihívások az agilis szoftverfejlesztéssel.
- Az automatizálás kockázata az agilis folyamatokban.
Agilis tesztterv
Az agilis tesztterv az adott iterációban elvégzett teszteket tartalmazza, például a vizsgálati adatok követelményeit, az infrastruktúrát, a tesztkörnyezeteket és a teszt eredményeit. A vízesés modellel ellentétben, egy mozgékony modellben egy teszttervet írnak és frissítenek minden kiadáshoz. Az agilis tipikus teszttervek tartalmazzák
- 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és és teljesítmény tesztelése
- Infrastruktúra megfontolása
- Enyhítési vagy kockázati terv
- Újrafeldolgozás
- Teljesítések és mérföldkövek
Agilis tesztelési stratégiák
Az agilis tesztelés életciklusa négy szakaszon átível
a) 0-s ismétlés
Az első szakasz vagy a 0-as iteráció során elvégzi a kezdeti beállítási feladatokat. Ez magában foglalja az emberek azonosítását a teszteléshez, a tesztelő eszközök telepítését, az erőforrások ütemezését (használhatósági tesztelő laboratórium) stb.
a) Üzleti eset megalapozása a projekt számára
b) Határozza meg a határfeltételeket és a projekt hatókörét
c) Vázolja fel azokat a legfontosabb követelményeket és felhasználási eseteket, amelyek elősegítik a tervezési kompromisszumokat
d) Vázoljon fel egy vagy több jelölt architektúrát!
e) A kockázat azonosítása
f) Költségbecslés és egy előzetes projekt elkészítése
b) Építési ismétlések
Az agilis tesztelési módszertan második fázisa az Építési Iterációk, a tesztek nagy része ebben a szakaszban 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 az egyes iterációkon belül a csapat az XP, a Scrum, az Agile modellezés és az agilis adatok stb. Gyakorlatok hibridjét valósítja meg.
Az építési iteráció során az agilis csapat követi a prioritásként előírt követelményeket: Az egyes iterációk során felveszik a munkadarab-veremből fennmaradó legfontosabb követelményeket és végrehajtják azokat.
Az építési iterációt két csoportba sorolják: megerősítő és vizsgálati tesztek. A megerősítő teszt annak ellenőrzésére összpontosít , hogy a rendszer teljesíti-e az érdekelt felek szándékát, amint azt a csapatnak leírták, és amelyet a csapat hajt végre. Míg a vizsgálati teszt azt a problémát észleli, amelyet a megerősítő csoport 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ó teszt olyan általános kérdésekkel foglalkozik, mint az integrációs tesztelés, a terhelés / stressz tesztelés és a biztonsági teszt.
Ismét a megerősítő teszteléshez két szempont van a fejlesztői tesztelés és az agilis elfogadási teszt . Mindkettő automatizált, hogy lehetővé tegye a folyamatos regressziós tesztet az egész életciklus alatt. A megerősítő vizsgálat a teszt agilis megfelelője a specifikációval.
Az agilis elfogadási teszt a hagyományos funkcionális tesztelés és a hagyományos elfogadási teszt kombinációja, mint a fejlesztői csapat, és az érdekelt felek ezt együtt végzik. Míg a fejlesztői tesztelés a hagyományos egységtesztelés és a hagyományos szolgáltatásintegrációs teszt keveréke. A fejlesztői tesztelés ellenőrzi az alkalmazás kódját és az adatbázis sémáját is.
(c) Engedje el a játék végét vagy az átmeneti fázist
A „Release, End Game” célja a rendszer sikeres telepítése a termelésbe. Ebben a szakaszban a tevékenységek a végfelhasználók, a támogató személyek és az operatív emberek képzését tartalmazzák. Ez magában foglalja a termék kiadásának marketingjét, biztonsági mentését és helyreállítását, a rendszer és a felhasználói dokumentáció véglegesítését.
Az agilis módszertan tesztelésének utolsó szakasza magában foglalja a teljes rendszer tesztelést és az elfogadási tesztet. Annak érdekében, hogy akadálytalanul befejezze az utolsó tesztelési fázist, szigorúbban kell tesztelnie a terméket, amíg építési iterációkban van. A végjáték során a tesztelők dolgozni fognak a hibatörténetein.
d) Termelés
A kiadási szakasz után a termék a gyártási szakaszba kerül.
Az agilis tesztelő kvadránsok
Az agilis tesztelési kvadránsok az egész folyamatot négy kvadránsra választják szét, és segítenek megérteni az agilis tesztelés módját.
a) Agile I negyed - A belső kód minősége a fő hangsúly ebben a negyedben, és olyan tesztesetekből áll, amelyeket technológia vezérel és a csapat támogatására valósítanak meg.
1. Egység tesztek
2. Komponens tesztek
b) Agile Quadrant II - Olyan teszteseteket tartalmaz , amelyek üzleti alapúak és a csapat támogatására lettek megvalósítva . Ez a negyed a követelményekre összpontosít. Az ebben a fázisban végzett vizsgálat fajtája:
1. A lehetséges forgatókönyvek és munkafolyamatok példáinak tesztelése
2. A felhasználói tapasztalatok, például prototípusok tesztelése
3. Páros tesztelés
c) Agilis III. kvadráns - Ez a negyed visszajelzést ad az első és a második kvadránsnak. A tesztesetek alapul szolgálhatnak az automatizálási tesztek elvégzéséhez. Ebben a negyedben sokféle iterációs felülvizsgálatot végeznek, ami növeli a termék iránti bizalmat. Az a fajta teszt, amelyet ebben a negyedben végeznek
1. Használhatóság tesztelése
2. Feltáró tesztelés
3. Páros tesztelés az ügyfelekkel
4. Együttműködő tesztelés
5. Felhasználói elfogadási teszt
d) IV . Agilis kvadráns - Ez a negyed a nem funkcionális követelményekre összpontosít , mint például a teljesítmény, a biztonság, a stabilitás stb. Ennek a kvadránsnak az alkalmazásával a nem funkcionális tulajdonságokat és a várható értéket nyújtják.
1. Nem funkcionális tesztek, mint például a stressz és a teljesítmény tesztelése
2. Biztonsági tesztek a hitelesítés és a hackelés tekintetében
3. Infrastruktúra tesztelése
4. Adatmigrációs teszt
5. Méretezhetőségi teszt
6. Terhelés tesztelése
Minőségbiztosítási kihívások az agilis szoftverfejlesztéssel
a) A hibalehetőségek inkább mozgékonyak, mivel a dokumentáció kevesebb prioritást élvez, és ezáltal nagyobb nyomás nehezedik a minőségbiztosítási csapatra
b) Az új funkciók gyorsan bevezetésre kerülnek, ami csökkenti a tesztcsoportok számára rendelkezésre á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 ruháknak
c) A tesztelőknek gyakran meg kell adniuk egy fél fejlesztő szerepét
d) A teszt végrehajtási ciklusai erősen tömörítettek
e) Kevesebb idő a tesztterv elkészítésére
f) A regressziós teszthez minimális időzítéssel rendelkeznek
g) Változás szerepükben a minőség kapujává válásból a Minőség partnereivé
h) A követelmények megváltoztatása és frissítése az agilis módszer velejárója, és a QA számára ez jelenti a legnagyobb kihívást
Az automatizálás kockázata az agilis folyamatokban
- Az automatizált felhasználói felület nagyfokú bizalmat biztosít, de végrehajtása lassú, karbantartása törékeny és felépítése költséges. Az automatizálás csak akkor javíthatja jelentősen a teszt termelékenységét, ha a tesztelők tudják, hogyan kell tesztelni
- A megbízhatatlan tesztek komoly problémát jelentenek az automatizált tesztelés során. A hibás tesztek kijavításának és a törékeny tesztekkel kapcsolatos problémák megoldásának elsődleges fontosságúnak kell lennie a hamis pozitív eredmények elkerülése érdekében
- Ha az automatizált tesztet manuálisan kezdeményezik, nem pedig a CI (folyamatos integráció) segítségével, fennáll annak a veszélye, hogy nem rendszeresen futnak, és ezért a tesztek kudarcát okozhatják
- Az automatizált tesztek nem helyettesítik a feltáró kézi teszteket. A termék elvárt minőségének eléréséhez tesztelési típusok és szintek keveréke szükséges
- Számos kereskedelemben kapható automatizálási eszköz egyszerű funkciókat kínál, például a manuális tesztesetek rögzítésének és visszajátszásának automatizálását. Egy 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. Szintén felesleges bonyolultságot okoz a tesztesetek tárolása a verziókezelő rendszeren kívül
- Az időmegtakarítás érdekében az automatizálási tesztterv sokszor rosszul vagy rosszul van megtervezve, ami a teszt kudarcát eredményezi
- A tesztbeállítások és a lebontási eljárások általában elmaradnak a tesztautomatizálás során, míg a manuális tesztelés során a tesztbeállítás és -bontási eljárások zökkenőmentesen hangzanak
- A termelékenységi mutatók, például a naponta létrehozott vagy végrehajtott tesztesetek száma, félelmetesen félrevezetőek lehetnek, és nagy befektetéshez vezethetnek a haszontalan tesztek futtatásához.
- Az agilis automatizálási csapat tagjainak hatékony tanácsadóknak kell lenniük: megközelíthető, együttműködő és találékony, különben ez a rendszer gyorsan meg fog bukni
- Az automatizálás olyan tesztelési megoldásokat javasolhat és szállíthat, amelyek túl sok folyamatos karbantartást igényelnek a megadott értékhez képest
- Az automatizált tesztelésből hiányozhat a szakértelem a hatékony megoldások megtervezéséhez és megvalósításához
- Az automatizált tesztelés annyira sikeres lehet, hogy fontos problémák elfogynak megoldani, és ezáltal lényegtelen problémákhoz fordulnak.
Következtetés
Az agilis módszertan a szoftvertesztelés során magában foglalja a lehető legkorábbi tesztelést a szoftverfejlesztés életciklusában. Magas vevői részvételt és tesztelési kódot igényel, amint elérhetővé válik. A kódnak elég stabilnak kell lennie ahhoz, hogy elvigye a rendszer teszteléséhez. Széleskörű regressziós tesztet lehet végezni a hibák kijavításáról és teszteléséről. Főleg a csapatok közötti kommunikáció eredményes az agilis modelltesztelés terén !!!