Stručný průvodce implementací ATDD

Tento článek poskytuje stručného průvodce všem zájemcům o zavedení ATDD do svých týmů a projektů. Uvádí výhody dodržování tohoto agilního přístupu na základě mých přímých zkušeností v týmu firemního vývoje softwaru.

Spolupráce je jednou ze základních hodnot agilní metodiky. Kdysi, když jsem pracoval na velkém projektu, jsem si všiml nedostatečné spolupráce mezi vývojáři, testery a obchodně smýšlejícími osobami; nedostatečné jasnosti požadavků; častého rozšiřování rozsahu požadavků; nedostatečného přehledu, pokud jde o dokončené testování; a defektů, které byly identifikovány pozdě v životním cyklu projektu. Nejdůležitější pro mě však bylo, že nikdo neměl ponětí o našem automatizačním rámci, takže všechny automatizační testy byly napsány až poté, co byly funkce vyvinuty a připraveny k testování. Kvůli těmto postřehům jsem začal zkoumat, jak lidé podobné problémy řeší. Výsledkem bylo zjištění, že Acceptance Test Driven Development (ATDD) je jedním z přístupů používaných ke zmírnění mnoha těchto problémů. Často se používá jako synonymum pro Behavior Driven Development (BDD), Story Test Driven Development (SDD) a Specification By Example (SBE). Hlavním rozdílem ATDD oproti ostatním agilním přístupům je jeho zaměření na to, aby vývojáři, testeři, obchodníci, vlastníci produktů a další zúčastněné strany spolupracovali jako jeden celek a vytvořili si jasnou představu o tom, co je třeba implementovat.

Na základě vlastních zkušeností se s vámi podělím o své nápady, jak mohou týmy implementovat ATDD do svých projektů.

Kontext

Pracoval jsem ve velké společnosti, která měla startupové myšlení, takže veškeré inovativní nápady a zpětná vazba byly týmem podporovány. Rychle jsme vytvářeli prototypy, abychom zjistili, zda by nějaký nápad zlepšil náš produkt nebo pomohl v nadřazených cílech společnosti. Byl jsem vedoucím testerem v 25členném týmu, který se skládal z jednoho scrum mastera, jednoho technického vedoucího a několika obchodních analytiků, designérů, vývojářů a testerů. V důsledku kultury inovací panoval v týmu často chaos, včetně častých změn požadavků na funkce, jednotlivci pracovali v oddělených prostředích a morálka týmu byla na velmi nízké úrovni. To mě znepokojovalo, a tak jsem se dobrovolně nabídl, že pomohu najít řešení těchto bolestivých bodů, což mě přivedlo k ATDD.

Všechny mé poznatky a zkušenosti s ATDD lze rozdělit do následujících tří kroků.

Cyklus implementace ATDD

Vytvořil Raj Subramanian

Krok 1 – Školení a experimentování

Existuje mnoho způsobů, jak přistupovat k úkolům, zejména pokud vezmeme v úvahu zkušenosti jednotlivců pracujících v různých agilních týmech uvnitř i vně jejich současných organizací. Aby došlo ke sdílenému a společnému chápání cílů týmu a organizace, je důležité zajistit odpovídající školení. Pokud jde konkrétně o ATDD, mělo by zahrnovat cíle, úkoly, očekávání a informace o výsledcích, které přinese používání tohoto přístupu. Po školení je důležité začít s implementací v malém měřítku, aby bylo možné vyzkoušet různé věci a získat iterativní zpětnou vazbu.

Příklad po prozkoumání ATDD jsem různým zúčastněným stranám vysvětlil, proč musíme tento přístup prozkoumat a jaké výhody z něj budeme mít. Zdůraznil jsem několik možných pozitiv, jako je zvýšená týmová spolupráce, lepší vyjasnění požadavků, dřívější identifikace chyb v rámci životního cyklu vývoje softwaru (SDLC), větší přehlednost a dřívější využití automatizace v SDLC a také zapojení celého týmu do vymýšlení jasných kritérií přijatelnosti.

Při diskusi se zúčastněnými stranami jsem zdůraznil, že to bude vyžadovat určité experimentování, ale bez vyzkoušení se nikdy nedozvíme jeho přínosy. Po několika dlouhých diskusích jsme se rozhodli rozdělit původní tým 25 lidí na 2 menší týmy: Tým A se skládal z 12 lidí a měl implementovat ATDD. Tým B měl zbývajících 13 lidí a měl pokračovat v tom, co už dělal.

