Testovací strategie a audit

Smoke, sanity a akceptační testy: co znamenají a kdy je spustit

Smoke, sanity a akceptační testy se v týmech často zaměňují, přestože odpovídají na odlišné otázky. Smoke ověřuje, zda je build nebo nasazení vůbec smysluplně testovatelné, sanity bývá úzkou kontrolou změny nebo stability a akceptační testování posuzuje shodu s akceptačními kritérii a potřebou uživatele či organizace. Samotný název však nestačí: tým musí u každé sady definovat cíl, rozsah, vstupy, vlastníka a rozhodnutí, které výsledek ovlivní.

Proč se stejná slova používají různě

Tato označení nevytvářejí tři technické složky, do kterých lze každý test zařadit jen jednou. Popisují především účel konkrétního běhu. Stejný automatizovaný scénář nákupu může být součástí smoke sady po nasazení, regresní sady před releasem a akceptačního ověření uživatelského příběhu. Mění se důvod spuštění, požadovaný důkaz a reakce na výsledek.

Největší zmatek působí slovo sanity. Některé týmy jím označují úzkou kontrolu opravené oblasti, jiné malou podmnožinu regrese a další ho používají téměř jako synonymum smoke testu. Není proto bezpečné převzít název z cizího projektu a předpokládat stejný význam. V tomto článku používáme časté praktické rozlišení: smoke je široká a mělká kontrola ověřitelnosti buildu či nasazení, sanity je úzká kontrola změněné oblasti a akceptační testování ověřuje, zda řešení splňuje dohodnutou potřebu.

Smoke test: lze s tímto buildem smysluplně pracovat?

Smoke test projde malý počet základních kontrol napříč systémem. Má rychle odhalit, že se build nespustí, služba neodpovídá, databázová migrace selhala, konfigurace směřuje na nesprávnou závislost nebo nelze otevřít kritickou cestu. Je široký, protože se dotkne důležitých částí, a mělký, protože nezkouší mnoho kombinací ani podrobné hraniční případy.

Po nasazení e-shopu může smoke sada ověřit, že se načte katalog, funguje přihlášení, produkt lze vložit do košíku, checkout se otevře a objednávkové API přijme kontrolovaný požadavek. Nemá dokazovat správnost všech slev, způsobů dopravy a plateb. Zelený smoke výsledek znamená „prostředí a základní cesty jsou připravené na další testování“, ne „release je bezpečný“.

Takové použití podporuje také ISTQB Advanced Level Test Analyst syllabus, který smoke test uvádí při ověření připravenosti testovacího prostředí. V praxi jej lze spustit i nad lokálním buildem, integračním prostředím nebo produkčním nasazením. Rozsah se mění podle prostředí: v produkci mají být scénáře kontrolované, nedestruktivní nebo po sobě bezpečně uklidit data.

Sanity test: funguje změněná oblast natolik, aby mělo smysl pokračovat?

Sanity test se často používá po menší změně, opravě chyby nebo novém buildu k úzkému ověření dotčené funkce a jejího nejbližšího okolí. Pokud se upravil výběr výdejního místa, sanity sada může zkontrolovat jeho načtení, výběr, zachování při průchodu checkoutem a uložení identifikátoru do objednávky. Neověřuje přitom celý e-shop.

Jeho hranice se částečně překrývají s confirmation testingem, tedy retestem opravy, a s cílenou regresí. Rozdíl si musí tým pojmenovat. Může se dohodnout, že retest vždy reprodukuje původní defekt, zatímco sanity balíček ověří základní stabilitu celé měněné oblasti. Jiný tým může termín sanity úplně vynechat a používat název „cílená regrese“. Obě možnosti jsou použitelné, pokud z výsledku každý rozumí rozsahu.

Pro sanity sadu neexistuje univerzální počet scénářů ani časový limit. Má být dostatečně úzká pro včasnou odpověď a dostatečně hluboká pro rozhodnutí, zda pokračovat širším testováním. Pokud se z ní časem stane hodinová kontrola nesouvisejících funkcí, přestala tento účel plnit, i když si ponechala původní název.

Akceptační testy: splňuje řešení dohodnutou potřebu?

Akceptační testování validuje, zda řešení splňuje podmínky, za kterých je příslušné zainteresované strany přijmou. Testovacím základem mohou být akceptační kritéria uživatelského příběhu, byznys pravidla, provozní požadavky, smlouva nebo regulatorní podmínky. Kontrola může být manuální i automatizovaná a může začít už během vývoje, pokud tým kritéria převede na spustitelné příklady.

Akceptační testování proto není pouze user acceptance testing (UAT), při kterém budoucí uživatel zkouší hotový systém. ISTQB Foundation Level syllabus mezi formy akceptačního testování řadí uživatelské, provozní, smluvní a regulatorní akceptační testování i alpha a beta testování. Pro konkrétní produkt mohou být relevantní jen některé z nich.

Příkladem funkčního akceptačního kritéria je: „Pokud objednávka obsahuje pouze zboží povolené pro výdejní místo a adresa je v podporované zemi, zákazník může vybrat výdejní místo a jeho název se zobrazí v potvrzení.“ Provozní akceptace může navíc ověřit, že kód výdejního místa dorazí do skladu, podpora ho vidí v administraci a selhanou integraci lze dohledat. Samotná úspěšná prezentace funkce na demu tyto důkazy nenahrazuje.

Porovnání na jedné straně

Tabulka je východisko, ne univerzální norma pro názvy jobů v pipeline. Pokud tým používá „sanity“ jinak, má upravit definici ve vlastním slovníku a název doplnit přesnějším popisem, například checkout-change-sanity.

Jaké vstupy a výstupy potřebuje každý běh

Bez jasných vstupů se rozsah mění podle toho, kdo test spustil. Bez jasného výstupu sice vznikne report, ale nikdo neví, co s ním udělat.

Smoke potřebuje identifikaci buildu a prostředí, dostupné základní závislosti, kontrolovaná testovací data a seznam kritických sond. Výstup má uvést, které komponenty byly dostupné, kde scénář skončil a zda lze pokračovat dalšími testy. Pokud běží po nasazení, je třeba rozlišit chybu artefaktu od konfigurace prostředí.

Sanity potřebuje popis změny, dotčené komponenty, původní defekt nebo akceptační příklady a očekávané související vazby. Výstup nemá být jen „5 z 5 prošlo“, ale také potvrzení testované verze a hranic: například výdejní místo funguje, ale doprava kurýrem zatím nebyla součástí běhu.

Akceptační testování potřebuje schválená a testovatelná kritéria, správné role, reprezentativní data a osobu oprávněnou vyhodnotit výsledek. Výstupem jsou důkazy ke kritériím, odchylky, otevřená rizika a rozhodnutí. Screenshot může být užitečný artefakt, ale neprokáže zpracování v API, databázi nebo navazujícím systému.

Kam patří v pipeline a release procesu

Typické pořadí vypadá takto:

1. Build projde statickými, unit a komponentovými kontrolami.
2. Po nasazení do testovacího prostředí smoke test potvrdí, že prostředí a kritické části jsou ověřitelné.
3. Sanity test nebo cílený retest prověří změnu a její nejbližší okolí.
4. Širší regresní sada hledá nežádoucí účinky v dalších oblastech.
5. Akceptační testy potvrdí konkrétní kritéria a připravenost z pohledu příslušných zainteresovaných stran.
6. Po produkčním nasazení může bezpečný smoke test potvrdit skutečně nasazenou konfiguraci a dostupnost kritických cest.

Toto pořadí není pevnou fází pro každý projekt. Automatizované akceptační příklady mohou běžet už při pull requestu, zatímco provozní akceptace potřebuje sestavený systém v reprezentativním prostředí. Sanity lze vynechat, pokud stejnou otázku jednoznačně pokrývá cílená regrese. Praktické rozdělení běhů popisuje článek co spouštět v CI/CD.

