Co je agilní testování?
AGILE TESTING je testovací postup, který se řídí pravidly a principy agilního vývoje softwaru. Na rozdíl od metody Waterfall může agilní testování začít na začátku projektu s nepřetržitou integrací mezi vývojem a testováním. Metodika agilního testování není postupná (v tom smyslu, že se provádí až po fázi kódování), ale kontinuální.
V tomto článku budeme diskutovat
- Agilní testovací plán.
- Agilní strategie testování.
- Agilní testovací kvadrant.
- QA výzvy s agilním vývojem softwaru.
- Riziko automatizace v agilním procesu.
Agilní testovací plán
Agilní testovací plán zahrnuje typy testování prováděné v této iteraci, jako jsou požadavky na testovací data, infrastruktura, testovací prostředí a výsledky testů. Na rozdíl od modelu vodopádu je v agilním modelu testovací plán napsán a aktualizován pro každé vydání. Typické plány testů v agilním režimu zahrnují
- Rozsah testování
- Nové funkce, které jsou testovány
- Úroveň nebo typy testování na základě složitosti funkcí
- Testování zátěže a výkonu
- Zohlednění infrastruktury
- Plán zmírnění nebo rizik
- Zdroje
- Výsledky a milníky
Agilní strategie testování
Agilní testování životního cyklu trvá ve čtyřech fázích
(a) Iterace 0
Během první fáze nebo iterace 0 provádíte úkoly počátečního nastavení. Zahrnuje identifikaci lidí pro testování, instalaci testovacích nástrojů, plánování zdrojů (laboratoř testování použitelnosti) atd. Následující kroky jsou nastaveny tak, aby bylo dosaženo v Iteraci 0
a) Vytvoření obchodního případu pro projekt
b) Stanovte okrajové podmínky a rozsah projektu
c) Popište klíčové požadavky a případy použití, které povedou k kompromisům designu
d) Nástin jedné nebo více kandidátských architektur
e) Identifikace rizika
f) Odhad nákladů a příprava předběžného projektu
(b) Iterace stavby
Druhou fází metodiky agilního testování je Construction Iterations, většina testování probíhá během této fáze. Tato fáze je pozorována jako sada iterací k vytvoření přírůstku řešení. Aby to bylo možné, v rámci každé iterace tým implementuje hybrid postupů z XP, Scrum, agilního modelování a agilních dat atd.
V konstrukční iteraci se agilní tým řídí prioritizovanou praxí požadavků: S každou iterací vezme nejdůležitější požadavky zbývající ze zásobníku pracovních položek a implementuje je.
Konstrukce iterace je rozdělena do dvou, potvrzovací testování a vyšetřovací testování. Potvrzovací testování se soustředí na ověření, že systém splňuje záměr zúčastněných stran, jak je týmu dosud popsáno, a je prováděn týmem. Zatímco vyšetřovací testování detekuje problém, který konfirmační tým přeskočil nebo ignoroval. V Investigativním testování určuje tester potenciální problémy ve formě příběhů o závadách. Investigativní testování se zabývá běžnými problémy, jako je testování integrace, zátěžové / zátěžové testování a testování zabezpečení.
Opět pro potvrzovací testování existují dva aspekty testování vývojářů a agilní akceptační testování . Oba jsou automatizovány, aby umožňovaly průběžné regresní testování během celého životního cyklu. Potvrzovací testování je agilní ekvivalent testování podle specifikace.
Agilní akceptační testování je kombinací tradičního funkčního testování a tradičního akceptačního testování jako vývojového týmu a zúčastněné strany to dělají společně. Zatímco testování vývojářů je směsicí tradičního testování jednotek a tradičního testování integrace služeb. Testování vývojáře ověřuje jak kód aplikace, tak schéma databáze.
(c) Vydat konec hry nebo přechodovou fázi
Cílem hry „Release, End Game“ je úspěšně nasadit váš systém do produkce. Mezi činnosti, které v této fázi patří, patří školení koncových uživatelů, podpůrných a provozních pracovníků. Zahrnuje také marketing vydání produktu, zálohování a obnovení, finalizace systémové a uživatelské dokumentace.
Konečná fáze testování agilní metodiky zahrnuje testování celého systému a akceptační testování. Aby bylo možné dokončit finální fázi testování bez jakýchkoli překážek, měli byste produkt důkladně otestovat, když je ve stavebních iteracích. Během závěrečné hry budou testeři pracovat na jejích vadných příbězích.
d) Výroba
Po fázi vydání se produkt přesune do fáze výroby.
Agilní testování kvadrantů
Agilní testovací kvadranty rozdělují celý proces do čtyř kvadrantů a pomáhají pochopit, jak se agilní testování provádí.
a) Agilní kvadrant I - kvalita interního kódu je hlavním zaměřením v tomto kvadrantu a skládá se z testovacích případů, které jsou založeny na technologii a jsou implementovány na podporu týmu, zahrnuje
1. Testy jednotek
2. Zkoušky součástí
b) Agile Quadrant II - Obsahuje testovací případy, které jsou řízeny obchodem a jsou implementovány na podporu týmu. Tento kvadrant se zaměřuje na požadavky. Druh testu prováděného v této fázi je
1. Testování příkladů možných scénářů a pracovních postupů
2. Testování uživatelských zkušeností, jako jsou prototypy
3. Párové testování
c) Agilní kvadrant III - Tento kvadrant poskytuje zpětnou vazbu kvadrantům jeden a dva. Testovací případy lze použít jako základ k provedení automatizačního testování. V tomto kvadrantu se provádí mnoho kol iteračních revizí, které budují důvěru v produkt. Druh testování provedeného v tomto kvadrantu je
1. Testování použitelnosti
2. Průzkumné testování
3. Párové testování se zákazníky
4. Kolaborativní testování
5. Testování přijetí uživatelem
d) Agilní kvadrant IV - Tento kvadrant se soustřeďuje na nefunkční požadavky, jako je výkon, bezpečnost, stabilita atd. S pomocí tohoto kvadrantu je aplikace vytvořena tak, aby poskytovala nefunkční vlastnosti a očekávanou hodnotu.
1. Nefunkční testy, jako jsou zátěžové a výkonnostní testy
2. Testování bezpečnosti s ohledem na autentizaci a hacking
3. Testování infrastruktury
4. Testování migrace dat
5. Testování škálovatelnosti
6. Zátěžové testování
QA výzvy s agilním vývojem softwaru
a) Šance na chyby jsou agilnější, protože dokumentace má menší prioritu a nakonec vyvíjí větší tlak na tým QA
b) Rychle se zavádějí nové funkce, což zkracuje čas, který mají testovací týmy k dispozici, aby zjistily, zda jsou nejnovější funkce v souladu s požadavkem, a skutečně řeší obchodní obleky
c) Od testerů se často vyžaduje, aby hráli v roli semi-vývojáře
d) Cykly provádění testů jsou vysoce komprimované
e) Velmi málo času na přípravu plánu zkoušek
f) Pro regresní testování budou mít minimální načasování
g) Změna jejich role z pozice strážce kvality na partnera v kvalitě
h) Změny a aktualizace požadavků jsou inherentní agilní metodě, která se pro QA stává největší výzvou
Riziko automatizace v agilním procesu
- Automatizované uživatelské rozhraní poskytuje vysokou úroveň spolehlivosti, ale jejich provádění je pomalé, křehké při údržbě a jejich sestavování je nákladné. Automatizace nemusí výrazně zlepšit produktivitu testů, pokud testeři nevědí, jak testovat
- Nespolehlivé testy jsou hlavním problémem automatizovaného testování. Oprava neúspěšných testů a řešení problémů souvisejících s křehkými testy by měla být nejvyšší prioritou, aby se zabránilo falešným pozitivům
- Pokud se automatický test spouští ručně, nikoli prostřednictvím CI (kontinuální integrace), existuje riziko, že nejsou pravidelně spuštěny, a proto mohou způsobit selhání testů.
- Automatizované testy nenahrazují průzkumné ruční testování. K získání očekávané kvality produktu je nutná kombinace typů a úrovní testování
- Mnoho komerčně dostupných automatizačních nástrojů poskytuje jednoduché funkce, jako je automatizace snímání a přehrávání manuálních testovacích případů. Takový nástroj podporuje testování prostřednictvím uživatelského rozhraní a vede k inherentně křehkým a obtížně udržovatelným testům. Ukládání testovacích případů mimo systém správy verzí také vytváří zbytečnou složitost
- Kvůli úspoře času je plán automatizačního testu mnohokrát špatně naplánovaný nebo neplánovaný, což má za následek selhání testu
- Postupy nastavení a zbourání testu se obvykle během automatizace testu zmeškají, zatímco Provádění ručního testování zní a postupy zbourání testu zní bezproblémově
- Metriky produktivity, jako je řada testovacích případů vytvořených nebo provedených denně, mohou být strašně zavádějící a mohly by vést k velké investici do provádění zbytečných testů
- Členové agilního automatizačního týmu musí být efektivní konzultanti: přístupní, kooperativní a vynalézaví, jinak tento systém rychle selže
- Automatizace může navrhnout a dodat testovací řešení, která vyžadují příliš mnoho průběžné údržby ve srovnání s poskytovanou hodnotou
- Automatizovanému testování může postrádat odborné znalosti, aby bylo možné navrhnout a dodat efektivní řešení
- Automatizované testování může být tak úspěšné, že jim dojdou důležité problémy, které je třeba vyřešit, a tak se obrátit k nedůležitým problémům.
Závěr
Agilní metodologie testování softwaru zahrnuje testování co nejdříve v celém životním cyklu vývoje softwaru. Vyžaduje vysoké zapojení zákazníků a testovací kód, jakmile bude k dispozici. Kód by měl být dostatečně stabilní, aby jej bylo možné použít k testování systému. Lze provést rozsáhlé regresní testování, abyste se ujistili, že chyby jsou opraveny a testovány. Díky komunikaci mezi týmy je úspěch agilního modelu úspěšný hlavně !!!