Jedním z nejčastějších problémů, na které týmy při agilní transformaci narazí, je rozdílné vnímání rolí. V tradičním světě analytik dělá dopředu analýzu, vývojář to podle ní nakóduje a tester následně hledá chyby. O tom, že analýzy dopředu nepotřebujeme, neboť můžou vznikat klidně za běhu, se mluví často. O tom, že vývojáři mohou pomoci s testováním taky, ač tato praktika již obvykle není přijímána s takovým nadšením a slýcháme k ní spousty výmluv typu vývojáři to nemůžou testovat protože to neumí. No proto také říkáme, že testerům s testováním mohou pomoct. Ne že je mají nahradit. Hned druhá výmluva v pořadí je, že berou větší plat než testeři a tak že by se to nevyplatilo. A tak nám tato spolupráce obvykle zpočátku trochu skřípe.
Dříve nebo později tak týmy dojdou do stavu, kdy testeři na začátku Sprintu nemají co dělat a na konci nestíhají. User Stories jsou hotové – tedy nakódované – a přesto je nesmíme uznat jako výsledek Sprintu. Chybí přeci testy. Týmy v takové situaci přichází s různými legračními nápady jako např. že by bylo potřeba testery od týmu oddělit a udělat jim separátní posunutý Sprint. Tedy to, co vývojáři v jednom Sprintu napíšou, testeři v druhem Sprintu otestují a je to. Ale to jsme pořád mentálně ve waterfallu. Nikam blíže k agilnímu Scrum týmu jsme se v pochopení ani implementaci neposunuli. Bez ohledu na to, jestli máme tabuli a děláme standupy.
Jak by tedy taková spolupráce měla vypadat? Analytik, vývojář a tester si vezmou User Story, a začnou si o ní povídat. Analytik vymýšlí, jak by se daná funkcionalita měla chovat, vývojář to hned implementuje a tester upozorňuje, na co vše si musí dát pozor. Co uděláte když nepřijdou data? Co když nebudou validní? Nezapomeňte, že v akceptačních kriteriích je i to či ono. A v neposlední řadě připomíná business value (proč) definovanou v poslední části formule User Story, abychom v plném zapojení do implementace funkcionality nezapomněli, proč to vlastně celé děláme a v návrhu to zohlednili. Tedy v podstatě místo aby chyby chytal na konci (kdy už je pozdě), chceme aby chybám předcházel. Chceme, aby chyby vůbec nevznikaly a vývojář se tedy nemusel k již ‘hotovému’ kódu vracet. Spolu s tím, že testera zapojíme do návrhu řešení funkcionalit, chceme, aby vývojářům pomáhal již v průběhu a testoval jednotlivé části. V některých případech pak klidně pracují v páru, jinde jde jen o úzkou spolupráci. Honí-li se vám hlavou, že to nebude efektivní, protože tester to musí testovat pořád dokola, není tomu tak. Opravy chyb se také testují dokola a k tomu tam máme ještě multitasking vývojářů a jejich čas strávený opravou již hotových funkčností. A říkáte-li si, že to vaši testeři nezvládnou, protože co mají testovat pochopí až z hotové funkcionality, zkuste se podívat na to, jak dobře definované User Story máte. Jestli dobře, včetně akceptačních kriterií, je to snadné. Když ne, není to chyba testerů, ale pravděpodobně tomu nerozumí ani ostatní členové týmu.
Takže summary na závěr. Úkolem testera není chyby hledat, ale předcházet jim. Dobrý tester v agilním týmu dosáhne toho, že ve finálním testování User Story se žádné chyby nenajdou. A tím jen tak mimochodem ušetří firmě spousty času potažmo peněz. Dobrý tester rozumí zákazníkovi a funkcionalitě a pomáhá s návrhem řešení. Umí se na User Story podívat očima uživatele. Je to plnoprávný člen týmu, který je pro jeho úspěch klíčový. A otázka na závěr… Opravdu si myslíte, že takový člen týmu má mít menší plat jen kvůli názvu jeho pozice?
