Regresní testování… Co to je? K čemu to je? Proč je to důležité? Každý SW se stále vyvíjí, přidávají se do něj nové funkce a také se opravují chyby v původní funkcionalitě. To nám testerům komplikuje život, ale také dává práci. 🙂 Při každém takovém zásahu totiž může dojít k chybě – a překvapivě nejen k chybě – v místě změny.
Jak tedy zajistit, aby po změně byl systém stále plně funkční i mimo danou oblast zásahu? K tomu nám slouží právě regresní testování.

Co to vlastně ta regrese je

Začněme příkladem ze života mimo IT. Představte si, že dáte auto do servisu, protože nefunguje ukazatel teploty oleje. Po opravě si auto vyzvednete a jste spokojení, jak ukazatel zase hezky ukazuje. Radost vám ale vydrží jen do doby, než zjistíte, že vám v servisu při opravě pokazili klimatizaci.
Stejný nešvar se děje ve vývoji softwaru. Regrese tedy znamená stav, kdy úpravou zdrojového kódu přestane fungovat něco, co do úpravy fungovalo v pořádku.
Abychom tomu předešli a chyby se nedostaly až k zákazníkovi, potřebujeme vytvářet a pouštět regresní testy.

K čemu jsou regresní testy?

Nedávno jsem se během konzultací v jedné firmě setkal s výrokem od zákazníka: „My nechceme vaše nové verze – jsou plné chyb!“ Tohle je přesně ukázka, kdy má firma velké mezery v regresním testování.
Chyby se vinou nedostatečného (nebo dokonce žádného) regresního testování nepodaří odhalit ještě ve fázi vývoje, a tak unikají až k zákazníkovi. Ten je z nich pochopitelně rozhořčený. Právem.
Regresní testy tedy slouží k odhalování těchto chyb.

Jak na regresní testy?

Regresní testy = skupina testů někdy označovaná také jako regresní sada, která se může objevovat na různé úrovni vývoje a testování:
  • komponent testy
  • integrační testy
  • API testy
  • funkční testy
Proto za ně zodpovídají jak testeři, tak vývojáři. Každý tým a projekt je jiný a pro nasazení správného regresního testování je třeba zvolit vhodnou strategii. Obecně se ale dá říci, že je vhodné vždy určit, na jaké úrovni budete chtít jednotlivé chyby odchytávat. S tím, že se začíná od nejnižší úrovně, tedy od unit testů. A pokud se tam daná funkcionalita nebo chyba nedá odchytit, jde se postupně výše.
Více se k tomu dozvíte ve článku Proč nám testování trvá tak dlouho.

Jak se regresní testy vytváří?

Budování regresní sady vzniká ideálně postupně. Při naprogramování nové funkcionality by měl zároveň vzniknou i nový test, který se zařadí do regresní sady. K evidenci těch testů je dobré využít nějaký test management tool (TMT). Ten vám usnadní správu a organizaci testů. Ale i jejich výsledků, které se vám budou množit s každým releasem nebo buildem.

Hlavní potíže u regresního testování

Z výše popsaného je evidentní, že množství regresních testů vám bude neustále narůstat. A tak máte 3 možnosti: Začít regresní sadu automatizovat. Najímat stále více testerů (budete se divit, ale i tuhle šílenou variantu některé firmy preferují). Nebo
regresní sadu redukovat podle některých z těchto pravidel:
  • nedávné změny
  • core funkcionalita (prioritní testy)
  • rizikové oblasti
  • opravované části
Ty části samozřejmě můžete kombinovat dle libosti. Příkladem může být oprava chyby v oblasti přihlašování. Prvně identifikujete, které komponenty jsou změnou zasaženy. A pak provedete testy těchto oblastí + core funcionalitu.
Jednoznačně nejlepší je ale testovat celou regresní sadu, a tedy psát automatické testy. Ty vám vyřeší problém s narůstajícím počtem testů.

Kdy se regresní testy provádí?

Kompletní regresní sadu je nutné pustit před každým releasem. Jedině tak máte zaručeno, že nedošlo k zavedení chyby v nějaké odlehlé oblasti, u které vás ani ve snu nenapadlo, že má s opravou souvislost.
Důležité je také plánování času na regresní testy. Častou chybou je, že se počítá s tím, že regresní testy se budou pouštět jen jedenkrát. Pokud máte automatické testy, pouštíte je pro každý build. Pokud ale testujete především manuálně, je dobré vytvořit si jasnou strategii vykonávání regresních testů.
Příklad:
  1. Nejdřív přidat novou funkcionalitu, nebo opravit chyby.
  2. Poté provést první běh regresního setu (ten odhalí další chyby).
  3. Opravit chyby identifikované při regresním testování.
  4. Provést finální regresní testování, kde by již v ideálním případě nemělo dojít k žádné chybě.

Závěr

Slovy Johna Ruskina: „Kvalita není nikdy náhoda. Je to vždy výsledek chytrého úsilí“. Přeji kvalitu vašemu produktu a snadné testování.
Pokud vás tato problematika zajímá více, přihlaste se na kurz Zaklady-testovani-softwaru. Nebo se o všem můžeme detailně v konkrétních barvách vaší firmy pobavit na konzultacích. Neváhejte se mi ozvat.