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.

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.

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.

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.

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ý