Scrum mínus testovací plán se rovná POC na steroidech.
V dnešní době většina úspěšných projektů začíná Proof of Concept (POC), relativně malým posouzením nápadu, kde bude zvolená technologie a balíček funkcí nejprve ověřena, vyhodnocena z hlediska potenciálního dopadu na podnikové uživatele a poté, jakmile bude prokázána. hodný investice, je určen plnohodnotný projektový tým, který navrhne a dodá plnohodnotný produkt a nasadí jej do výroby.
Toto je ideální případ pro tým Scrum. Tým může rychle vyvinout prototyp a přidávat podstatné nové funkce do každého sprintu, zatímco podnikoví uživatelé mohou v reálném čase sledovat rychlý pokrok a to, jak je nápad postaven od nuly během pouhých 10 sprintů. Zanechává silný dojem (což je ostatně hlavním cílem POC), ale má také jednu významnou vlastnost – minimální nebo žádné testovací aktivity a i pomyšlení na testovací proces by byl přímo vtip.
Uvnitř týmu Scrum to není žádná zábavná činnost a lidem se většinou bude líbit myšlenka vyvíjet se bez procesů, které by je zpomalovaly. To je v podstatě to, co jakákoli testovací činnost implicitně udělá. A kdo chce zbytečnou pomalost v době, kdy potřebujeme nejvíce zapůsobit na koncového uživatele?
Stav, který nastane, pokud projektový tým pokračuje stejným způsobem i po skončení období POC, je něco, čemu říkám POC na steroidech – produkční systém rostoucí ve velikosti a funkcích, ale stále se chová jako POC – rádoby kompletní produkt s skryté vady a neprozkoumaná rohová pouzdra, čekající pouze na vážnou havárii.
Ale než se tam konvertuje, tým bude mít od sprintu ke sprintu těžší držet krok se stabilními verzemi, protože oprava průběžných problémů bude jen složitější.
Zde je několik technik, které se osvědčily, když jsem se potýkal s podobnými problémy, a o kterých se domnívám, že je lze označit za nejlepší postupy pro implementaci solidních testovacích procesů, aniž by příliš ztěžovaly vývojový pokrok – protože to je to, pro co všichni chceme být. Scrum tým.
Table of Contents
Distribuujte bolest
Kde jinde začít se zbytečným trápením, než štěpením bolesti :).
A co tím myslím, je vytvoření plánu, který bude tu a tam vyžadovat malou dodatečnou aktivitu od vývojářů, ale který časem výrazně přispěje ke společnému cíli, postupně, ale konzistentně.
#1. Vytvořte testovací kód jednotky pro každý vytvořený kus nového kódu
Pokud se vám podaří přesvědčit své scrum týmy, aby do své klauzule Definition Of Done přidali vývoj jednotkových testů pro každý nový kód vytvořený v rámci sprintu, pak to bude z dlouhodobého hlediska velký úspěch.
Důvody jsou poměrně zřejmé:
Donutí vývojáře přemýšlet o různých nestandardních cestách kódu. –
- Takové testy jednotek lze zapojit do automatizovaných kanálů DevOps a provádět je při každém jednotlivém nasazení do vývojového nebo testovacího prostředí. Metriky z kanálu lze také snadno exportovat a poté použít k demonstraci procentuálního pokrytí testovacích případů přímo vázaných na zdrojový kód obchodním uživatelům.
Nejdůležitější je začít velmi brzy. Čím později začnou být testy jednotek vyvíjeny, tím více bude pro vývojáře rušit jejich přidávání v rámci sprintu.
- Zpětný vývoj jednotkových testů pro již existující kód bude vyžadovat značné úsilí. Některé části kódu mohou být vytvořeny jiným vývojářem a přesná znalost toho, jak by to mělo fungovat v každé jednotlivé části kódu, není aktuálnímu vývojáři přesně jasné. V některých případech to může dojít tak daleko, že přidání testu jednotky do upraveného kódu zabere více času než vývoj změny funkce pro sprint (což je stav, který nikdo během plánování sprintu s jistotou nepočítal).
#2. Vytvořte rutinu spouštění všech částí Unit Tests ve vývojovém prostředí
Ještě před vytvořením požadavku na stažení nového kódu do větve Master by mělo být standardní aktivitou otestovat kód funkce i kód testování jednotky v prostředí dev. Tímto způsobem bude zajištěno, že:
- Testovací kód jednotky skutečně funguje pro každou část (nakonec je to jen další kód, který musí být ověřen). Tento krok je velmi často zcela vynechán. Nějak se předpokládá, že pokud je test jednotky stejně zapojen do potrubí DevOps, bude nakonec proveden a někde standardně otestován. Nejde však o nic jiného, než o posunutí problémů do vyšších úrovní sprintových aktivit, kde má tým obvykle méně času a více stresu na dokončení každého angažovaného příběhu.
- Nový kód funkce je testován vývojářem na základní funkčnost. Je zřejmé, že od tohoto testu nelze očekávat, že bude plně ověřena obchodní funkčnost, ale alespoň tento test potvrdí, že se kód chová tak, jak jej vývojář zamýšlel (prozatím ignorujeme skutečnost, že obchodní logika by mohla být při vývoji nesprávně pochopen).
#3. Po sloučení kódu do hlavní větve očekávejte provedení testu jednotky
Jedna věc je mít funkční kód na místní pobočce (kde nikdo kromě vlastníka pobočky nevyvíjí novou funkci), ale úplně jiná věc je mít stejný kód funkční po požadavku na stažení a sloučení do hlavní větve.
Hlavní větev obsahuje změny od ostatních členů Scrum týmu, a i když jsou konflikty vyřešeny a vše vypadá v pořádku, kód po sloučení a vyřešení konfliktů je v podstatě stále nevyzkoušeným kusem kódu a je riskantní jej posílat dále bez předchozího ověření. stále to funguje dobře.
Takže to, co se zde ukázalo jako efektivní, je jednoduše požádat o provedení stejného testování jednotek – již dříve provedené v prostředí dev – také v prostředí, které je vytvořeno z verze kódu hlavní větve.
Pro vývojáře to může být další krok, který by měli zahrnout do svého života, ale není to až taková námaha, protože v tomto případě není třeba vymýšlet nic nového – stačí znovu provést to, co již bylo jednou uděláno.
Nyní lze tento krok v jednom konkrétním případě přeskočit:
- Automatizované testy jednotek v kanálech DevOps jsou tak komplexní, že již pokrývají celé manuální testování prováděné navíc.
I když dosažení tohoto stavu je rozhodně proveditelné, v reálném životě jsem takový stav nikdy nezažil. Pro vývojáře by bylo pravděpodobně až příliš časově náročné vytvořit tak hluboce podrobné automatizované Unit testy. Pro vlastníka produktu by mohlo být snadno nepřijatelné, kdyby nechal tým věnovat této činnosti tolik času, protože by to mělo explicitní dopad na počet dodaných příběhů v rámci sprintu.
Upřednostnění obsahu sprintu však nikdy nesmí být omluvou pro neprovedení jednotkových testů nebo dokonce pro jejich minimalizaci. Tím se tým znovu převede do stavu, kdy kód postrádá příliš velké pokrytí testem jednotky, a pak už může být příliš pozdě na dohonění (opět větší úsilí o dokončení testu jednotky než skutečné změna kódu pro sprint).
Ze všech těchto důvodů bych bez váhání doporučil opětovné provedení testů jednotek na verzi hlavního kódu. Je to tak nízké úsilí v porovnání s tím, jakou hodnotu to přinese.
Provede poslední kontrolu připravenosti hlavní větve na fázi testování vydání. Pomůže také najít většinu technických chyb (např. chyby, které brání úspěšnému provedení zdrojového kódu až do úspěšného konce), přičemž v další fázi se ponechává pouze ověření funkčnosti businessu.
Připravte se na funkční testování
Všechny předchozí testovací aktivity povedou k jednomu konkrétnímu závěru – hlavní kód větve neobsahuje technické chyby a je bez problémů spustitelný pro end-to-end funkční toky.
Jedná se o fázi, kterou bez problémů zvládne i jediný člověk, a to ani nemusí mít technické vzdělání.
Ve skutečnosti je mnohem lepší, když to provádí někdo odpojený od vývojářů, ale s funkčním povědomím o tom, jak obchodní uživatelé očekávají, že se kód bude chovat. Je třeba dokončit dvě hlavní činnosti:
#1. Nový funkční test zaměřený na příběhy sprintů
Každý sprint by měl v ideálním případě přinést nějakou novou funkcionalitu (přírůstek cíle sprintu), která dříve neexistovala, a proto bude ověřena. Je důležité zajistit, aby nový software fungoval do té míry, aby z něj business uživatelé byli rádi, protože se na něj evidentně těšili minimálně celý poslední sprint :).
Je to tak smutná zkušenost, když je (dlouho) slibovaná funkčnost konečně oznámena, že bude uvolněna, jen abychom druhý den zjistili, že ve skutečnosti nefunguje dobře.
Správné testování nové funkčnosti sprintu je proto klíčové. Aby to bylo úspěšné, je dobrou praxí shromáždit důležité testovací případy předem a od příslušných zúčastněných stran (buď od vlastníka produktu nebo dokonce od koncových uživatelů) a vytvořit seznam všech takových testovacích případů potřebných pro obsah uvnitř sprint.
To se může na první pohled zdát ohromující, ale z mé zkušenosti to opět zcela zvládne jeden člověk. Vzhledem k tomu, že sprinty jsou většinou poměrně krátké (např. krátké období dvou týdnů), téměř nikdy to není příliš nového obsahu, protože sprint obsahuje také další aktivity, jako jsou technické dluhové příběhy, dokumentace, design/spike stories atd.
Testovací případy jsou pak prováděny s cílem především ověřit požadovanou funkčnost. Pokud se s výsledky vyskytne jakýkoli problém, je osloven pouze příslušný vývojář (ten, kdo vlastní změny související s touto konkrétní vadou), aby problém vyřešil, doufejme, rychle.
Vývojáři tak stráví minimum času spojeného s funkčním testováním a stále se mohou soustředit na činnosti, které mají nejraději.
#2. Provádění případů regresního testu
Další částí funkčního testování je zajistit, aby vše, co fungovalo doposud, bude fungovat i po příštím vydání. K tomu slouží regresní testy.
Testovací případy pro regresní testy jsou nejlepší, pokud jsou pravidelně udržovány a znovu navštěvovány před každým vydáním. Na základě konkrétních specifik projektu je nejlepší, aby byly jednoduché, ale zároveň pokrývaly většinu samotných základních funkcí a důležitých end-to-end toků procházejících celým systémem.
Obvykle má každý systém takové procesy, které se dotýkají mnoha různých oblastí, ty jsou nejlepšími kandidáty na případy regresního testu.
V některých případech regresní testy dokonce implicitně pokrývají také nové funkce ve sprintu, například pokud nový příběh ve sprintu mění určitou část stávajícího toku.
Takže ve většině případů není vůbec příliš složité dokončit regresní testy spolu s testy funkčnosti nových příběhů sprintu, zvláště pokud se to provádí pravidelně před každým produkčním vydáním a periodicita produkčních vydání není příliš malá.
Trvejte na provedení testů zajištění kvality před každým uvedením do výroby
Test zajištění kvality (QA) je posledním krokem před uvedením do výroby a často je tento test vynechán jako nedůležitý. Zvláště pokud je scrum tým řízen agresivně pro nový obsah.
I firemní uživatelé řeknou, že se zajímají o nové funkce a ne tolik o zachování funkčnosti nebo udržení nízkého počtu závad. Ale znovu – v průběhu času je to hlavní důvod, proč bude muset vývojářský tým nakonec zpomalit a firemní uživatelé pak stejně nedostanou to, o co žádají.
QA test provádějí výhradně lidé mimo tým Scrum, ideálně samotní obchodní uživatelé ve vyhrazeném prostředí, které je co nejblíže budoucí produkci. Alternativně zde může vlastník produktu nahradit koncové uživatele.
V každém případě by se mělo jednat o čistý, funkční test z pohledu koncového uživatele, bez jakékoli vazby na vývojářský Scrum tým. Představí jeden konečný pohled na produkt a bude používán způsobem, který možná nikdo ze scrum týmu nepředpokládal (není to vůbec ideální případ, ale rozhodně se to může stát). Ještě je čas na opravy na poslední chvíli.
Případně by se mohlo ukázat, že scrum tým očekávání nepochopil dobře, a v takovém případě se alespoň můžeme dohodnout na následném plánu, ještě dlouho před skutečným uvedením do produkce. Toto opět není ideální případ, ale stále mnohem lepší jako přiznat selhání hned po nahlášení úspěšného produkčního vydání.
Kam dál odtud?
Aplikování těchto praktik na každodenní práci se scrumem vás může vážně přivést ke stabilizovanějším a předvídatelnějším návykům uvolňování sprintů, aniž byste zdržovali produkční vydání nebo strávili celý sprint přípravou na další vydání, nebo dokonce aniž byste nutili všechny ve scrum týmu dělat něco, co dělají. Po většinu sprintu se mi to opravdu nelíbí nebo nevím, jak to dělat efektivně.
Ale tady se určitě zastavit nemusíte.
Zahrnutí testů výkonu je jedno téma, které je třeba zde jmenovat. Ty jsou často ignorovány nebo považovány za zbytečné, což je v prvním kole „optimalizace činností skrumáže“ vyřazeno. Vždy jsem však pochyboval o tom, jak lze očekávat, že se produkční systém bude časem vyvíjet, pokud není pravidelně kontrolován výkon.
Postoupit o úroveň výš znamená také zavedení automatizovaných testů.
Jednu skupinu automatizovaných testů (jednotkové testy v potrubí) jsem již pokryl. Můžete však vyvinout úplné regresní testy typu end-to-end, které jsou zcela automatizované a spouštěné samy po každém nasazení do testovacího prostředí. To by ještě více uvolnilo vývojářský scrumový tým, ale k vývoji a údržbě takových automatizovaných testů je zapotřebí specializovaný tým. Stalo by se to neustálou prací, protože kdykoli se změní produkční kód, některé stávající automatizované testy se mohou stát neplatnými, a proto je třeba je aktualizovat, aby pokračovaly v práci. Je to úsilí, za které je ochoten zaplatit jen málokdo, přínosy pro dev scrum tým by však byly velké.
To jsou témata sahající daleko nad rámec tohoto článku a nalezení správného rozvrhu a načasování pro každý zde zmíněný typ testu – tak, abyste to zvládli v rámci okna sprintu. Příště se rád ponořím!