Když se Scrum zbaví testovacího plánu, vznikne POC na steroidech.
V dnešní době většina úspěšných projektů zahajuje svou cestu konceptem Proof of Concept (POC), což je v podstatě menší zhodnocení myšlenky. Během tohoto procesu se ověřuje zvolená technologie a soubor funkcí. Následně se posuzuje jejich potenciální dopad na uživatele v rámci podniku. Jakmile se prokáže, že daný nápad stojí za investici, sestavuje se plnohodnotný projektový tým, jehož úkolem je navrhnout, vyvinout a uvést do produkčního prostředí kompletní produkt.
Pro takový úkol je ideální tým pracující podle metodiky Scrum. Tým dokáže rychle vytvořit prototyp a v každém sprintu přidávat nové, významné funkce. Uživatelé v podniku tak mohou v reálném čase sledovat rychlý pokrok a vznik nápadu od samotného základu během například deseti sprintů. Takový postup zanechává silný dojem, což je koneckonců hlavním cílem POC. Nicméně má jeden velký nedostatek – minimální, nebo dokonce žádné testování. Myšlenka testovacího procesu by v této fázi působila spíše jako vtip.
V týmu Scrum se obvykle netěší oblibě činnosti, které zpomalují vývoj. Většině se líbí představa vývoje bez zbytečných procesů. A testování v podstatě vždy vývoj zpomaluje. Navíc, kdo chce zbytečné zpomalování, když potřebujeme na koncové uživatele udělat co nejlepší dojem?
Pokud projektový tým pokračuje stejným tempem i po ukončení POC, dochází k situaci, kterou nazývám „POC na steroidech“. Vzniká produkční systém, který roste na velikosti i v počtu funkcí, ale stále se chová jako POC. Je to jakoby skoro kompletní produkt s utajenými chybami a neotestovanými okrajovými případy, které jen čekají na vážnou havárii.
Nicméně, než k tomu dojde, bude mít tým s každým sprintem stále těžší udržet stabilitu verzí. Opravování průběžných problémů bude čím dál složitější.
Dále uvádím několik ověřených technik, které se mi osvědčily při řešení podobných problémů. Domnívám se, že je lze považovat za nejlepší postupy pro zavedení solidních testovacích procesů, aniž by došlo k nadměrnému brzdění vývojového postupu. A to je koneckonců to, o co v týmu Scrum všichni usilujeme.
Rozložte zátěž
Kde jinde začít s eliminací zbytečných obtíží než rozložením zátěže? 🙂
Mám na mysli vytvoření plánu, který vývojáře tu a tam zatíží drobnou aktivitou navíc, ale která postupem času výrazně přispěje ke společnému cíli, a to postupně, ale konzistentně.
#1. Vyvíjejte jednotkové testy pro každý nový kus kódu
Pokud se vám podaří přesvědčit váš scrum tým, aby do své definice „Hotovo“ zahrnul i vývoj jednotkových testů pro každý nový kód vytvořený v rámci sprintu, bude to z dlouhodobého hlediska obrovský úspěch.
Důvody jsou poměrně zřejmé:
Donutí vývojáře přemýšlet o různých neobvyklých cestách kódu.
- Takové jednotkové testy lze integrovat do automatizovaných kanálů DevOps a spouštět je při každém nasazení do vývojového nebo testovacího prostředí. Metriky z kanálu lze také snadno exportovat a použít k demonstraci procentuálního pokrytí testovacích případů, které jsou přímo svázány se zdrojovým kódem, i obchodním uživatelům.
Nejdůležitější je začít co nejdříve. Čím později se s vývojem jednotkových testů začne, tím více bude pro vývojáře rušivé jejich přidávání během sprintu.
- Zpětné doplňování jednotkových testů do existujícího kódu si vyžádá značné úsilí. Některé části kódu mohl vytvořit jiný vývojář a současný vývojář nemusí mít přesnou znalost toho, jak by měla každá část kódu fungovat. V některých případech může přidání jednotkového testu do upraveného kódu zabrat více času než samotná úprava funkcí pro sprint (což nikdo během plánování sprintu nemohl předvídat).
#2. Zaveďte rutinu spouštění všech jednotkových testů ve vývojovém prostředí
Ještě předtím, než se vytvoří požadavek na stažení nového kódu do hlavní větve, mělo by být standardní činností otestovat kód funkcí i kód jednotkových testů ve vývojovém prostředí. Tímto způsobem se zajistí, že:
- Kód jednotkových testů skutečně funguje pro každou část (koneckonců je to také jen kód, který je třeba ověřit). Tento krok se velmi často vynechává. Předpokládá se, že pokud je jednotkový test začleněn do kanálu DevOps, bude se nakonec provádět a testovat standardně někde v procesu. Nicméně to není nic jiného než 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 zadaného úkolu.
- Nový kód funkcí je otestován vývojářem z hlediska základní funkčnosti. Od tohoto testu nelze samozřejmě očekávat plné ověření obchodní funkčnosti, ale alespoň se potvrdí, že se kód chová tak, jak zamýšlel vývojář (zatím ignorujeme skutečnost, že obchodní logika mohla být při vývoji nesprávně pochopena).
#3. Očekávejte spuštění jednotkových testů po sloučení kódu do hlavní větve
Jedna věc je mít funkční kód na lokální větvi (kde kromě vlastníka větve nikdo jiný novou funkci nevyvíjí), ale úplně jiná věc je, když stejný kód funguje i po požadavku na stažení a sloučení do hlavní větve.
Hlavní větev obsahuje změny od ostatních členů týmu Scrum. 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 stále neotestovaný a je riskantní jej posílat dále bez předchozího ověření, že stále funguje správně.
V praxi se ukázalo jako efektivní jednoduché vyžadování opakovaného spuštění stejných jednotkových testů, které již byly provedeny ve vývojovém prostředí, také v prostředí vytvořeném z verze kódu hlavní větve.
Pro vývojáře to může být další krok, který by měli zařadit do svého pracovního postupu, ale nepředstavuje to až tak velkou námahu, protože v tomto případě se nemusí nic nového vymýšlet – pouze se znovu provede to, co se již jednou udělalo.
V jednom konkrétním případě lze tento krok přeskočit:
- Automatizované jednotkové testy v kanálech DevOps jsou natolik komplexní, že již pokrývají celé manuální testování provedené navíc.
I když je dosažení tohoto stavu rozhodně proveditelné, v reálném životě jsem se s tímto stavem nikdy nesetkal. Pro vývojáře by pravděpodobně bylo příliš časově náročné vytvářet tak hluboké a detailní automatizované jednotkové testy. Pro vlastníka produktu by mohlo být nepřijatelné, aby tým věnoval tolik času této činnosti, protože by to mělo dopad na počet dodaných úkolů během sprintu.
Upřednostňování obsahu sprintu by však nikdy nemělo být záminkou pro neprovádění jednotkových testů nebo dokonce pro jejich minimalizaci. Tímto se tým opět dostane do stavu, kdy kód postrádá dostatečné pokrytí testy a pak už může být příliš pozdě na to, aby se to dohnalo (opět větší úsilí při dokončení testu jednotky než samotná změna kódu pro sprint).
Ze všech těchto důvodů bych bez váhání doporučil opakované spuštění jednotkových testů na verzi hlavního kódu. Je to tak málo úsilí ve srovnání s tím, jakou hodnotu to přinese.
Provede se poslední kontrola připravenosti hlavní větve pro fázi testování release. Také pomůže najít většinu technických chyb (např. chyby, které brání úspěšnému spuštění zdrojového kódu až do úspěšného konce). V další fázi se tak ponechá pouze ověření funkčnosti obchodní logiky.
Připravte se na funkční testování
Všechny předchozí testovací aktivity vedou k jednomu zásadnímu závěru – hlavní kód větve neobsahuje technické chyby a je bezproblémově spustitelný pro komplexní funkční procesy.
Tuto fázi může bez problémů zvládnout i jedna osoba, která dokonce nemusí mít technické vzdělání.
Je dokonce výhodnější, když testování provádí někdo, kdo není přímo spojen s vývojáři, ale má funkční povědomí o tom, jak by se kód měl podle obchodních uživatelů chovat. Je třeba dokončit dvě hlavní činnosti:
#1. Funkční test zaměřený na novinky sprintu
Každý sprint by měl v ideálním případě přinést novou funkcionalitu (přírůstek k cíli sprintu), která dříve neexistovala a kterou je tedy potřeba ověřit. Je důležité se ujistit, že nový software funguje k plné spokojenosti obchodních uživatelů, kteří se na něj zjevně těšili alespoň celý poslední sprint. 🙂
Je to smutný zážitek, když je (dlouho) slibovaná funkce konečně oznámena jako uvolněná, a druhý den zjistíme, že vlastně dobře nefunguje.
Proto je správné testování nové funkčnosti sprintu klíčové. Pro úspěch tohoto kroku je dobrým zvykem shromáždit důležité testovací případy předem od příslušných zainteresovaných stran (ať už od vlastníka produktu, nebo i od koncových uživatelů) a vytvořit seznam všech takových testovacích případů, které jsou potřebné pro obsah sprintu.
Na první pohled se to může zdát ohromující, ale z vlastní zkušenosti vím, že to opět zvládne jedna osoba. Protože sprinty jsou většinou poměrně krátké (například dvoutýdenní období), tak není téměř nikdy moc nového obsahu. Sprinty zahrnují i další aktivity jako technické úkoly, dokumentaci a návrhové úkoly.
Testovací případy se pak spouštějí s cílem především ověřit požadovanou funkcionalitu. Pokud se vyskytne nějaký problém, je kontaktován pouze příslušný vývojář (ten, kdo je zodpovědný za změny související s konkrétní chybou), aby problém co nejrychleji vyřešil.
Vývojáři tak stráví minimum času spojeného s funkčním testováním a mohou se i nadále soustředit na aktivity, které je nejvíce baví.
#2. Provádění regresních testů
Další částí funkčního testování je zajistit, že vše, co dosud fungovalo, bude fungovat i po následujícím vydání. K tomu slouží regresní testy.
Regresní testy jsou nejlepší, když jsou pravidelně udržovány a aktualizovány před každým vydáním. Podle specifických požadavků projektu je nejlepší, pokud jsou testy jednoduché, ale zároveň pokrývají většinu základních funkcí a důležitých komplexních procesů v rámci celého systému.
Obvykle má každý systém takové procesy, které se dotýkají mnoha různých oblastí, a ty jsou nejlepšími kandidáty pro regresní testy.
V některých případech dokonce regresní testy implicitně pokrývají i nové funkce ve sprintu, například pokud nový úkol ve sprintu změní část stávajícího procesu.
Ve většině případů tedy není příliš složité dokončit regresní testy spolu s testy funkčnosti nových úkolů sprintu, zvláště pokud se provádějí pravidelně před každým produkčním vydáním a frekvence produkčních vydání není příliš vysoká.
Trvejte na provádění testů zajištění kvality před každým uvedením do produkce
Test zajištění kvality (QA) je posledním krokem před uvedením do produkce a často se tento test vynechává jako nedůležitý. Zvláště pokud je scrum tým tlačen na dodávání nového obsahu.
Dokonce i uživatelé v podniku tvrdí, že se více zajímají o nové funkce než o zachování stávající funkčnosti nebo udržování nízkého počtu chyb. Ale opět – časem je to hlavní důvod, proč vývojářský tým nakonec musí zpomalit a i firemní uživatelé nedostanou, o co si žádají.
QA testy by měly provádět výhradně lidé mimo tým Scrum, ideálně samotní obchodní uživatelé ve vyhrazeném prostředí, které se co nejvíce blíží budoucímu produkčnímu prostředí. Alternativně může vlastníka produktu nahradit koncové uživatele.
V každém případě by to mělo být čistě funkční testování z pohledu koncového uživatele, bez jakéhokoli napojení na vývojářský tým Scrum. To poskytne poslední pohled na produkt a bude se používat způsobem, který nikdo z týmu Scrum možná nepředpokládal (není to ideální stav, ale rozhodně se to může stát). Stále je čas na opravy na poslední chvíli.
Případně se může ukázat, že tým Scrum dobře nepochopil očekávání, a v takovém případě se můžeme alespoň domluvit na dalším plánu, dlouho před skutečným uvedením do produkce. Opět to není ideální, ale je to mnohem lepší než přiznat selhání hned po nahlášení úspěšného produkčního vydání.
Kam se posunout dál?
Používání těchto postupů při každodenní práci se Scrumem vám může pomoci dosáhnout stabilnějších a předvídatelnějších návyků při vydávání sprintů. Nebudete muset zdržovat produkční vydání, trávit celý sprint přípravou na další vydání, ani nutit všechny v týmu Scrum dělat něco, co je nebaví a nevědí, jak efektivně dělat.
Ale nemusíte se u toho zastavit.
Jedním z témat, které je třeba zmínit, je zahrnutí testování výkonu. To se často ignoruje nebo se považuje za zbytečné, a proto se vyřadí v prvním kole „optimalizace Scrum aktivit“. Vždy jsem ale pochyboval o tom, jak lze očekávat, že se produkční systém bude s časem vyvíjet, pokud se pravidelně nekontroluje jeho výkon.
Další krok je zavedení automatizovaných testů.
Jednu skupinu automatizovaných testů (jednotkové testy v kanále) jsem již probral. Můžete ale vytvořit i plnohodnotné regresní testy typu end-to-end, které jsou plně automatizované a spouštějí se samy po každém nasazení do testovacího prostředí. To by vývojářský tým Scrum ještě více uvolnilo. Nicméně vývoj a údržba takových automatizovaných testů vyžaduje specializovaný tým. Stala by se z toho neustálá práce, protože kdykoli se změní produkční kód, některé stávající automatizované testy se mohou stát neplatnými a je třeba je aktualizovat. Je to úsilí, za které je jen málo kdo ochoten platit, přínosy pro vývojářský tým Scrum by však byly velké.
Tato témata ale přesahují rámec tohoto článku. Stejně tak nalezení správného načasování pro každý zde zmíněný typ testu tak, abyste to zvládli v rámci sprintu. Ráda se do toho ponořím příště!