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é.

  • 🔁 Neustále testujte: Začleňte testování do každé iterace, aby byly vady zachyceny v okamžiku napsání kódu, nikoli na konci vydání.
  • 🧭 Sledujte životní cyklus: Projděte si procesy hodnocení dopadů, plánování, připravenosti na vydání, denních scrumů a agility Revpohled na to, jak zůstat v souladu s týmem.
  • 🗂️ Použijte čtyři kvadranty: Zahrnuje jednotkové a komponentní testy, scénáře řízené podnikáním, průzkumnou zpětnou vazbu a nefunkční kontroly.
  • 📜 Naplánujte každou iteraci: Aktualizujte agilní testovací plán v každém sprintu s rozsahem, typy testování, riziky a výstupy.
  • 🤖 Automatizujte s opatrností: Spojte sady regresních algoritmů s podporou umělé inteligence s průzkumným a konfirmačním testováním, abyste udrželi vysokou produktivitu testů bez křehkých skriptů.

Životní cyklus agilního testování

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.

Životní cyklus agilního testování

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.

Agilní testovací strategie

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í testovací kvadranty

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.

Nejčastější dotazy

Vodopádové testování probíhá až po dokončení kódování, zatímco agilní testování probíhá průběžně spolu s vývojem. Agilní metody zkracují smyčky zpětné vazby, zapojují testery do týmu a dodávají funkční software v malých, častých krocích.

Kvalita je sdílenou odpovědností. Vyhrazení testeři navrhují a provádějí testy, vývojáři automatizují jednotkové a servisní testy a vlastníci produktů ověřují kritéria přijetí. Za výsledek každého vydání nese odpovědnost celý tým.

Regresní testování chrání stávající funkce, protože v každé iteraci se objevují nové. Automatizované regresní sady se spouštějí při každém commitu, zatímco průzkumné regresní sezení pokrývají scénáře, které skripty nedokážou snadno zachytit.

Kritéria přijetí se píší během úpravy backlogu a převádějí se do automatizovaných akceptačních testů. Zainteresované strany a testeři je na konci každé iterace společně spustí, aby se ověřilo, že je příběh skutečně hotový.

Mezi užitečné metriky patří míra uniklých vad, procento úspěšnosti automatizovaných testů, míra nestabilních testů, průměrná doba detekce a doba cyklu na příběh. Vyhněte se zbytečným metrikám, jako jsou počty nezpracovaných testovacích případů.

Agilní týmy obvykle testují v rámci jedno- až čtyřtýdenních sprintů s průběžným testováním v denním režimu. Automatizovaná regrese by měla být dokončena během několika minut, aby se zpětná vazba dostala k vývojářům, dokud je kontext ještě čerstvý.

Nástroje umělé inteligence vybírají ovlivněné testy po změně kódu, opravují poškozené lokátory, seskupují podobné chyby a navrhují chybějící scénáře. Zkracují dobu běhu regrese a pomáhají testerům soustředit se na práci vyžadující úsudek.

Ano. Asistenti umělé inteligence převádějí uživatelské příběhy a kritéria přijetí do návrhů testovacích případů, doplněných vzorovými daty a hraničními případy. Lidští recenzenti stále potvrzují obchodní rizika a prioritizují scénáře k provedení.

Shrňte tento příspěvek takto: