Oprava testovací sady

Co je regresní testování a jak často ho spouštět

Regresní testování ověřuje, zda změna nepoškodila chování, které dříve fungovalo. Není to jedno velké tlačítko „otestovat všechno“ ani povinný noční běh. Jde o výběr kontrol na úrovni kódu, API, integrací i uživatelského rozhraní, jehož rozsah a okamžik spuštění mají odpovídat riziku konkrétní změny.

Regrese není jen chyba v měněné funkci

Změna může mít nepříznivý důsledek v upravené komponentě, společné knihovně, databázi, konfiguraci prostředí nebo připojeném systému. Regrese je právě takový vedlejší účinek: před změnou dané chování fungovalo, po ní už nefunguje nebo funguje jinak, přestože to nebylo záměrem.

Regresní testování proto odpovídá na otázku: Co dalšího mohla tato změna poškodit? Rozsah nezačíná seznamem všech existujících testů, ale analýzou dopadu. Při změně výpočtu ceny je třeba myslet na košík, platbu, fakturu, export do účetnictví i vratku. Při aktualizaci databáze mohou být relevantní migrace, výkon dotazů a kompatibilita starších záznamů.

Oficiální ISTQB Foundation Level syllabus také rozlišuje nepříznivé důsledky ve stejné komponentě, jiných částech systému, propojených systémech i prostředí. Regresní testy proto nemusí být pouze end-to-end scénáře v prohlížeči.

Regresní test a retest mají odlišný cíl

Při opravě chyby je třeba provést dvě příbuzné, ale rozdílné kontroly:

• Retest, přesněji confirmation testing, zopakuje původně selhávající scénář a potvrdí, že konkrétní chyba byla opravena. Pokud slevový kupón odečetl částku dvakrát, retest ověří stejné podmínky na opravené verzi.
• Regresní testování ověří, zda oprava nezpůsobila nový problém jinde. Zkontroluje například běžnou objednávku bez kupónu, kombinaci slevy s dopravou, částku poslanou platební bráně a údaje předané do účetnictví.

Zelený retest tedy neznamená zelenou regresi. Potvrzuje pouze opravu známého projevu. Regresní sada bez retestu naopak může projít, přestože původní chyba zůstala, protože přesný selhávající případ v ní nebyl. Při opravě defektu má plán obsahovat obě otázky a u každé určit očekávaný výsledek.

Jak může oprava projít a release se přesto pokazit

Představte si e-shop, ve kterém se desetiprocentní kupón při určité kombinaci s věrnostní slevou započítal dvakrát. Vývojář upraví společnou službu pro výpočet celkové ceny. Původní scénář zopakuje, částka je správná a oprava jde do releasu.

Stejná služba však připravuje také částku pro požadavek na platbu a údaje objednávky. U objednávky s dárkovým poukazem nyní platební brána dostane částku po slevě, zatímco uložená objednávka obsahuje částku před posledním přepočtem. Platba projde, ale zpracování webhooku odmítne nesoulad částek a zaplacená objednávka zůstane ve stavu „čeká na platbu“. Retest kupónu je stále zelený; release pokazil vedlejší účinek změny.

Přiměřená regrese by nemusela proklikávat každou kombinaci přes UI. Unit testy by pokryly pravidla skládání slev, API nebo integrační test shodu částek mezi objednávkou a platbou a jeden kritický E2E test celý nákup. Důležité je pokrýt cestu rizika na vhodné úrovni, ne maximalizovat počet kroků v prohlížeči.

Regrese patří na více úrovní

Jedna sada složená pouze z UI testů bývá pomalá a při selhání se obtížněji diagnostikuje. Rozdělení podle testovací pyramidy umožňuje najít většinu problémů blíže jejich zdroji.

• Unit a komponentové testy ověřují výpočty, validace, stavové přechody a chování malých částí. Hodí se pro mnoho kombinací a hraničních hodnot.
• API a integrační testy prověřují byznys pravidla, databázi, kontrakty a komunikaci komponent nebo externích služeb. Často sem patří největší část regrese sdílených procesů.
• UI a end-to-end testy potvrzují, že reprezentativní uživatelské cesty drží pohromadě od rozhraní po výsledek. Mají chránit kritická propojení, ne opakovat každou kombinaci z nižších vrstev.
• Manuální a průzkumné testování doplňuje automatizaci tam, kde je třeba posoudit nové chování, použitelnost nebo riziko, které ještě nemá stabilní test.

Regresní charakter neurčuje technologie testu, ale jeho cíl. Unit test starého pravidla i manuální kontrola existujícího procesu mohou být součástí regrese, pokud ověřují možné vedlejší účinky změny.

Tři vrstvy místo jedné nekonečné sady

Praktické je rozdělit regresi podle rychlosti zpětné vazby a šířky rizika:

1. Rychlá vrstva obsahuje stabilní unit, komponentové a vybrané API testy plus několik kritických kontrol. Běží při relevantní změně a má včas zastavit zjevný problém. Po nasazení ji může doplnit smoke test, jehož přesný účel vysvětluje porovnání smoke, sanity a akceptačních testů.
2. Širší vrstva přidává integrace, více byznys pravidel, oprávnění, prohlížečů nebo reprezentativních E2E cest. Spouští se po spojení změn, nad kandidátem na release nebo při události, která zasáhla sdílené části.
3. Plná vrstva představuje dohodnuté maximální pokrytí relevantní pro produkt, ne automaticky každý test, který kdy vznikl. Má smysl při významném releasu, migraci, změně infrastruktury nebo jiném vysokém riziku. Může kombinovat automatizované běhy s cíleným manuálním ověřením.