Jeden release e-shopu, tři různé důkazy

E-shop přidává doručení na výdejní místo. Po nasazení kandidáta smoke sada načte katalog, přidá produkt do košíku, otevře checkout, vytvoří kontrolovanou objednávku a ověří dostupnost objednávkového API. Pokud checkout padá kvůli chybějící konfiguraci dopravce, další testování se zastaví a tým řeší nasazení.

Po zeleném smoke běhu sanity sada cíleně prověří novinku: seznam míst se načte pro podporovaná PSČ, výběr zůstane zachovaný při návratu mezi kroky, poplatek se přepočítá a identifikátor místa se uloží do objednávky. Pokud poslední bod selže, build je sice obecně testovatelný, ale změna není připravena na širší ověření.

Akceptační testy potom projdou každé dohodnuté kritérium včetně nepovoleného zboží, potvrzení pro zákazníka, zobrazení v administraci a exportu pro sklad. Product owner vyhodnotí funkční kritéria, provoz datový tok a tester připraví důkazy a okrajové případy. Samostatná regrese ještě ověří, že stávající doručení kurýrem, slevy a platba zůstaly funkční. Žádná ze tří zelených kontrol sama nenahrazuje ostatní.

Kdo má testy vlastnit

Vlastník nemusí všechny scénáře osobně provést. Odpovídá však za rozsah, důvěryhodnost a reakci. Smoke často společně udržují vývojáři, testeři a platformový tým, protože selhání může být v aplikaci i nasazení. Sanity patří co nejblíže lidem, kteří rozumějí změně. U akceptace musí být jasné, kdo má pravomoc potvrdit byznysová, uživatelská, provozní nebo jiná kritéria; tester může proces vést, ale nemá sám vymýšlet potřebu produktu.

Ke každé sadě zapište také zástupce vlastníka a eskalaci. Automatizovaný job bez člověka, který vyhodnotí červený výsledek, není release kontrola. Stejně tak nestačí, když product owner formálně „odklikne UAT“ bez znalosti nepokrytých kritérií a zbytkového rizika.

Na co si dát pozor

• Smoke sada, která zkouší každou kombinaci, bude dávat základní signál pozdě. Podrobná pravidla přesuňte do vhodné vrstvy podle testovací pyramidy.
• Sanity bez týmové definice vytváří falešná očekávání. Do README nebo strategie zapište jeho otázku, hranice a rozdíl oproti retestu a regresi.
• Akceptace bez měřitelných kritérií se změní v subjektivní demo. Kritéria mají zahrnovat také negativní a provozní scénáře, pokud jsou pro přijetí podstatné.
• Zelený post-deploy smoke test nenahrazuje monitoring. Potvrzuje konkrétní kontrolované cesty v daném čase, ne nepřetržitou zkušenost všech uživatelů.
• Opakovaný pokus nesmí potichu proměnit nejasný první pád v důvěryhodnou zelenou. Uložte výsledek prvního běhu a určete příčinu nestability.

Co tím získáte

Přesné pojmenování zkrátí diskusi při releasu: tým ví, zda řeší neověřitelný build, problém ve změněné oblasti, nesplněné kritérium nebo regresi mimo ni. Každý běh může mít přiměřený rozsah a výsledek se dostane k člověku, který má pravomoc jednat. Místo jednoho neurčitého „testy prošly“ vzniknou oddělené důkazy s jasnými hranicemi.

Další krok

Otevřete konfiguraci poslední pipeline a ke každému jobu dopište pět položek: otázku, na kterou odpovídá, spouštěč, vstupy, vlastníka a rozhodnutí po zeleném či červeném výsledku. Potom označte joby nazvané smoke, sanity nebo acceptance, jejichž obsah této definici neodpovídá. Přejmenujte je nebo upravte rozsah dříve, než podle nich budete rozhodovat o dalším releasu.