Agile and Lean, Scrum, Kanban, XP @ Business

Zuzi's blog header image 2

Role testera v agilním týmu

19. 11. 2013 · 6 Comments

Agile

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?

Tags: ······

6 responses so far ↓

  • 1 Cerveny Ladislav // Nov 19, 2013 at 9:05 am

    Moc pekne napsano. Kratce a vystizne. Mohu jen souhlasit.
    Mam stejne zkusenosti pri zavadeni agilniho vyvoje. Resil jsem to castecne alespon tak, ze jsem pozadoval soucinnost testera pri odhadu pracnosti, aby se vyvojari a testeri spolu zacali bavit uz na zacatku pred vyvojem a zjistili vcas co vsechno musi udelat a co k tomu potrebuji.

  • 2 Martin V // Nov 19, 2013 at 9:14 am

    Souhlasim s tim ze by se nad user story mel setkavat analytik, vyvojar a tester. Zvlast u novych casti aplikace a rozsahlejsich ukolu ma tenhle pristup smysl – tam muze byt pomer prace mezi analyzou,vyvojem a testem vcelku vyrovnany.

    Vrta mi ale hlavou jak by se resil bugfixing. Myslim ze u mensich chyb velkou vetsinu casu sebere ciste jen vyvoj napr. 10:1 vuci ostatnim aktivitam jako testum a analyze. Samozrejme existuji i chyby ktere vedou nasledne k analyze a nejakemu komplexnejsimu reseni, ale tech neni mnoho.

    Nezapominejme na code review mezi vyvojari, to ma pro nektere tasky mnohem vetsi smysl – zvlast tam kde je minimum UI / komplexni zpracovani dat v pozadi atp…

  • 3 zuzi // Nov 20, 2013 at 12:44 pm

    To je uricite dobra pripominka. Odhaduje cely tym prave proto, ze potrebujeme mit jistotu ze cely tym zna backlog a rozumi User Stories a ze jsme nezapomeli na jejakou cast pracnosti a komplexity User Story – treba testovani – v tomto pripapade. Kdyz si date pozor ze v dobe odhadu testeri chapou co se bude delat, snaze se pak zapoji jiz v prubehu.

  • 4 zuzi // Nov 20, 2013 at 12:45 pm

    Ono kdyz tym funguje dobre tak po nejake dobe pocet chyb minimalizuje. Pripominam ze chyby v ramci sprintu se rovnou opravi treba prave diky spolupravi testera a vyvojare. Takze ty vyjimecne pripady kde se reportuje chyba asi nemusime resit.

    Na druhou stranu, tester muze prave pri reportingu chyby vyznemne usetrit praci vyvojari. Je rozzdil kdyz najde presny scenar a chybu tak zbyva jen opravit a kdyz jen tak jak tomu casto je ve waterfallu rika nefunguje to….

  • 5 Jiri Benes // Dec 2, 2013 at 8:31 pm

    Jeden problém v úzké spolupráci testerů a vývojařů je a to že všich koukají na problém stejně a ztrácí se nezávislý pohled na problém. Zapomenou se tak otestovat celé kusy funkcionality.

    PS: problém s testováním se jednoduše vyřeší netestováním.

  • 6 Radek Manasek // Dec 3, 2013 at 2:57 pm

    No bohuzel pri kratkych projektech se uplne predejit chybam stejne neda a test zustava vzdy poslednim clankem pred predanim. Vynechat test? Jirko byl jsi vzdy prukopnikem novych technologii, ale tohle by fakt nefungovalo. Cyby tam vzdycky budou, at uz je odhali test, integracni test nebo produkce. Muj nazor je ze tester by mel byt zodpovedny za test, nikoliv vsak vse testovat sam. Pokud mate v tymu schopne developery a analytiky, testovani pro ne nebude tezke. Zvlaste kdyz jim uslapete cesticku: pripravite tooly, vysvetlite metologii a ukazete jak jim muzou byt tyto postupy napomocne pri vyvoji nebo analyze. A o tom scrum taky je, vypomahat si s rolemi navzajem.

Leave a Comment