Agilní testování

O čem bude řeč

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č. 😀

Proč se bavíme o agilním testování

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)

Slovo SCRUM pochází z ragby a znamená tu „skrumáž“ hráčů při vhazování míče. Všichni jsou do sebe zakleslí a působí jeden na druhého, někteří táhnou spolu, někdy proti sobě. Stejně tak ve vývoji formou Scrumu je zásadní tým. Tým je složen z členů, kteří mají různé role. Nejdřív si představíme Product Ownera (PO). Jeho úkolem je vědět, co zákazník potřebuje, a přináší tyto informace do týmu. Jeho druhou nejdůležitější úlohou je stanovovat priority požadavkům, které se vyvíjejí (tzv. user story). Druhou rolí je Scrum Master (SM). Toho si můžete nejlépe představit jako takového týmového kouče. Jeho úkolem je zajistit, aby tým pracoval efektivně. Tedy např. sledoval, jaká je aktuální efektivita týmu, a zjišťoval, jak ji tým může zlepšit. Nedělá to ale formou direktivních nařízení ale koučováním. Další úlohou SM je odstraňovat překážky (tzv. impedimenty), které brání ve vývoji nebo v práci členům týmu. A nejdůležitější rolí jsou samozřejmě samotní členové týmu. Scrumové týmy bývají tzv cross-functional, tedy jsou sestaveny ze všech členů potřebných k tomu, aby se zákazníkovi mohla dodat část softwaru, která mu k něčemu podstatnému je (tzv. product increment). Jsou to tedy typicky vývojáři, testeři, analytici, devops specialisté, architekti, UX designeři atd.
Všichni tito členové včetně SM a PO se scházejí na společných mítinzích:
  • 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).
Scrum je iterativní, tedy nechce vše hned udělat naprosto správně, ale postupně se každý Sprint tým zlepšuje. Scrum je také incrementální, tedy neděláme vše naráz, ale snažíme se produkt budovat postupně po malých částech. Začíná s těmi nejpodstatnějšími user story pro zákazníky/byznys.

Jak se v něm zajišťuje kvalita, tedy testuje

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

 

Samotný Sprint:
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í.

 

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

Hlavní rozdíly vodopád vs Scrum v testování

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

Chcete se naučit testovat software?

Práce s požadavky

Vodopád
  • připravují analytici
  • pevně dané
  • detailně dokumentované
  • testeři nemohou iniciovat změnu
  • připravují PO s týmem
  • mohou se měnit každý Sprint
  • popis volný formou user story
  • testeři iniciují změnu
Plánování
Vodopád
  • plánování jednou před testovací fází
  • review Testplánu zřídka během fáze testování
  • plánování na začátku každého Sprintu
  • review Testplánu každý Sprint

Design a implementace

Vodopád
  • TestCasy pro veškerou funkcionalitu
  • TestCasy jen pro vyvíjenou funcionalitu Sprint/Release
Další rozdíly
Vodopád
  • odhady dělá manažer
  • práci určuje manažer
  • každý inženýr zodpovědný za malou část produktu
  • odhady dělá test inženýr
  • každý test inženýr si vybírá úkoly sám
  • každý inženýr zodpovědný za celý produkt

Závěr

Samozřejmě agilní vývoj není pro každou firmu, o tom ale až někdy příště. Stejně tak si můžeme příště ukázat, co jsou hlavní ničitelé agilního testování, tedy rozebrat největší problémy a jak je řešit. Agilní testování je skvělý způsob jak zajistit kvalitní produkt pro vaše zákazníky a také si užít během vývoje více legrace, místo stresu z nesplněných termínů a naštvaných klientů. Testování v agilním prostředí nemusí být až tak složité, pokud víte jak na to. Jestli ve vašem týmu na agilní vývoj přecházíte a zatím si nejste moc jistí, určitě doporučuji se obrátit na někoho, kdo s tím má již reálné zkušenosti. Abyste se vyvarovali zbytečných chyb, které vás mohou stát hodně. Dalším řešením je navštívit nějaký kurz. Já pořádám např. kurz Testování v agilním prostředí, kde se dané problematice věnujeme celý den a účastníci si mohou i prakticky vyzkoušet, jak se takové agilní testování dělá.