Lekce 4 - Testování v průběhu SDLC podruhé - DevOps a automatizace

V předchozím kvízu, Kvíz - Základy testování a testovací proces, jsme si ověřili nabyté zkušenosti z předchozích lekcí.

V dnešní lekci se podíváme na test-driven development, vysvětlíme si, co je DevOps a shift-left přístup. Nakonec si vysvětlíme retrospektivy a zlepšování procesů.

Metodiky testování

Test-driven development, acceptance test-driven development a behavior-driven development jsou metodiky, které využívají testy jako hlavní nástroj pro řízení vývoje. Uplatňují princip včasného testování a shift-left, což znamená, že testy jsou vytvářeny ještě před samotným psaním kódu a jsou ideální pro iterative development.

Test-driven development

Psaní kódu je řízeno pomocí test casů místo rozsáhlého návrhu softwaru. Nejprve jsou sepsány testy a až následně kód, a to tak, aby těmto testům vyhovoval. Následně mohou být testy a kód refaktorovány. To znamená úpravu a zlepšení vnitřní struktury kódu, aniž se změní jeho chování nebo funkčnost. Cílem refaktorování je zlepšit čitelnost a srozumitelnost kódu, zjednodušit údržbu a usnadnit budoucí úpravy, odstranit duplicitní části kódu nebo zbytečné složitosti. Vývojář pracující na funkci pro přihlášení uživatelů nejprve napíše testy, které ověřují, zda zadání správného uživatelského jména a hesla umožní přihlášení. Až poté vývojář napíše samotnou funkci tak, aby tyto testy úspěšně prošly:

Acceptance test-driven development

Acceptance test-driven development odvozuje testy z acceptance criteria (akceptačních kritérií) jako součást procesu návrhu systému. Daná část aplikace je vytvořena tak, aby vyhovovala testům napsaným před samotným vývojem. Před implementací funkce pro správu objednávek tým nejprve sepíše acceptance criteria, například to, že uživatel musí vidět potvrzení objednávky. Na základě těchto kritérií jsou napsány testy, které ověřují, že aplikace splňuje požadavky, a poté je vytvořen samotný kód:

Behavior-driven development

V behavior-driven development je požadované chování aplikace popsáno test casy formulovanými v jednoduché formě přirozeného jazyka srozumitelného pro zainteresované strany. Obvykle se využívá formát Given/When/Then – vstup/podmínka/ak­ce. Test casy jsou následně automaticky přeloženy do spustitelných testů. Tým popíše funkci pro výběr doručení z pohledu uživatele: když uživatel například vybere způsob dopravy, zobrazí se souhrn objednávky. Tento popis je přeložen do automatizovaných testů, které ověřují, že systém skutečně funguje podle těchto pravidel:

Testy mohou být automatizovány pro všechny výše uvedené přístupy. Cílem je podpořit kvalitu při budoucích úpravách nebo refaktoringu.

DevOps a testování

DevOps je přístup k vývoji softwaru, který vyžaduje úzkou spolupráci mezi vývojovými, testovacími a provozními týmy, aby společně dosahovaly stanovených cílů. Tento přístup mění organizační kulturu, překonává bariéry mezi týmy a staví na jejich rovnocenném významu. DevOps podporuje týmovou autonomii, rychlou zpětnou vazbu, využívání integrovaných nástrojů a technik, jako je continuous integration – CI (průběžná integrace) a continuous delivery – CD (průběžné dodávání). To umožňuje rychlejší tvorbu, testování a nasazení kvalitního kódu prostřednictvím DevOps pipeline:

• Continuous integration (průběžná integrace) je proces, kdy vývojáři často odesílají změny kódu do centrálního úložiště, kde jsou tyto změny automaticky sestaveny a otestovány. To zajišťuje, že nový kód neporušuje existující funkcionalitu a problémy jsou zachyceny brzy.
• Continuous delivery (průběžné dodávání) navazuje na CI tím, že automatizuje nasazení kódu do testovacího nebo produkčního prostředí. Tento proces zaručuje, že jakmile kód projde všemi testy, může být bezpečně nasazen do produkce.
• DevOps pipeline kombinuje CI a CD v automatizovaný proces, který zahrnuje sestavení, testování, nasazení a monitorování kódu. To umožňuje týmu doručovat nové funkce či opravy rychle, bezpečně a bez ztráty kvality softwaru:

Výhody DevOps