Pro tým A jsem naplánoval dvoudenní školící workshop, na kterém jsem se seznámil s ATDD, určil, které koncepty mají smysl v kontextu našeho projektu, a jak bychom mohli využít automatizaci v celém tomto procesu. Do školení jsem zařadil směs teoretických a praktických cvičení. Některá cvičení jsou uvedena níže:

• Jak psát příkazy Gherkin – Given/When/Then (GWT)
• Jaké jsou klíčové atributy dobrého uživatelského příběhu
• Ukázka našeho automatizačního rámce včetně toho, jak funguje a jak je strukturovaný. Nechybělo ani cvičení, jak v týmu napsat jednoduchý automatizační testovací kód. Před workshopem jsme s jedním členem týmu upravili náš automatizační rámec tak, aby byl v souladu s přístupem ATDD. Pro náš automatizační framework jsme použili plugin Cucumber s Javou a Appium.

Zdroj

Krok 2 – Zvýšení přehlednosti

Když projekt žije několika sprinty, je snadné ztratit přehled o různých procesech, které je třeba dodržovat. Klíčem k úspěchu je tedy zviditelnit cíle, úkoly a očekávání pro celý tým.

Když jsme začali používat ATDD, začal jsem jednoduše tím, že jsem každý z denních procesů, které bude třeba dodržovat, napsal na tabuli, kterou jsem umístil na místo, kde měl náš tým každodenní stand-up schůzky. Ke každému uživatelskému příběhu jsem přidal kontrolní seznam položek, které bylo třeba provést, aby byl příběh považován za dokončený. Tímto způsobem nevznikaly žádné nejasnosti ohledně toho, jaké procesy ATDD je třeba dodržovat. Jednou z takových položek kontrolního seznamu byla úvodní schůzka, během níž vývojář, tester a obchodníci jako tým diskutovali o požadavcích, určili, které požadavky lze automatizovat, a nastínili akceptační kritéria příběhu ve formátu GWT. Další položkou kontrolního seznamu byla QA-Dev Handoff, kde vývojář prostřednictvím rychlé ukázky nebo diskuse ukáže testerovi, jak byly požadavky splněny a jaké unit testy byly napsány jako součást příběhu. Díky tomuto předání se tester dozvěděl, které oblasti nebyly pokryty jednotkovými testy, a lépe porozuměl implementované funkci, což vedlo k lepšímu pokrytí testů. Položky kontrolního seznamu byly někdy zřejmé, ale bylo dobré je mít jasně uvedené. Zařadili jsme jeden, který zajišťoval uzavření všech defektů spojených s příběhem; dalším bylo konečné schválení obchodní osobou po zhlédnutí ukázky, což zajišťovalo, že funkce byla vytvořena v souladu s předem stanovenými požadavky a očekáváními.

Začali jsme také mít „procesního jestřába“. Jednalo se o jednotlivého člena týmu; mohl to být scrum master, projektový manažer nebo kdokoli jiný, kdo zajišťoval, aby tým dodržoval proces. V mém případě to byl další seniorní tester v týmu; on i já jsme pravidelně všem připomínali dodržování procesu ATDD na všech schůzkách, včetně standupu, plánování, retrospektivy a dalších týmových schůzek.

Krok 3- Iterativní učení a zpětná vazba

Mít neustálou smyčku zpětné vazby je klíčové při implementaci jakéhokoli agilního přístupu, včetně ATDD. Pořádání týdenních nebo dvoutýdenních retrospektivních schůzek s celým týmem je důležitým způsobem, jak zjistit, které části procesu jsou pro tým skutečně přínosné a které je případně třeba upravit. Jak již víme, něco, co týmu nepomáhá, vede k plýtvání časem a úsilím. Jak uvádí Brian Tracy, autor knihy Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time (Snězte tu žábu!: 21 skvělých způsobů, jak přestat prokrastinovat a udělat více za méně času): „Jedním z nejhorších způsobů využití času je dělat velmi dobře něco, co vůbec není třeba.“

V současné éře informačních technologií si organizace nemohou dovolit plýtvat časem a energií na neefektivní přístupy; naopak potřebujeme zavést štíhlé a efektivní procesy. To souvisí s principem štíhlého startupu Validated Learning: cyklus Build, Measure, Learn.

