Jak správně řídit testování v DevOps a minimalizovat rizika?

V rámci vytváření strategie pro testování softwaru v organizaci, zejména v prostředí DevOps, se výběr metod testování může jevit jako obtížný a náročný úkol. Většina organizací nebude implementovat každý testovací přístup, ale spíše si vybere soubor praktik, které vyhovují jejich potřebám. V organizacích, které usilují o častější vydávání verzí produktů, stále zůstává potřeba evaluace kvality produktu prostřednictvím testování. Testování však nezmizí. Naopak, pokud je cílem častější vydávání verzí, testování musí být pružné a schopné rychlé reakce.

Rychlá zpětná vazba, jak ji DevOps propaguje, je klíčová. Ta závisí na vyspělých komunikačních kanálech, které umožňují nejen vývojářům, ale i operacím rychlý přístup k důležitým informacím o stavu produktu. Čím dříve získáte zpětnou vazbu od týmu operací, tím dříve můžete identifikovat případné problémy v produktu. To přináší zásadní otázku: jak testovat před vydáním softwaru, když je důležité, aby celý proces fungoval rychle a efektivně?

Jerry Weinberg ve své knize říká, že "kvalita je hodnotou pro určitou osobu". Tato osoba, která má klíčovou roli v hodnocení kvality produktu, je konečný uživatel. Pokud mu umožníte testovat produkt, získáte přímý názor na hodnotu a kvalitu, která vychází od nejdůležitějšího stakeholdera – samotného uživatele. Tento přístup je pro tradiční testery výzvou, protože často zastávali roli "hlasu uživatele" uvnitř vývojového týmu. Na druhou stranu však každý chce vydat produkt, který má kvalitní a stabilní základnu, a to nejen z pohledu funkčnosti, ale i z pohledu uživatelské zkušenosti.

V kontextu strategie testování v DevOps je důležité se zaměřit na konkrétní přístupy a přemýšlet o rizicích spojených s vydáním. Prvním krokem je vytvoření rizikové dílny, která slouží k diskuzi o rizicích spojených s testováním. I když je běžné, že testování je založeno na řízení rizik, diskuse o těchto rizicích bývá v praxi relativně vzácná. V DevOps je kladeno důraz na to, aby každý člen týmu měl stejné pochopení rizik a měl možnost se aktivně podílet na rozhodování.

Riziková dílna by měla začít jednoduchým cvičením, kde se jednotliví členové týmu postaví podle svého názoru na aktuální úroveň rigoróznosti testování v produkčním prostředí. Tento vizuální přehled poskytuje rychlý náhled na to, jak členové týmu vnímají současný stav a jak by se chtěli v budoucnu posunout. Tento přístup nejen zjednodušuje identifikaci rozdílů v názorech, ale i otevírá cestu k otevřenější komunikaci o tom, co si kdo představuje pod pojmem "kvalitní testování".

Při dalším kroku se zaměřujeme na identifikaci konkrétních rizik. Účastníci dílny by měli napsat na samolepicí lístky konkrétní rizika, která vidí ve své práci. Při brainstormingu by se měli soustředit na samotná rizika, nikoliv na konkrétní testovací činnosti, jako je například "testování kompatibility prohlížečů". Místo toho by měli zmínit konkrétní riziko, například "produkt nemusí fungovat na různých platformách". Tento způsob práce vytváří široký a vyvážený seznam rizik, který zahrnuje různé aspekty, jako je funkčnost, kompatibilita, uživatelská zkušenost, dostupnost, bezpečnost a další.

Konečným cílem tohoto procesu je seřadit rizika podle jejich závažnosti a naléhavosti a vytvořit prioritizovaný backlog rizik. Nejvyšší prioritu by měly mít ty problémy, které mohou nejvíce ovlivnit výkon a stabilitu produktu. Následně by se měl tým zaměřit na způsoby, jak těmto rizikům předcházet nebo je minimalizovat v rámci každého vydání.

