Firem a týmů, které přešly na agilní vývoj, stále přibývá. A to je dobře! Agilní vývoj může spoustě firmám pomoci – ale ne každé a také se musí dělat správně. Zajistit kvalitu v agilním prostředí je často velkým oříškem pro mnoho firem. Setkávám se s tím dnes a denně na svých kurzech i konzultacích. A tak jsem se rozhodl, že základní principy objasním v tomto článku. Cílem článku tedy je vysvětlit, co je agilní vývoj, vysvětlit co je agilní testování a jak se provádí. Jak říká Simon Sinek: začneme s proč. 😀

Svět se změnil! Rychlost, s jakou se nám mění technologie i požadavky, nabrala tak na obrátkách, že již není možné plánovat na jeden rok, co se bude vyvíjet. Je potřeba to dělat častěji, třeba každých čtrnáct dní (tzv. Sprint). Agilní vývoj přišel s řešením jak zajistit vývoj, který bude iterativní a inkrementální, a tedy bude řešit problém rychlých změn a také to, že management/byznys neví, co přesně trh nebo zákazník potřebuje. On to často neví ani sám zákazník… 😉 Ale to nevadí, pokud máte možnost po každém Sprintu předvést zákazníkovi, co za nové featury (funkce) dostal, a on si je může rovnou vyzkoušet a zjistit, jestli to je to, co potřebuje. Díky tomu se nevyvíjí naslepo, ale vše je ihned prověřeno v reálném provozu. A jak s tím souvisí agilní testování? Agilní testování je způsob, jakým zajistit kvalitu právě v agilním vývoji. Protože nejčastější formou agilního vývoje je použití SCRUM frameworku. Budeme se dále bavit především o něm, i když většina principů je univerzálních a dají se použít v jakémkoliv agilním vývoji.

Co je agilní vývoj (Scrum)

• Backlog grooming
  • Zde vám PO představí, co zákazník chce, ve formě user storek – ty musí byt dostatečně malé, aby se daly realizovat během 2-4 dní (pro 14-ti denní Sprint). Protože často nejsou, řeší se na tomto mítingu, jak je rozdělit na menší. Dále se dělá effort estimation (většinou formou tzv. Planning Pokeru).
  • Cílem mítingu je tedy mít malé UST (User Story) seřazené v Backlogu (místo, kde jsou všechny požadavky) podle priority.
• Sprint Planning
  • Cílem tohoto mítingu je aby tým naplánoval, co vše se bude v následujícím sprintu dělat, tedy které všechny user story se budou implementovat, testovat a ideálně i releasovat.
  • Postupuje se v backlogu od té nejprioritnější UST dále k méně prioritním, dokud má tým kapacitu, aby UST stihl dokončit.
• Daily scrum (dříve označován jako Stand up)
  • Jakmile je naplánováno, mohou se všichni pustit do práce a každý den se sejdou na Daliy scrumu, který trvá max. 15 min a každý zde odpovídá na 3 otázky: Co jsem dělal včera. Co budu dělat dnes a co mě blokuje. Tohle je signál pro SM, aby zajistil, že překážky budou odstraněny. (pozn: tohle je jeden z možných formátů)
• Sprint Review (dříve označován jako Demo)
  • Jakmile Sprint doběhne (typická délka je 14 dní), svolá se Sprint Review meeting, kde se předvede zákazníkovi, co se udělalo. A on nám na to hned dává externí zpětnou vazbu, jak se mu to líbí a jestli to je to, co potřebuje.
• Retrospektiva
  • Aby se tým mohl zlepšovat, potřebuje také vnitřní zpětnou vazbu. Ta se koná na Retrospektivě. Zde se opět všichni sejdou a v základu odpovídají na 2 otázky: Co se mi na Sprintu líbilo (a chci zachovat) a co se mi naopak nelíbilo (a chci, aby se změnilo, přestalo).

Když už víme, jak agilní vývoj funguje, pojďme se podívat, jak se v něm zajišťuje kvalita, tj. jak v něm testujeme. Základním pravidlem je, že za kvalitu jsou zodpovědní všichni členové týmu a ne jen testeři! Jinak to nebude fungovat. Kvalita je výsledek týmové práce. Testerovým úkolem je vzdělávat tým ohledně zajištění kvality. Nebo např: pomoci s definováním DONE kritérií, posoudit testovatelnost, pomoci s odhady náročnosti testování pro každou UST.

Pojďme se tedy na zajištění kvality podívat detailněji.

