Jak DevOps mění roli testování ve vývoji softwaru

DevOps je nejnovější fází vývoje v dlouhé řadě změn, které se dotýkají metodik vývoje softwaru. Od Waterfall po Agile, od Agile po DevOps, každý krok znamenal významné změny v rolích a aktivitách testerů. Ačkoli v některých organizacích není mezi těmito fázemi ostrá hranice, pro přehlednost je můžeme brát jednotlivě.

V prostředí Waterfall měli testeři plnou zodpovědnost za testovací strategii a její provádění. Testování bylo naším výsadním úkolem, kde jsme si nezávisle vymýšleli testovací scénáře, prozkoumávali software, hledali problémy a následně je hlásili. I když jsme spolupracovali s vývojáři, analytiky, designéry, manažery testování a dalšími, bylo nám jasné, že testování je naší výsadou. Byla to naše role a naše identita v týmu.

V agilním prostředí se testování stalo kolektivní odpovědností celého vývojového týmu. Tým společně přemýšlí o testovacích scénářích, prozkoumává software a nachází různé problémy, které se následně diskutují a řeší společně. Tento přístup přetváří i vztah mezi testováním a byznysem. Diskuze o požadavcích se stávají kolaborativními, prostřednictvím Behavior Driven Development, a význam akceptačních testů je oslaben každodenními interakcemi s vývojem, přičemž rychlá zpětná vazba z iterativních verzí zmírňuje potřebu rozsáhlých předchozích kontrol.

Znalost nástrojů, dovedností a praktik, které byly historicky považovány za okrajové vůči vývojovým týmům, otevírá nové možnosti pro rozšíření testovacích aktivit. Mezi příklady patří on-demand cloudová infrastruktura umožňující testování v produkčně podobném prostředí, zpětná vazba z A/B testů získaná díky zákaznickým metrikám nebo beta testovací skupiny poskytující rychlou zpětnou vazbu od uživatelů. Na druhé straně se i informace, které přicházejí zpět do vývojového týmu, mění. Problémy odhalené v reálném čase na monitorovacích panelech, zákaznické požadavky nebo neobvyklé analytické zprávy jsou okamžitě přeneseny do týmu k prioritizaci a řešení.

Automatizace je často považována za řešení pro urychlení testování, zejména ze strany těch, kteří vedou změny v tomto směru. Správné využívání nástrojů je zpravidla nejlepší cestou, jak zrychlit proces, a to nemusí nutně spočívat pouze v automatizaci testování ve vývojovém týmu. Vylepšení monitorování produkce a upozorňování na problémy, spolu s rychlým nasazením a možností rychlého rollbacku, mohou být stejně účinné.

V DevOps se klade důraz na spolupráci mezi vývojáři a profesionály v IT, a to i v oblastech, které byly dříve okrajové. Hlavní snahou je zajistit, aby celý proces vývoje, testování a nasazování softwaru byl rychlý, častý a spolehlivý. To v praxi znamená, že tester musí být schopen přizpůsobit své dovednosti dynamickým změnám v metodikách a procesech, což často vyžaduje nejen technické znalosti, ale i schopnost rychle se adaptovat na nové pracovní podmínky.

Za těchto podmínek musí tester zůstat agilní a připravený na neustálé změny v testovacích postupech a nástrojích. Je to doba, kdy se testování stává méně izolovaným a více součástí širšího cyklu vývoje. Týmová spolupráce, rychlé nasazování nových verzí a neustálé zlepšování procesů jsou klíčovými prvky úspěchu v prostředí DevOps.

Jaké výhody a nevýhody přináší metody testování v DevOps prostředí a jaké trendy formují budoucnost vývoje softwaru?

Mezi nejznámější metody testování patří dogfooding a dark launching. Obě metody mají své silné stránky, ale zároveň i několik zásadních nevýhod.