Testování v DevOps je tedy v konečném důsledku procesem, který spojuje rychlost s efektivitou, flexibilitou s bezpečností. Každá organizace musí najít rovnováhu mezi těmito faktory, aby zajistila stabilní a hodnotné vydání produktů.

Jak vyvažovat rizika v DevOps: Nový přístup k testování a mitigaci rizik

V rámci DevOps se koncept zmírnění rizik může vztahovat na různé aktivity. Ne vždy to musí být testování – mohou to být i změny v programovacích postupech, designové workshopy nebo monitoring ve výrobě. Při diskusi o mitigaci rizik je zajímavé položit otázku: "Jak pozdě mohou být rizika mitigována?" Není vždy nutné rizika mitigovat ještě před dodáním, mohou být řešena i v produkčním prostředí. Čím více rizik odložíme, tím rychleji můžeme doručit produkt, ale zároveň roste pravděpodobnost, že se nějaký problém objeví až v produkci. Klíčem je najít rovnováhu, která vyhovuje konkrétní organizaci.

V rámci vytváření testovací strategie se doporučuje uspořádat workshop zaměřený na rizika. Tento workshop pomáhá definovat, jaká rizika v organizaci existují a jakým způsobem je lze mitigovat. Výsledky této aktivity následně tvoří základ pro tvorbu testovací strategie.

Jedním z nejrozšířenějších konceptů v agilních testovacích strategiích je testovací pyramida. Pyramida byla původně vyvinuta Michaelem Cohnem v roce 2009 a slouží jako vizuální rámec pro plánování automatizovaných testů. Pyramidová struktura zahrnuje tři vrstvy: základní jednotkové testy, střední úroveň pro integrační testy a vrchol pyramidy pro testy uživatelského rozhraní. Testovací pyramida doporučuje, aby týmy vytvářely větší počet jednotkových testů, méně integračních testů a ještě méně testů uživatelského rozhraní.

V posledních letech se však stále více odborníků v oblasti testování začalo zamýšlet, zda je pyramida ideálním modelem pro všechny projekty. V článku "Heresy of the Test Pyramid" John Ferguson Smart poukazuje na to, že ne všechny testovací strategie musí následovat tuto strukturu. V roce 2015 Richard Bradshaw na workshopu MEWT prezentoval alternativní model, který zahrnoval nástroje pro automatizaci a dovednosti testerů. Podobně Marcel Gehlen uvádí, že nemusíme striktně dodržovat původní vrstvy pyramidy, ačkoli její vizuální forma může stále zůstat užitečná.

Dalším zajímavým přístupem, který se objevil v roce 2017, je model "filtru chyb" navržený Noah Sussmanem. Tento model posouvá koncept testování na další úroveň tím, že se zaměřuje na to, jak chyby procházejí jednotlivými úrovněmi testování. Například v případě testování funkce registrace uživatele mohou být některé chyby snadno zachyceny při jednotkových testech, zatímco jiné větší problémy mohou být odhaleny pouze při testech koncových uživatelských scénářů.

Sussmanův model si klade za cíl ukázat, jak mohou chyby migrovat mezi různými vrstvami aplikace. Když některé chyby nejsou zachyceny na nízké úrovni, mohou se vyvinout v problémy většího rozsahu, které je těžší opravit až ve fázi end-to-end testování. Tento přístup ukazuje, že testovací procesy musí být flexibilní, aby dokázaly zachytit chyby jak na jednotkové, tak na integrační úrovni a při testování celkového systému.

Filtr chyb v DevOps prostředí navíc přináší důležitou myšlenku: testování musí být kontextuální. Nemělo by se zaměřovat pouze na samotný vývoj kódu, ale mělo by zahrnovat širší souvislosti, které zahrnují i provoz. To znamená, že strategie automatizovaného testování by měla zohlednit nejen vývojové fáze, ale i následný provoz, kde se mohou objevit nové druhy problémů – například díky interakci uživatelů nebo jiných externích systémů.

Jak rychlé dodávky softwaru ovlivňují testování a jak se připravit na rychlý vývoj?

