Agilní testování: Metodologie a životní cyklus
⚡ Chytré shrnutí
Agilní testování aplikuje principy agilního vývoje softwaru na zajištění kvality. Testování začíná první den, probíhá nepřetržitě paralelně s vývojem a je organizováno do fází životního cyklu, kvadrantů a strategií, které udržují zpětnovazební smyčky krátké a dodávky spolehlivé.

Co je agilní testování?
Agilní testování je testovací postup, který se řídí pravidly a principy agilního vývoje softwaru. Na rozdíl od metody Waterfall začíná agilní testování na začátku projektu a probíhá průběžně spolu s vývojem. Není sekvenční – provádí se až po fázi kódování – ale je začleněno do každé iterace, takže zpětná vazba se k týmu dostane v okamžiku, kdy se objeví chyby.
Principy agilního testování
Základní principy agilního testování jsou:
- Funkční software je primárním měřítkem pokroku.
- Nejlepších výsledků dosahují samoorganizující se týmy.
- Dodávání hodnotného softwaru včas a nepřetržitě je nejvyšší prioritou.
- Vývojáři a testeři denně spolupracují na celém projektu.
- Agilitu zvyšuje neustálé technické zlepšování a dobrý design.
- Průběžná zpětná vazba zajišťuje, že konečný produkt splňuje obchodní očekávání.
- Testování probíhá během implementace, což zkracuje celkovou dobu vývoje.
- Testovací proces si udržuje konzistentní a udržitelné tempo.
- Týmy si dělají pauzy, aby se zamyslely a pravidelně se přizpůsobovaly, aby byly efektivnější.
- Nejlepší architektury, požadavky a návrhy vznikají v samoorganizujících se týmech.
- Osobní rozhovor je nejefektivnější a nejúčinnější formou komunikace v rámci týmu.
Tyto principy, aplikované společně, zvyšují produktivitu softwaru a zkracují cestu od nápadu k funkční funkci.
Životní cyklus agilního testování
Životní cyklus agilního testování se skládá z pěti fází, jak je znázorněno níže.
Fáze jsou:
- Fáze 1: Posouzení dopadů. Shromážděte vstupy od zainteresovaných stran a uživatelů. Tomu se také říká fáze zpětné vazby, protože pomáhá testovacím inženýrům stanovit cíle pro další životní cyklus.
- Fáze 2: Agilní plánování testování. Všechny zúčastněné strany se scházejí, aby naplánovaly harmonogram testování, rozsah a výstupy.
- Fáze 3: Připravenost k vydání. Revzobrazit implementované funkce a rozhodnout se, které jsou připraveny k okamžitému spuštění a které je třeba vrátit do vývoje.
- Fáze 4: Denní Scrums. Ranní schůzka vestoje, kde tým probere stav testování a stanoví si cíle na daný den.
- Fáze 5: Test agility Revvidět. Týdenní schůzky se zainteresovanými stranami za účelem vyhodnocení pokroku oproti cílům a úpravy strategie.
Agilní testovací plán
An agilní testovací plán popisuje typy testování prováděných v iteraci, potřebná data a infrastrukturu, testovací prostředía výsledky testů. Na rozdíl od vodopádového modelu se agilní testovací plán píše a aktualizuje pro každé vydání. Typický plán zahrnuje:
- Rozsah testování.
- Probíhá testování nové funkcionality.
- Úroveň nebo typ testování založený na složitosti funkcí.
- Zátěžové a výkonnostní testování.
- Úvahy o infrastruktuře.
- Plán rizik a jejich zmírňování.
- Zajišťování zdrojů.
- Výstupy a milníky.
Agilní testovací strategie
Životní cyklus agilního testování zahrnuje čtyři strategické fáze.
iterace 0
Během první fáze provádíte úvodní nastavení. Patří mezi ně identifikace lidí pro testování, instalace testovacích nástrojů a plánování zdrojů, jako je například laboratoř pro testování použitelnosti. Cíle iterace 0 jsou:
- Vytvořte obchodní případ pro projekt.
- Definujte okrajové podmínky a rozsah projektu.
- Nastíněte klíčové požadavky a případy užití, které budou vést k kompromisům v oblasti designu.
- Popište jednu nebo více kandidátských architektur.
- Identifikujte rizika.
- Odhadněte náklady a připravte předběžný plán projektu.
Stavební iterace
Druhou fází agilního testování jsou konstrukční iterace, během kterých probíhá většina testování. Tato fáze je sadou iterací, které postupně budují řešení. V rámci každé iterace tým aplikuje hybrid postupů z XP, Scrumu, agilního modelování a agilních dat.
Týmy se řídí postupem prioritizace požadavků: s každou iterací vybírají nejdůležitější položky z nevyřízených položek a implementují je. Iterace konstrukčních testů se dělí na dvě doplňkové fáze testování:
- Potvrzující testování ověřuje, zda systém splňuje záměr zainteresovaných stran. Provádí ho samotný tým.
- Investigativní testování Hledá problémy, které konfirmační testování mohlo přehlédnout. Testeři upozorňují na potenciální problémy jako na případy chyb. Investigativní testování zahrnuje integrační, zátěžové a stresové testování a bezpečnostní testování.
Konfirmační testování má dva další aspekty – vývojářské testování a agilní akceptační testování — a obojí je automatizované, aby umožňovalo průběžné regresní testování po celou dobu životního cyklu. Konfirmační testování je agilní ekvivalent testování podle specifikace.
Agilní akceptační testování kombinuje tradiční funkční a akceptační testování, protože je provádí vývojový tým a zúčastněné strany společně. Vývojářské testování kombinuje tradiční jednotkové testování s testováním integrace služeb a ověřuje jak kód aplikace, tak schéma databáze.
Fáze uvolnění, ukončení hry nebo přechodová fáze
Cílem fáze vydání je úspěšné nasazení systému do produkčního prostředí. Mezi aktivity patří školení koncových uživatelů, podpůrného personálu a provozních týmů, marketing vydání produktu, nácvik zálohování a obnovy a finalizace systémové a uživatelské dokumentace.
Závěrečná fáze agilního testování zahrnuje kompletní testování systému a akceptační testování. Aby byl produkt dokončen bez překážek, musí být během konstrukčních iterací důkladně testován. Během závěrečné fáze se testeři zaměřují na řešení chyb, které se objevily dříve v cyklu.
Výroba
Po fázi vydání se produkt přesune do produkce, kde je monitorován jeho provoz a veškeré problémy jsou zohledňovány v dalším plánovacím cyklu.
Agilní testovací kvadranty
Agilní testovací kvadranty rozdělují celý proces do čtyř oblastí a pomáhají týmům pochopit, jak se agilní testování provádí.
Agilní kvadrant I
Kvadrant I se zaměřuje na kvalitu interního kódu pomocí technologicky řízených testů, které podporují tým:
- Jednotkové testy.
- Testy komponent.
Agilní kvadrant II
Kvadrant II obsahuje testy zaměřené na business, které podporují tým a zaměřují se na požadavky. Typická práce v tomto kvadrantu zahrnuje:
- Testovací příklady možných scénářů a pracovních postupů.
- Testování artefaktů uživatelské zkušenosti, jako jsou prototypy.
- Párové testování.
Agilní kvadrant III
Kvadrant III poskytuje zpětnou vazbu do kvadrantu I a II. Zde uvedené testovací případy často tvoří základ pro automatizaci a opakované iterační kontroly budují důvěru v produkt. Typická práce zahrnuje:
- Testování použitelnosti.
- Průzkumné testování.
- Párové testování se zákazníky.
- Kolaborativní testování.
- Uživatelské akceptační testování.
Agilní kvadrant IV
Kvadrant IV se zaměřuje na nefunkční požadavky, jako je výkon, bezpečnost a stabilita. Tento kvadrant zajišťuje, že aplikace poskytuje očekávané nefunkční vlastnosti. Typická práce zahrnuje:
- Nefunkční testy, jako jsou zátěžové a výkonnostní testy.
- Bezpečnostní testování zahrnující autentizaci a pokusy o vniknutí.
- Testování infrastruktury.
- Testování migrace dat.
- Testování škálovatelnosti.
- Zátěžové testování.
Problémy s QA při agilním vývoji softwaru
Agilní dodávání přináší skutečné výhody, ale také vytváří nové výzvy pro týmy QA:
- Dokumentace má nižší prioritu, takže se zvyšuje riziko chyby a tlak se přesouvá na tým QA.
- Nové funkce přicházejí rychle, takže testerům zbývá méně času na ověření nejnovějších funkcí s ohledem na požadavky a obchodní záměr.
- Testeři často hrají roli polovývojářů.
- Cykly provádění testů jsou vysoce komprimované.
- Na přípravu testovacího plánu je k dispozici omezený čas.
- Rozpočty na regresní testování se stávají napjatými.
- Testeři se z pozice strážců kvality stávají partnery v oblasti kvality.
- Časté změny požadavků jsou neodmyslitelnou součástí agilních metod, což je jedna z největších výzev v oblasti QA.
Riziko automatizace v agilním procesu
Automatizace je v agilním přístupu nezbytná, ale s sebou nese rizika, která musí týmy aktivně řídit:
- Automatizované testy uživatelského rozhraní nabízejí vysokou spolehlivost, ale jsou pomalé, nestabilní a drahé na údržbu. Zvýšení produktivity se projeví pouze tehdy, když testeři vědí, jak navrhovat dobré testy.
- Nespolehlivé testy jsou velkým problémem. Oprava křehkých testů a falešně pozitivních výsledků musí zůstat nejvyšší prioritou.
- Automatizované testy, které se spouští ručně, a nikoli přes CI, riskují, že se tiše posunou a budou produkovat zastaralé výsledky.
- Automatizace nenahrazuje manuální průzkumné testování. Pro dosažení očekávané kvality je zapotřebí kombinace typů a úrovní testování.
- Nástroje pro zachycení a přehrávání podporují skripty řízené uživatelským rozhraním, které jsou křehké a obtížně se udržují. Testy uložené mimo systém správy verzí přidávají zbytečnou složitost.
- Špatně naplánovaná automatizace, provedená za účelem „úspory času“, často zcela selže.
- Postupy nastavení a demontáže testů se při automatizaci snadno přehlédnou, zatímco manuální testování je zvládá přirozeně.
- Metriky produktivity, jako je „počet testovacích případů za den“, mohou týmy zavést do omylu a svést k provádění zbytečných testů.
- Tým automatizace musí být efektivními konzultanty – přístupnými, spolupracujícími a vynalézavými – jinak celá praxe selže.
- Řešení, která vyžadují náročnou průběžnou údržbu, mohou převážit hodnotu, kterou poskytují.
- Automatizované testy mohou postrádat odborné znalosti potřebné k poskytování efektivních řešení.
- Úspěšná automatizace může ztratit důležité problémy k řešení a proces se přesune k méně hodnotné práci.
Nejlepší postupy pro efektivní agilní testování
Následující postupy udržují agilní testování rychlé, spolehlivé a cenné pro tým:
- Shift vlevo, odjet: začněte testovat v době požadavků, nikoli na konci iterace.
- Spárování s vývojáři: společně prozkoumat kritéria přijetí, aby vady byly navrženy tak, aby nebyly zakódovány.
- Automatizace vrstev: vybudovat zdravou pyramidu jednotkových, servisních a UI testů.
- Udržujte testy nezávislé: izolujte každý test tak, aby selhání ukazovala na jednu hlavní příčinu.
- Track nespolehlivým testům: karanténu a neprodleně opravte nespolehlivé testy, abyste zabránili narušení důvěry v sadu.
- Používejte analytiku s podporou umělé inteligence: Nechte nástroje označit ovlivněné testy, seskupit selhání a po každém sloučení navrhnout stabilní lokátory.