Dogfooding, tedy používání vlastní verze softwaru zaměstnanci firmy, je jedním z nejběžnějších způsobů, jak testovat aplikace před jejich oficiálním vydáním. Tento přístup má mnoho výhod, jako je možnost okamžitého zjištění chyb a získání zpětné vazby od lidí, kteří jsou s produktem blízce seznámeni. Nicméně, pokud jsou očekávání zaměstnanců od kvality softwaru vyšší než ta uživatelská, může se zpětná vazba stát nepřesnou. Zaměstnanci mohou nahlásit problémy, které nejsou pro běžného uživatele zásadní, což může vést k tomu, že se zaměří na detaily místo na skutečně kritické chyby. Naopak, pokud jsou očekávání nižší, může zpětná vazba chybět, protože zaměstnanci jsou ochotni tolerovat problémy, které by pro uživatele mohly být nepřijatelné.

Výzvou při dark launching je, že vývojáři často předpokládají, že uživatelé budou nové funkce používat stejně, jak je očekávají, což nemusí odpovídat skutečnému chování. Tento přístup tedy vyžaduje pečlivé testování a sledování chování uživatelů, aby bylo možné rychle reagovat na neočekávané problémy, které by mohly vzniknout. Doporučuje se spojit dark launch s postupným nasazováním nových funkcí (staged rollout), kdy se nová funkce postupně zpřístupňuje více uživatelům, což umožňuje vývojářům přizpůsobit aplikaci podle skutečných potřeb uživatelů.

Kromě těchto testovacích metod se významně mění i způsob, jakým jsou vytvářena a spravována testovací prostředí. Významným trendem v posledních letech je přechod na infrastrukturu jako kód (Infrastructure as Code), což umožňuje automatizovat tvorbu a správu serverů prostřednictvím kódu. Dříve se server musel manuálně nastavit, což bylo časově náročné a náchylné k chybám. Dnes je možné prostřednictvím kódu definovat, jak bude server nakonfigurován, co bude nainstalováno a jak bude spravován. Tato automatizace přináší nejen vyšší spolehlivost, ale i rychlost a flexibilitu. Infrastruktura jako kód umožňuje rychlejší nasazení změn, snadnější obnovu po chybách a menší riziko chyb při nasazování nových verzí.

Pro vývojáře je klíčové, že mohou psát nejen kód aplikace, ale i kód pro infrastrukturu, na které aplikace běží. To zajišťuje větší propojení mezi aplikací a jejími provozními požadavky. Výhody tohoto přístupu jsou nezanedbatelné, zejména při práci s cloudovými prostředími a kontejnery, které umožňují rychlé nasazení a škálování aplikací. Kromě toho se díky využívání nástrojů pro správu konfigurace, jako jsou Puppet, Chef, Ansible a SaltStack, zjednodušuje správa rozsáhlé infrastruktury a minimalizuje potřeba ručního zásahu.

Jedním z klíčových aspektů, které je důležité chápat v souvislosti s těmito změnami, je propojení vývoje aplikací s infrastrukturou. Automatizace tohoto procesu nejen zvyšuje efektivitu, ale i snižuje lidské chyby, což je zvláště důležité v kontextu vysokých nároků na kvalitu a rychlost v dnešním softwarovém vývoji. Tento trend směřuje k modelu, kde vývojář nejen píše aplikace, ale i spravuje prostředí, ve kterém aplikace běží.

Jak najít rovnováhu v testování softwaru: Případová studie DevOps a změny v roli testera

V prostředí DevOps je otázka rovnováhy v testování softwaru klíčová. Vzhledem k rychlému vývoji a neustálým změnám v týmech je důležité pochopit, jak se orientovat v dynamickém prostředí testování, které se neustále vyvíjí. Jedním z hlavních indikátorů správného přístupu k testování je zjištění, kdy je testování příliš povrchní a kdy naopak příliš hluboké. Tato rovnováha se často nazývá „pendulem testování“, které se pohybuje mezi dvěma krajními body: testování, které je příliš detailní, a testování, které opomíjí klíčové aspekty kvality.