V dnešní době je vývoj softwaru neoddělitelně spjatý s rychlostí dodávky nových verzí. Tlak na rychlé uvedení produktů na trh, efektivitu a konkurenceschopnost vede k přehodnocení tradičních metod vývoje a testování. Tento přístup si žádá nové metodologie a přístupy k testování, které musí být integrovány přímo do procesů vývoje a nasazování softwaru.

Spotify, například, ve své praxi ukázalo, jak technologie jako Docker a Helios mohou usnadnit nasazování a testování v reálném čase, umožňující vývojářům soustředit se na novinky místo na komplikované administrativní úkoly spojené s nasazováním. Tento přístup není bez rizika. V okamžiku, kdy se dodávky softwaru zrychlují, je zásadní mít systém monitorování a zpětné vazby, který umožňuje rychlou detekci problémů a jejich okamžité řešení.

Zde přichází do hry automatizace testování, která se stává neoddělitelnou součástí procesu. Automatizované testy poskytují okamžitou zpětnou vazbu o kvalitě softwaru, což je nezbytné, pokud chcete udržet rychlost nasazení bez kompromisů v kvalitě. Testování v produkci, jak ukazují zkušenosti s Etsy, je jedním z moderních přístupů, kde se testy provádějí přímo na živých systémech. Tento přístup má své výhody, ale také rizika, která je potřeba pečlivě řídit a neustále optimalizovat.

Dalším důležitým trendem je používání nástrojů pro správu konfigurací, jakými jsou Ansible, Puppet nebo Chef. Tyto nástroje umožňují automatizovat nasazování a správu infrastruktury, což snižuje manuální zásahy a zvyšuje opakovatelnost procesů. Důležité je však mít na paměti, že správná konfigurace a její dokumentace je klíčová pro úspěšné nasazení a minimalizaci chyb. Přehledná a dobře dokumentovaná infrastruktura je základem pro zajištění bezpečnosti a stability.

Nezbytnou součástí tohoto procesu je také správné monitorování a alerting. Pokročilé nástroje monitorování umožňují odhalovat potenciální problémy dříve, než se stanou kritickými. To zahrnuje nejen sledování samotného softwaru, ale i infrastruktury, na které běží, a využívání metrik pro prediktivní analýzu chyb. Efektivní alerting zase umožňuje vývojářům a operátorům reagovat na problémy ještě před tím, než ovlivní uživatele.

V tomto kontextu je důležité si uvědomit, že rychlý vývoj softwaru a jeho nasazování nejsou jen o technologiích. Kultura ve firmě, která podporuje experimentování, otevřenost k chybám a rychlé učení z nich, je klíčová pro úspěšné zavedení těchto metodik. Zajistit efektivní komunikaci mezi vývojáři, testery a operátory je zásadní pro minimalizaci rizik spojených s nasazováním nových verzí.

Kromě těchto technických aspektů je třeba také věnovat pozornost samotné metodice testování. Testování není jen o detekci chyb, ale také o zajištění, že produkt splňuje požadavky uživatelů a je stabilní v reálných podmínkách. Důležitou roli zde hraje explorativní testování, které umožňuje testerům zaměřit se na oblasti, které automatizované testy nemohou pokrýt. Tento typ testování je obzvláště efektivní v prostředí rychlých změn, kdy je nutné přizpůsobit se neustále se vyvíjejícím podmínkám.

Jak vytvořit a zhodnotit testovací strategii v cross-funkčních týmech?

Přestože byste si mohli myslet, že specialista na testování je jedinou osobou v cross-funkčním týmu, která může definovat testovací strategii, skutečnost je složitější. Metoda, jakou se strategie určuje a sdílí, je klíčová. Tester, který nedokáže jasně vysvětlit, jak došel k rozhodnutím týkajícím se testovací strategie, na sebe bere vysoké riziko tím, že přebírá odpovědnost za volby, které nemusí být výhradně v jeho kompetenci. Během testování odborný tester neustále činí rozhodnutí, která ovlivňují strategii testování týmu. Uvědomuje si kompromisy, které je třeba učinit při výběru jedné metody testování před jinou, dopady těchto rozhodnutí na pokrytí testy a jejich vliv na celkovou kvalitu produktu. Mnozí však o těchto rozhodnutích přemýšlejí a rozhodují se izolovaně, aniž by svou změnu strategie sdíleli s týmem. V agilních týmech, kde je testování otevřeno pro všechny, může být strategické myšlení o testování považováno za něco, co se týká pouze specialistů, což znamená, že členové týmu testují bez porozumění tomu, proč něco testují a jaká rozhodnutí byla za tímto testováním.