Každá vrstva potřebuje cílový čas zpětné vazby, vlastníka, podmínky spuštění a reakci na selhání. Bez nich se z označení „rychlá“ a „plná“ stanou pouze složky, jejichž obsah časem přestane odpovídat názvu.

Jak často regresi spouštět

Univerzální interval neexistuje. Tým, který nasazuje několikrát denně, potřebuje jinou skladbu než regulovaný produkt s plánovanými releasy. Lepší otázkou než „denně, nebo týdně?“ je „která událost změnila naše riziko?“

Pravidelný noční běh může být užitečný pro pomalejší část sady, ale kalendář nenahrazuje spouštěč. Pokud kritická změna čeká do noci, zpětná vazba může přijít pozdě. Jestliže se produkt nezměnil, opakovaný plný běh může spotřebovat kapacitu bez nového rozhodovacího přínosu.

Jak vybrat a seřadit testy

Začněte mapou dopadu: které komponenty se změnily, jaká data čtou a zapisují, kdo je volá a které uživatelské či provozní procesy na nich závisí. Potom zkombinujte čtyři signály:

• dopad chyby na zákazníka, peníze, data, bezpečnost nebo provoz;
• pravděpodobnost, že změna zasáhne danou cestu;
• historie chyb a nestability v oblasti;
• síla jiných důkazů, například kontroly kódu, unit testů nebo monitoringu.

Výsledkem nemá být falešně přesné skóre. Stačí pořadí: nejprve testy s vysokým dopadem a přímou vazbou na změnu, poté společné integrace a kritické cesty, nakonec nižší rizika. Praktický postup rozvíjí rizikově orientované testování.

Výběr podle změněných souborů nebo tagů může sadu výrazně zkrátit, potřebuje však bezpečnostní síť. Mapa závislostí nemusí zachytit dynamickou konfiguraci, sdílená data nebo nepřímou vazbu mezi službami. Cílený výběr se proto kombinuje s malou stabilní sadou kritických cest a podle rizika také se širším během.

Sada se musí měnit spolu s produktem

Regresní sada není hotový inventář. Nová funkce vytváří nová rizika, zrušené chování činí část testů neplatnou a přesun pravidla mezi službami může změnit nejvhodnější úroveň kontroly. Při každé významné změně proto aktualizujte nejen kód testu, ale také mapu rizik, tagy, vlastnictví a zařazení do vrstev.

Chyba uniklá do produkce je podnětem k analýze mezery, ne automatickým příkazem přidat další E2E test. Nejprve zjistěte, proč existující kontroly problém neodhalily. Mohla chybět kombinace v unit testu, kontrakt mezi službami, realistická data nebo reakce na již viditelné selhání. Novou kontrolu přidejte na nejnižší úrovni, která spolehlivě odhalí příčinu, a vyšší vrstvu doplňte jen tehdy, když má ověřit důležité propojení.

Stejně důležité je testy upravovat a vyřazovat. Scénář bez platného rizika, jasného očekávání nebo vlastníka nevytváří jistotu jen tím, že je zelený. Rozhodnutí o vyřazení zdokumentujte a zkontrolujte, zda stejné riziko pokrývá jiný test nebo vědomé manuální opatření.

Kdy výsledek stačí pro rozhodnutí o releasu

Zelená ikona sama o sobě nestačí. Před rozhodnutím je třeba vědět, jaká verze a prostředí se testovaly, která rizika byla pokryta, které testy se nespustily a zda opakované pokusy neskryly první selhání. Otevřené chyby mají mít známý dopad a vlastníka rozhodnutí.

Červený výsledek zase nemusí automaticky znamenat chybu produktu. Může jít o test, data nebo prostředí, ale někdo to musí diagnostikovat. Release lze uvolnit až podle dohodnutých kritérií a zbytkového rizika, ne proto, že tým nemá čas výsledek prozkoumat. Rozdělení kontrol mezi pull request, nasazení a release popisuje článek o automatizovaných testech v CI/CD.

Když sada trvá dlouho nebo jí tým nevěří

U dlouhé sady nejprve oddělte čas ve frontě, přípravu prostředí, běh testů, pevná čekání a opakování. Potom přesuňte kombinace na nižší úroveň, izolujte data, bezpečně paralelizujte, odstraňte duplicity a rozdělte zpětnou vazbu podle rizika. Samotné vypnutí pomalých testů bez náhrady jen skryje nepokryté riziko. Podrobný postup nabízí návod, jak zrychlit regresní sadu.

Pokud tým výsledkům nevěří, začněte malou kritickou vrstvou. Sledujte výsledek prvního pokusu, ne pouze konečný stav po opakování (retry), a při každém selhání rozlište aplikaci, test, data a prostředí. Karanténa má být dočasná, s důvodem, vlastníkem a termínem nápravy. Rostoucí počet přeskočených testů nebo zelené výsledky po opakování jsou signály, že sada ztrácí rozhodovací hodnotu; pomůže audit toho, proč testovací sady přestávají pomáhat.

Co tím získáte

Vrstvená regrese poskytne rychlý signál při malé změně a širší důkaz tam, kde je riziko větší. Tým ví, proč se konkrétní test spustil, co znamená jeho selhání a kdo má reagovat. Taková sada podporuje rozhodnutí o releasu bez předstírání, že jakýkoli počet zelených testů dokazuje nepřítomnost všech chyb.

Další krok

Vyberte poslední release nebo incident a na jednu stranu zapište: co se změnilo, které další oblasti mohly být zasaženy, jaké testy se spustily a které rozhodnutí jejich výsledek ovlivnil. Potom existující testy rozdělte na rychlou, širší a plnou vrstvu. Ke každé doplňte spouštěč, maximální přijatelný čas zpětné vazby, vlastníka selhání a riziko, které zůstává mimo ni.