Pokud vaše testování vede k příliš velkému množství chyb, které nejsou opraveny, nebo pokud ve vašem týmu kolegové pravidelně odebírají rozsah testování, může to být znakem, že testujete příliš hluboko. Naopak, pokud jste svědky situace, kdy jsou požadavky na testování považovány za přehnané nebo kdy kolegové testování zcela delegují na testery, znamená to, že testování je příliš povrchní. Tento výkyv ve stylu testování může být příčinou nespokojenosti v týmu, a proto je nezbytné věnovat pozornost zpětné vazbě od kolegů a nadřízených, kteří mohou přímo poukázat na to, kdy je potřeba přehodnotit přístup k testování.

Testování není jen technickou činností, ale i kulturou. Pokud v rámci týmu přetrvává tendence delegovat testování na jednoho konkrétního člena týmu, například testera, může se snadno stát, že ostatní členové týmu přestanou cítit spoluvlastnictví kvality produktu. To může vést k nežádoucímu efektu, kdy výsledky testování nejsou optimální, protože se o ně stará pouze jedna osoba, zatímco zbytek týmu ignoruje odpovědnost za kvalitu.

Ačkoliv se může zdát, že testování by mělo být zaměřeno výhradně na detailní detekci chyb, je třeba si uvědomit, že testování by mělo zahrnovat i ověřování funkčnosti, uživatelské zkušenosti a shody s požadavky na software. V některých případech může být hlubší testování žádoucí, protože může odhalit skryté problémy, které se mohou v budoucnosti stát zásadními. Jiní však mohou tvrdit, že příliš důkladné testování může zpomalit celý proces vývoje. K nalezení správné rovnováhy je tedy důležité testování pravidelně přehodnocovat a adaptovat.

V prostředí DevOps dochází k významné změně v roli testera. Testování se již nevykonává pouze jako fáze před nasazením kódu do produkce, ale probíhá neustále v průběhu celého životního cyklu softwaru. Tester se tedy stává nejen tím, kdo hledá chyby, ale i tím, kdo spolupracuje s vývojáři a operátory a pomáhá při analýze dat produkčního prostředí. Taková změna představuje velkou kulturní změnu, kde testování není oddělené od ostatních činností, ale je součástí kontinuálního procesu vývoje a nasazování.

Přístup k testování v DevOps se liší od tradičního přístupu v tom, že kvalita není hodnocena pouze během vývoje, ale především skrze interakce uživatelů s produkčním systémem. Z tohoto pohledu je důležité mít nástroje, které umožní testování přímo v produkčním prostředí. Tester tedy vytváří nástroje, které mohou sledovat chování aplikace naživo, což je přístup velmi podobný monitoringu, ale zaměřený na scénáře, které mohou mít přímý dopad na uživatele.

Pokud jde o změnu role testera, nelze pominout názor některých organizací, které se rozhodly tuto roli zcela eliminovat. Tento krok vychází z předpokladu, že testování může provádět každý člen týmu, a to buď jako součást jejich vývojového procesu, nebo přímo na základě uživatelských interakcí v produkci. Některé organizace argumentují, že v prostředí DevOps již není potřeba specializovaného testera, pokud jsou ostatní členové týmu dostatečně školeni a odpovědní za kvalitu kódu.

Pokud je tester v týmu přítomen, jeho úloha se neustále vyvíjí. Testování není pouze o nalezení chyb, ale také o analýze kvality z širšího hlediska. V roli kouče a poradce může tester spolupracovat s ostatními členy týmu na definování testovacích scénářů, pomáhat při tvorbě nástrojů pro automatizované testování a monitorování a tím zajišťovat, že kvalitní testování bude prováděno v každé fázi vývoje.

S tímto přístupem musí tester udržovat flexibilitu a neustále přizpůsobovat svůj přístup k testování aktuálním potřebám týmu. Při dlouhodobém testování je důležité se vyvarovat stagnace a pravidelně přehodnocovat použité metodologie. Pro tento účel může být užitečné periodicky provádět „bump“ v testování, což znamená experimentování s novými heuristikami, změnami testovacích dat nebo novými persona modely uživatelů. Tento přístup může odhalit nové problémy, které mohou být přehlédnuty běžným testováním.