S tímto vědomím jsem začal každý čtvrtek pořádat 30minutové schůzky s týmem A, abych zkontroloval, jak se týmu daří s novým procesem. Byl to dobrý způsob, jak na základě reakcí týmu zjistit, jaké změny je třeba provést. Tato schůzka probíhala odděleně od retrospektivní schůzky, která byla na konci dvoutýdenních sprintů. Tento přístup přinášel průběžnou zpětnou vazbu od týmu, což nám umožnilo provádět okamžité a efektivní změny. Zpětná vazba nevycházela pouze z týdenních kontrolních schůzek procesu; cenným zdrojem informací se ukázaly být i každodenní stand-up schůzky. Aktualizace a diskuse jednotlivých členů týmu odhalily červené vlajky týkající se procesu a my jsme je mohli okamžitě řešit dříve, než ovlivnily zbytek týmu.

Shrnutí

V důsledku dodržování cyklu implementace ATDD začal tým A pozorovat značné rozdíly v morálce týmu, spolupráci a požadavcích.

Morálka týmu

Všichni začali pracovat jako tým a cítili se posíleni. Každý člověk vlastnil příběh od začátku až do konce. Zajistil, aby příběh obsahoval všechny potřebné informace pro zahájení vývojových a testovacích prací. Člen týmu také zajistil, aby byly provedeny všechny následné kroky související s příběhem. Nakonec měla tato osoba na starosti předvedení příběhu všem zúčastněným stranám na konci sprintu. Tento pocit vlastnictví výrazně zvýšil morálku týmu.

Spolupráce

Na zahajovacích schůzkách se sešli obchodník, vývojář a tester, aby společně dosáhli porozumění uživatelskému příběhu. QA-Dev Handoff, které proběhlo před odesláním sestavení na servery QA, pomohlo vývojáři i testerovi zjistit, jaké testování bude v rámci příběhu provedeno, a přineslo lepší pochopení implementované funkce. Došlo k většímu přehledu v automatizaci, protože odpovědnost převzal celý tým, nikoli pouze testeři. A konečně, na plánovacích schůzkách celý tým diskutoval o příběhu společně, a proto vzniklo více nápadů, otázek a diskusí. Zvýšená spolupráce vedla také ke zvýšenému učení – tým se rozhodl pořádat vzájemná koučovací sezení, aby se učil jeden od druhého, testeři začali provádět párové průzkumné testování a různí členové týmu pořádali sezení typu „lunch-n-learn“, na kterých probírali různá témata týkající se technologie. Všechny tyto věci vedly ke zlepšení celkové týmové spolupráce.

Požadavky

Jedním z hlavních problémů našich předchozích procesů byly časté změny požadavků a nárůst rozsahu. S přístupem ATDD bylo nutné, aby jakmile vývojář začal pracovat na příběhu, požadavky se uzamkly. Jakékoli změny musely být prioritizovány spolu s ostatními připravovanými příběhy a přidány do nadcházejících sprintů. Tím se snížila pracovní zátěž vývojářů i testerů a zabránilo se tomu, aby zainteresované strany měly nerealistická očekávání od dokončených funkcí.

Po zjištění všech výše uvedených zlepšení začal tým B také zavádět ATDD. Výsledkem bylo, že po pravidelném experimentování a zpětné vazbě začal tento přístup používat celý původní tým.

Závěr

Přístup ATDD doporučuji a je v souladu s paradigmatem „Shift Left“, podle kterého by vývoj a testování měly začít co nejdříve v SDLC. Přinesl větší přehled o automatizaci, protože jsme začali psát automatizované testy na začátku SDLC, což zase zvýšilo spolupráci v týmu.

Zdroj

Zapomeňte, že ATDD není řešení „one size fits all“. V kontextu mého projektu to byl agilní přístup, který dával největší smysl, ale existují různé další způsoby, jak zlepšit procesy v týmech. Tento přístup jsem použil kvůli zaměření na lepší akceptační testy, ale především kvůli jeho důrazu na spolupráci. Část týkající se spolupráce je nedílnou součástí tohoto přístupu a považuji ji za nejcennější.

O autorovi

Raj Subrameyer je technologický kariérní stratég, který se zaměřuje na pomoc lidem získat práci snů a stát se úspěšnými lídry. S nadšením vede profesionály k tomu, aby maximalizovali své příležitosti a objevili svou zónu geniality. Své zkušenosti z technologického průmyslu využívá k výzkumu, přednáškám a psaní o tom, jak můžeme přijmout technologie a stát se plnohodnotnými digitálními občany. Je vyhledávaným řečníkem na různých konferencích a objevil se v mnoha podcastech a publikacích, včetně CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success a The Good Men Project. Je také autorem nové knihy – „Skyrocket Your Career“. Mezi jeho odborné oblasti patří kariérní postup, vedení, motivace, produktivita a podnikání. Ve volném čase rád cestuje a vychutnává si řemeslné pivo. Více informací o tom, jak slouží lidem, najdete na jeho webových stránkách.