Z pohledu testování má DevOps určité výhody. Poskytuje rychlou zpětnou vazbu o kvalitě nového kódu a o nepříznivém vlivu na dosavadní funkčnost systému nebo komponenty. Díky CI podporuje přístup shift-left při testování tím, že motivuje vývojáře k psaní kvalitního kódu podporovaného testováním komponent a statickou analýzou (static analysis). Propaguje automatizované zpracování (např. CI/CD), které usnadňuje vytváření stabilních testovacích prostředí. Zvyšuje důraz na nefunkcionální charakteristiky kvality, jako je výkon nebo spolehlivost. Automatizací prostřednictvím pipeline snižuje potřebu opakovaného manuálního testování. Minimalizuje riziko regrese díky rozsahu a míře automatických regression testů.

Rizika a nevýhody DevOps

DevOps má však také některá rizika a nevýhody. Musí být definovány a zavedeny DevOps pipeline. Musí být zavedeny a udržovány nástroje CI/CD. Automatické testy vyžadují dodatečné investice a může být obtížné je vytvořit a udržovat.

Přestože DevOps předpokládá vyšší rozsah automatického testování, nelze opomíjet ani manuální testování, a to zejména z pohledu koncového uživatele.

Praktický příklad

Představme si tým, který vyvíjí aplikaci pro správu skladových zásob pomocí DevOps přístupu. Vývojáři pravidelně odesílají nové verze kódu do centrálního úložiště. Každá změna spouští automatizovanou CI/CD pipeline, která zahrnuje spuštění automatizovaných testů. Pro novou funkci, která umožňuje automatické přidávání zboží na sklad po přijetí dodávky, tým napíše automated regression tests. Automatizované nástroje shromažďují data o výkonnosti a stabilitě, jako například dobu odezvy při aktualizaci zásob. Pokud se objeví problémy, tým okamžitě dostane zpětnou vazbu a může provést opravy.

Přístup shift-left

Princip včasného testování, známý jako shift-left, posouvá testování do dřívějších fází SDLC. Tento přístup doporučuje začít testovat co nejdříve, ale nezanedbává význam testování ani v pozdějších fázích vývoje.

Existují některé osvědčené postupy, na kterých lze demonstrovat aplikaci tohoto přístupu:

• Revidování specifikací z pohledu testování, které nachází potenciální defekty, jako jsou nejednoznačnosti, neúplnosti a nesrovnalosti.
• Psaní test cases před napsáním kódu a spuštění kódu v sadě testovacího vybavení během vývoje kódu.
• Používání CI, nebo lépe CD, protože přichází s rychlou zpětnou vazbou a automatizovanými testy komponent (automated component tests), které jsou společně s kódem uloženy do repozitáře.
• Spouštění static analysis zdrojového kódu před dynamic testingem nebo jako součást daného automatizovaného procesu.
• Provádění nefunkcionálních testů hned v úrovni testování komponent. Jedná se také o formu přístupu shift-left, jelikož obvykle jsou tyto typy testů prováděny v pozdějších fázích SDLC, kdy je k dispozici kompletní systém a odpovídající testovací prostředí.

I když zavedení shift-left může zpočátku zvýšit náklady, například na školení týmu, v dlouhodobém horizontu šetří čas i peníze. Důležité je, aby všichni zúčastnění uznávali jeho přínosy a aktivně jej podporovali.

Retrospektivy a zlepšování procesů

Retrospektivy, známé také jako poprojektové schůzky, se obvykle konají na konci projektu, iterace, milníku nebo dle potřeby. Načasování závisí na modelu SDLC a účastníky jsou testeři, vývojáři, architekti, vlastníci produktů a byznysoví analytici. Hlavním cílem retrospektivy je probrat následující otázky:

• Co bylo úspěšné a mělo by být zachováno?
• Co se nepovedlo a dalo by se zlepšit?
• Jak implementovat návrhy na zlepšení a zajistit v budoucnu trvalou úspěšnost?

Výstupy retrospektiv by měly být zaznamenány a zahrnuty do souhrnného reportu z testování. Jsou klíčové pro kontinuální zlepšování, a proto je důležité jejich důsledné dodržování. Mezi typické výhody retrospektiv z pohledu testování patří zvyšování efektivity a účinnosti testů, zvyšování kvality testwaru, stmelování týmu a vzájemné učení, zlepšování kvality testovací báze a zlepšování spolupráce mezi vývojem a testováním.

Zdrojem této lekce jsou Učební osnovy – Certifikovaný tester základní úrovně ver. 4.0. Copyright © 2023 autoři verze 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (předseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (místopředseda), Eshraka Zakaria

V příští lekci, Úrovně testování, si rozlišíme různé úrovně testování a různé typy testů a nakonec si shrneme konfirmační a regresní testování.