Retrospektiva testovací strategie je interaktivní a dynamický proces, který by měl trvat přibližně jednu hodinu. Specialisté na testování by tuto retrospektivu měli facilitovat, ale nezasahovat do samotného vytváření vizualizace, aby nedošlo k ovlivnění rozhodnutí ostatních členů týmu. Tato retrospektiva by měla mít čtyři základní prvky: čas, kdy je celý tým k dispozici, lepící papírky v několika barvách a velký povrch, na který je možné papírky nalepit, jako je velký stůl nebo prázdná zeď.

Proces retrospektivy začíná jasným stanovením účelu. Tým bude vizualizovat testovací strategii a sdílet pochopení o tom, jaké testování probíhá a proč. K tomu použijete papírky v různých barvách, které označují následující:

• Fialová – součást naší testovací strategie a provádíme to.

• Růžová – součást naší testovací strategie, ale neprovádíme to.

• Žlutá – není součástí naší strategie, ale mělo by být.

Každý člen týmu umístí své papírky na časovou osu tak, jak si myslí, že jednotlivé testovací aktivity probíhají. Po uplynutí pěti minut bude povrch pokrytý různě rozmístěnými papírky, které následně tým společně roztřídí a umístí na správná místa v časové ose.

Po vizualizaci následuje diskuze, která pomáhá odhalit klíčová rozhodnutí, jež utvářela současnou testovací strategii. Některé z otázek, které mohou vyvstat, zahrnují:

• Jsou některé skupiny papírků rozděleny do různých barev? Proč?

• Používají lidé různé názvy pro stejné testovací aktivity? Proč?

• Jsou některé aktivity v testovací strategii, které se neprovádějí? Proč?

• Chceme do strategie přidat nějaké chybějící aktivity?

• Chybí některé aktivity z celé vizualizace? Jaké?

Tyto otázky odhalí nedorozumění ohledně současného stavu testování a pomohou identifikovat klíčová rozhodnutí, která vedla k dnešní podobě testovací strategie. Výsledná vizualizace bude produkt celého týmu, což zvyšuje pravděpodobnost, že se do ní všichni budou více investováni.

Pokud tým není jednotný ohledně definice testování, mohou nastat nesrovnalosti. Například při testování end-to-end může jeden člen týmu považovat tuto aktivitu za součást strategie, zatímco jiný si myslí, že se neprovádí vůbec. V jednom případě členové týmu zjistili, že používají termíny jako „manuální testování“, „explorativní testování“ a „akceptační testování“ zaměnitelně, což vedlo k nejasnostem. Tento problém se vyřešil tím, že se tým rozhodl používat termín „explorativní testování“.

Takové retrospektivy poskytují cenné informace, protože odhalují neshody i v oblasti, kde by se měla testovací strategie jevit jako zcela jasná. Mnohé nejasnosti mohou být způsobeny tím, že různí členové týmu mají odlišné představy o tom, co testování znamená.

V některých případech může být užitečné zavést alternativní přístup, například podle metody Seana Cresswella, který rozdělil aktivity podle toho, kdo je vykonává (tester, vývojář, jiný člen týmu) a následně je umístil do matice, která ukazuje, jak často se daná aktivita vykonává ve srovnání s tím, jak často by měla být vykonávána. Tento přístup umožňuje jiný pohled na distribuci testování v týmu a přináší příležitost rozpoznat přínosy vývojářů, kteří se podílejí na testování, což může zůstat často nepovšimnuto.