Na Groomingu je z pohledu zajištění kvality nutné, aby všichni pochopili, co je podstatou každé user story, tedy k čemu to zákazníkovi bude. Za testery je to velmi důležitý okamžik, protože pokud tester nerozumí požadavku nebo jakou hodnotu nová funcionalita zákazníkovi přináší, těžko pak může ověřit, že tam ta hodnota je. Příklad: Pokud PO představí, že se zákazník chce přihlašovat bez hesla jen s využitím facebook účtu: Musí tester pochopit, že cílem je zřejmě usnadnění přihlašování, a tedy testování bude zahrnovat jak to, že je to technicky možné, tak to, že je to pro zákazníka snadné. Pokud během přihlašování musím navíc vyplňovat další údaje jako přihlašovací jméno nebo dokonce heslo, asi se nejedná o žádné usnadnění pro zákazníka a jako tester na to musím okamžitě upozornit. Pro testera je tedy zásadní se ptát na detaily a zjišťovat, k čemu nová funkcionalita je. Součástí groomingu je také effort estimation (odhad pracnosti). Zde je zásadní, aby odhady dělali i testeři, tj. aby se počítalo i s testováním a ne jen vývojem. Za odhady je odpovědny celý tým a měl by mít na paměti, že testing je součástí vývoje feature.

Při plánování je zásadní naplánovat pro každou user story tásky (aktivity, které vedou ke splnění user story) pro zajištění kvality. Patří mezi ně např. code review, unit testy, integrační testy, funkční testy, také příprava testovacího prostředí a automatizace testů. Tedy aby se počítalo také s testováním a automatizací.

Scrumový tým se organizuje sám, takže jak si kdo rozdělí práci a co bude dělat, je na týmu. Důležité je, aby byly všechny testy realizovány a nezapomnělo se na některou podstatnou část. Tohle je možný příklad, jak to může vypadat: Jakmile je něco implementováno, nechá si vývojář udělat code review druhým vývojářem. Také si vývojář ověří správnou funkčnost svého kódu pomoc Unit Testů. To, že nám komponenty fungují dohromady, zase ověří Integrační testy. Ty můžou mít na starosti vývojáři nebo testeři, záleží na domluvě. Dále pak testeři ověřují novou funkcionalitu ze začátku formou exploratory testů a následně vymyslí test-casy, které budou prověřovat danou funkcionalitu i v budoucnu, tedy zařadí se do Regresní sady. Nezapomínejte na to, že regresní sada v agilním vývoji vzniká průběžně. Žádné uděláme to později až bude čas! Čas nebude nikdy. 🙂 Podobné to je s automatizací testů, ta vzniká také průběžně a je zásadní pro udržení rychlosti celého vývoje. Protože regresní sada vám bude stále narůstat, automatizace je tedy zásadní způsob, jak tento problém vyřešit. Nezapomínejte také na testerskou pyramidu, tedy testujte vždy, co nejníže to jde. To znamená, že prvně verifikujte na úrovni unit testů. Pokud to nejde, tak na úrovni integračních testů, pokud nejde ani tam, tak teprve potom na GUI. Často slýchávám dotaz ale co mají dělat testeři na začátku sprintu, když ještě není nic hotové? Těch věcí které mohou dělat je opravdu hodně. Zmíním jen některé: připravovat automatizační framework, zlepšovat testovací prostředí, připravovat si podklady pro testování, seznamovat se detailněji s funkcionalitou atd.

Každý den probíhá Daily scrum (Stand up), na kterém se tým synchronizuje a testeři vědí, co je hotovo a co mohou začít testovat nebo automatizovat. Také se všichni dozvídají, co jede a co naopak ještě nefunguje. Kde jsou jaké problémy apod. Tester slyší o čem vývojáři povídají, takže má lepší přehled a díky tomu může lépe testovat. Například pokud slyší, že vývojář si není jisty jak je to s napojením aplikace na účetní systém je jasné, že to bude první věc kterou bude zkoušet.

Sprint review (Demo)

Zde se konečně dozvíme, zda požadavky zákazníka byly uspokojeny nebo ne. Z pohledu kvality je zásadní pro testery slyšet a vidět, co zákazník na nové featury říká. Do testingu často chodí empatičtí lidé, kteří slyší úplně jiné věci než třeba vývojáři, a díky tomu mohou lépe pochopit, co zákazník opravdu potřebuje, a pomoci tak týmu vytvářet hodnoty, které zákazníci opravdu potřebují.

Na závěr je třeba si zhodnotit, jak nám celý sprint šel a co se nám daří dělat dobře a co naopak dobře neděláme. Jak bylo řečeno na začátku, není nutné vše dělat hned správně, ono to ani není možné. Důležité je, jestli se tým ve zajištění kvality a dodávání hodnoty zákazníkovi stále zlepšuje. Na tomto mítingu se může řešit například: proč nám unikla kritická chyba k zákazníkovi. Jak to že nestíháme automatizovat, proč máme nestabilní testovací prostředí. Nebo v extrémnějších případech jak to, že automatizaci vůbec nemáme. Cílem je najít řešení, zavést nové opatření, které to, co neděláme dobře, zastaví a naopak to, co dobře děláme, zachová. Příkladem co řešit na retrospektivě je třeba proč nemáme automatizované testy nebo proč na testery spadne testování až poslední den sprintu.

Pojďme se nyní podívat na zásadní rozdíly mezi testováním ve Scrumu a vodopádu podle jednotlivých oblastí.

Vodopád

Vodopád

Vodopád

Vodopád

Závěr