Agilis tesztautomatizálási keretrendszer
Thomas Hamilton
⚡ Okos összefoglaló
Az agilis tesztautomatizálás automatizált ellenőrzéseket alkalmaz rövid sprinteken belül, ahol a követelmények hetente változnak, és egy stabil vízesés modellre felépített csomag gyorsan karbantartási teherré válik, ahelyett, hogy biztonsági hálót biztosítana.
Agilis automatizálási tesztelés
Agilis automatizálási tesztelés a tesztautomatizálás alkalmazásának gyakorlata egy agilis szállítási folyamaton belül. Célja, hogy a szoftverfejlesztést hatékonyabbá és eredményesebbé tegye, miközben védi a minőséget, és szabályozza a kiadáshoz felhasznált időt és erőforrásokat. Mivel a teszteket a funkciókkal végzett munkával párhuzamosan írják, a gyakorlat nagymértékben függ a fejlesztők és a tesztelők közötti koordinációtól.
Amióta az agilis módszertan elhatározta, hogy megszünteti a vízesésmodell fáradságos valóságát, hatása érezhető volt automatizálási tesztelés is. A két tudományágat tudatosan kell kombinálni:
.jpg)
Automatizálás vízesésben vs. automatizálás agilisan
Egy hagyományos szoftvertesztelési életciklusban az automatizált tesztelés akkor válik megvalósíthatóvá, amikor az alkalmazás stabil és a követelmények rendezettekFeltételezi a jelentős mennyiségű időt, magasan képzett automatizálási szakemberek és jelentős beállítási költség. Az alapvető cél a költségek hosszú távú csökkentése és annak megerősítése, hogy a meglévő tesztesetek körül nem keletkeztek új hibák.
Az automatizált tesztelés természeténél fogva nem feltáró jellegű, mivel fő szerepe az időmegtakarítás és a költségek csökkentése. Nem arra tervezték, hogy új és innovatív hibákat tárjon fel. Az automatizált tesztelés többnyire olyan viselkedést erősít meg, amely már létezik.
A két környezet ezért nagyon eltérő követelményeket támaszt a tesztkészlettel szemben:
| Tényező | Automatizálás vízesésben | Automatizálás agilisan |
|---|---|---|
| Alkalmazás állapota | Stabil és jóváhagyott a szkriptelés indítása előtt | Minden sprintben változtatunk, gyakran szkriptelés közben is |
| Rendelkezésre álló idő | Egy dedikált automatizálási fázis | Bármi, ami belefér egy egy-négy hetes sprintbe |
| Ki szkriptek | Egy külön automatizálási szakemberekből álló csapat | A kivitelező csapat, a tesztelők és a fejlesztők együtt |
| Elsődleges cél | Hosszú távú költségcsökkentés egy nagyméretű regressziós csomagban | Gyors visszajelzés az újonnan elkészült növekményről |
| Karbantartási kockázat | Alacsony, mert a követelmények lassan változnak | Magas, mert a követelmények folyamatosan változnak |
Hogyan automatizáljunk agilis módszertannal?
Saját definíciója szerint az agilis módszertan elhagyja a fárasztó dokumentációt, így az új ötletek gyorsan megvalósíthatók és az emberek szabadon interakcióba léphetnek egymással. A papírmunkával szemben a felfedező munkát részesíti előnyben:
Valódi ellentmondás feszül az agilis módszertan és az automatizált tesztelés alapvető filozófiája között. Az agilis csapatok ezt úgy oldják meg, hogy szűkítik az automatizált tevékenységek körét ahelyett, hogy kevesebbet automatizálnának: az ellenőrzéseket ugyanabban a sprintben írják meg, mint a funkciót, lejjebb viszik az egység és az API szintjére, ahol a legolcsóbb fenntartani őket, és minden builden lefutnak.
Az agilis tesztautomatizálás alapvető pontjai
Mielőtt a sprint kapacitását automatizálásra bíznánk, mérlegeljük azokat a szempontokat, amelyek eldöntik, hogy egy szkript egyáltalán befejezhető-e:
- Tervezési és kódolási idő: Minden szkriptet meg kell tervezni, kódolni és ellenőrizni, akárcsak a produkciós kódot.
- Validáció tesztadatokkal: A kész szkriptet a meglévő tesztadatokkal kell validálni, mielőtt bárki megbízhatna benne.
- A teszt célja: A funkcionális és regressziós tesztek eltérő karbantartási költségekkel és eltarthatósági idővel járnak.
- Sprint hossz: Egy sprint egy-négy hétig tart, leggyakrabban kettőig, ami ritkán hagy teret nagy szkriptelési munkának.
A második tényező a követelményváltozás. Az agilis módszertan definíció szerint egy olyan technika, amely az ügyfél által vezérelt változásokra reagál, így a fejlesztés során gyakran alkalmazkodik.
Az automatizált tesztelés ezzel szemben stabil követelmények esetén a leghasznosabb. Nem igazán alkalmas az agilis módszertan állandó változására, ezért az automatizálandó dolgok kiválasztása nagyobb súllyal bír, mint az automatizált mennyiség.
Agilis automatizálási eszközök
A releváns kiválasztás automatizálási eszköz egy másik fontos tényező az automatizált tesztelés agilis módszertanon belüli alkalmazásában. A licencelt automatizálási eszközök például szigorú biztonsági hozzáférési kritériumokat írnak elő a különböző típusú és szintű felhasználókra, ami korlátozza, hogy ki férhet hozzá az adott tesztelési automatizálási keretrendszerhez tartozó erőforrásokhoz.
Az agilis módszertan ezzel szemben a nyílt együttműködést és a csapattagok közötti nyitott interakciót hangsúlyozza. A korlátozó hozzáférési szabályzatok e kohézió ellen dolgoznak, és olyan eredményeket hozhatnak, amelyek sem nem hasznosak, sem nem segítik elő a projekt sikerét.
A prioritás az, hogy minőségi automatizálási szkripteket szállítsunk az agilis folyamatok által megengedett időn belül. Gondosan válasszuk ki a teszteseteket, hogy a kapott szkriptek később újra felhasználhatók legyenek, és a megadott időn belül elkészüljenek.
Még egy agilis környezetben is le kell fedni bizonyos teszteket – különösen a regressziós teszteket. A következő szakasz azokat a helyzeteket vizsgálja, amelyekbe az automatizált tesztelés beleillik, és hogy ezek hogyan illeszkednek az agilis teszteléshez.
Automatizálási tesztelés Concepts Amikor agilis módszertanra alkalmazzák
Az alábbi táblázat bemutatja a tesztek automatizálását indokoló hét klasszikus feltételt, és mindegyikre megadja az agilis választ. Ezek közül csak három fordítható le egyértelműen agilis sprintté, és mindhárom regresszió alakú:
| # | Automatizált tesztelési koncepció | Agilis módszertan válasz |
|---|---|---|
| 1 | A tesztet gyakran meg kell ismételni. | Itt jön képbe a regressziós tesztelés koncepciója. |
| 2 | A teszt munkafolyamata és validációja az idő múlásával lassan fejlődik és változik. | Nem hasznos agilis teszteléshez, mivel az agilis tesztelés a követelmények gyakori változását jelenti. |
| 3 | A teszt egy üzleti folyamatot vagy munkafolyamatot validál, nem pedig a megjelenést és érzetet, a színt vagy a táblázat elrendezését. | Ez a forgatókönyv manuális teszteléssel kapcsolatosnak tekinthető. |
| 4 | A teszt eredményeit egy szabályozó szerv számára állítja elő, amely előírja, hogy ezeket az eredményeket elektronikusan rögzítsék és archiválják a megfelelőség hivatalos bizonyítékaként. | Nem alkalmas agilis módszertanhoz, mivel a kimerítő dokumentáció nem része az agilis módszertannak. |
| 5 | A teszt nagyon ismétlődő, vagy sok olyan lépésből áll, amelyeket minden alkalommal pontosan ugyanúgy kell végrehajtani, ahol el kell kerülni a kézi tesztelő fáradását. | Nem alkalmas agilis módszertanhoz. |
| 6 | A teszt sikeres vagy sikertelen eredménye viszonylag könnyen meghatározható és rögzíthető a kiválasztott automatizálási eszközzel. | Alkalmas az agilis tesztelés során végzett regressziós tesztekhez, amelyek ismétlődő és munkaigényes képességeket igényelnek. |
| 7 | A tesztnek jelentős mennyiségű adatot kell betáplálnia az alkalmazásba. | Regressziós tesztelésként is beépíthető. |
