Oprava testovacej sady

Čo je regresné testovanie a ako často ho spúšťať

Regresné testovanie overuje, či zmena nepoškodila správanie, ktoré predtým fungovalo. Nie je to jedno veľké tlačidlo „otestovať všetko“ ani povinný nočný beh. Je to výber kontrol na úrovni kódu, API, integrácií aj používateľského rozhrania, ktorého rozsah a čas spustenia majú zodpovedať riziku konkrétnej zmeny.

Regresia nie je iba chyba v menenej funkcii

Zmena môže mať nepriaznivý dôsledok v upravenom komponente, v spoločnej knižnici, v databáze, konfigurácii prostredia alebo v pripojenom systéme. Regresia je práve takýto vedľajší účinok: pred zmenou dané správanie fungovalo, po nej už nefunguje alebo funguje inak, hoci to nebolo zámerom.

Regresné testovanie preto odpovedá na otázku: Čo ďalšie mohla táto zmena poškodiť? Rozsah nezačína zoznamom všetkých existujúcich testov, ale analýzou vplyvu. Pri zmene výpočtu ceny treba myslieť na košík, platbu, faktúru, export do účtovníctva aj vratku. Pri aktualizácii databázy môžu byť relevantné migrácie, výkon dotazov a kompatibilita starších záznamov.

Oficiálny ISTQB Foundation Level syllabus tiež rozlišuje nepriaznivé dôsledky v tom istom komponente, iných častiach systému, prepojených systémoch aj prostredí. Regresné testy preto nemusia byť iba end-to-end scenáre v prehliadači.

Regresný test a retest majú odlišný cieľ

Pri oprave chyby treba vykonať dve príbuzné, ale rozdielne kontroly:

• Retest, presnejšie confirmation testing, zopakuje pôvodne zlyhávajúci scenár a potvrdí, že konkrétna chyba bola opravená. Ak zľavový kupón odpočítal sumu dvakrát, retest overí rovnaké podmienky na opravenej verzii.
• Regresné testovanie overí, či oprava nespôsobila nový problém inde. Skontroluje napríklad bežnú objednávku bez kupónu, kombináciu zľavy s dopravou, sumu poslanú platobnej bráne a údaje odovzdané do účtovníctva.

Zelený retest teda neznamená zelenú regresiu. Potvrdzuje iba opravu známeho prejavu. Naopak, regresná sada bez retestu môže prejsť, hoci pôvodná chyba zostala, pretože presný zlyhávajúci prípad v nej nebol. Pri oprave defektu má plán obsahovať obe otázky a pri každej určiť očakávaný výsledok.

Ako môže prejsť oprava a pokaziť sa release

Predstavte si e-shop, v ktorom sa desaťpercentný kupón pri určitej kombinácii vernostnej zľavy započítal dvakrát. Vývojár upraví spoločnú službu na výpočet celkovej ceny. Pôvodný scenár zopakuje, suma je správna a oprava ide do releasu.

Tá istá služba však pripravuje aj sumu pre platobnú požiadavku a údaje objednávky. Pri objednávke s darčekovou poukážkou teraz platobná brána dostane sumu po zľave, zatiaľ čo uložená objednávka obsahuje sumu pred posledným prepočtom. Platba prejde, ale spracovanie webhooku odmietne nesúlad súm a zaplatená objednávka zostane v stave „čaká na platbu“. Retest kupónu je stále zelený; release pokazil vedľajší účinok zmeny.

Primeraná regresia by nemusela preklikať každú kombináciu cez UI. Unit testy by pokryli pravidlá skladania zliav, API alebo integračný test zhodu súm medzi objednávkou a platbou a jeden kritický E2E test celý nákup. Dôležité je pokryť cestu rizika na vhodnej úrovni, nie maximalizovať počet krokov v prehliadači.

Regresia patrí na viac úrovní

Jedna sada zložená iba z UI testov býva pomalá a pri zlyhaní sa ťažšie diagnostikuje. Rozdelenie podľa testovacej pyramídy umožňuje nájsť väčšinu problémov bližšie k ich zdroju.

• Unit a komponentové testy overujú výpočty, validácie, stavové prechody a správanie malých častí. Sú vhodné pre veľa kombinácií a hraničných hodnôt.
• API a integračné testy preverujú biznis pravidlá, databázu, kontrakty a komunikáciu komponentov či externých služieb. Často tu patrí najväčšia časť regresie zdieľaných procesov.
• UI a end-to-end testy potvrdzujú, že reprezentatívne používateľské cesty držia pohromade od rozhrania po výsledok. Majú chrániť kritické prepojenia, nie opakovať každú kombináciu z nižších vrstiev.
• Manuálne a prieskumné testovanie dopĺňa automatizáciu tam, kde treba posúdiť nové správanie, použiteľnosť alebo riziko, ktoré ešte nemá stabilný test.

Regresný charakter neurčuje technológia testu, ale jeho cieľ. Unit test starého pravidla aj manuálna kontrola existujúceho procesu môžu byť súčasťou regresie, ak overujú možné vedľajšie účinky zmeny.

Tri vrstvy namiesto jednej nekonečnej sady

Praktické je rozdeliť regresiu podľa rýchlosti spätnej väzby a šírky rizika:

1. Rýchla vrstva obsahuje stabilné unit, komponentové a vybrané API testy plus niekoľko kritických kontrol. Beží pri relevantnej zmene a má včas zastaviť zjavný problém. Po nasadení ju môže doplniť smoke test, ktorého presný účel vysvetľuje porovnanie smoke, sanity a akceptačných testov.
2. Širšia vrstva pridáva integrácie, viac biznis pravidiel, oprávnení, prehliadačov alebo reprezentatívnych E2E ciest. Spúšťa sa po spojení zmien, nad kandidátom na release alebo pri udalosti, ktorá zasiahla zdieľané časti.
3. Plná vrstva predstavuje dohodnuté maximálne pokrytie relevantné pre produkt, nie automaticky každý test, ktorý kedy vznikol. Má zmysel pri významnom release, migrácii, zmene infraštruktúry alebo inom vysokom riziku. Môže kombinovať automatizované behy s cieleným manuálnym overením.

Každá vrstva potrebuje cieľový čas spätnej väzby, vlastníka, podmienky spustenia a reakciu na zlyhanie. Bez nich sa z označení „rýchla“ a „plná“ stanú iba priečinky, ktorých obsah časom prestane zodpovedať názvu.

Ako často regresiu spúšťať

Univerzálny interval neexistuje. Tím, ktorý nasadzuje niekoľkokrát denne, potrebuje inú skladbu než regulovaný produkt s plánovanými releasmi. Lepšou otázkou než „denne alebo týždenne?“ je „ktorá udalosť zmenila naše riziko?“

Pravidelný nočný beh môže byť užitočný pre pomalšiu časť sady, ale kalendár nenahrádza spúšťač. Ak kritická zmena čaká do noci, spätná väzba môže prísť neskoro. Ak sa produkt nemenil, opakovaný plný beh môže spotrebovať kapacitu bez nového rozhodovacieho prínosu.

Ako vybrať a zoradiť testy

Začnite mapou vplyvu: ktoré komponenty sa zmenili, ktoré dáta čítajú a zapisujú, kto ich volá a ktoré používateľské alebo prevádzkové procesy na nich závisia. Potom skombinujte štyri signály:

• dopad chyby na zákazníka, peniaze, dáta, bezpečnosť alebo prevádzku;
• pravdepodobnosť, že zmena zasiahne danú cestu;
• história chýb a nestability v oblasti;
• sila iných dôkazov, napríklad kontroly kódu, unit testov alebo monitoringu.

Výsledkom nemá byť falošne presné skóre. Stačí poradie: najprv testy s vysokým dopadom a priamou väzbou na zmenu, potom spoločné integrácie a kritické cesty, napokon nižšie riziká. Praktický postup rozvíja rizikovo orientované testovanie.

Výber podľa zmenených súborov či tagov môže sadu výrazne skrátiť, no potrebuje bezpečnostnú sieť. Mapa závislostí nemusí zachytiť dynamickú konfiguráciu, zdieľané dáta alebo nepriamu väzbu medzi službami. Preto sa cielený výber kombinuje s malou stabilnou sadou kritických ciest a podľa rizika aj so širším behom.

Sada sa musí meniť spolu s produktom

Regresná sada nie je hotový inventár. Nová funkcia vytvára nové riziká, zrušené správanie robí časť testov neplatnou a presun pravidla medzi službami môže zmeniť najvhodnejšiu úroveň kontroly. Pri každej významnej zmene preto aktualizujte nielen kód testu, ale aj mapu rizík, tagy, vlastníctvo a zaradenie do vrstiev.

Chyba uniknutá do produkcie je podnet na analýzu medzery, nie automatický príkaz pridať ďalší E2E test. Najprv zistite, prečo existujúce kontroly problém neodhalili. Mohla chýbať kombinácia v unit teste, kontrakt medzi službami, realistické dáta alebo reakcia na už viditeľné zlyhanie. Novú kontrolu pridajte na najnižšej úrovni, ktorá spoľahlivo zachytí príčinu, a vyššiu vrstvu doplňte iba vtedy, keď má overiť dôležité prepojenie.

Rovnako dôležité je testy upravovať a vyraďovať. Scenár bez platného rizika, jasného očakávania alebo vlastníka nevytvára istotu len tým, že je zelený. Rozhodnutie o vyradení zdokumentujte a skontrolujte, či rovnaké riziko pokrýva iný test alebo vedomé manuálne opatrenie.

Kedy výsledok stačí na rozhodnutie o release

Zelená ikona sama osebe nestačí. Pred rozhodnutím treba vedieť, aká verzia a prostredie sa testovali, ktoré riziká boli pokryté, ktoré testy sa nespustili a či opakované pokusy neskryli prvé zlyhanie. Otvorené chyby majú mať známy dopad a vlastníka rozhodnutia.

Červený výsledok zase nemusí automaticky znamenať chybu produktu. Môže ísť o test, dáta alebo prostredie, no niekto to musí diagnostikovať. Release možno uvoľniť až podľa dohodnutých kritérií a zvyškového rizika, nie preto, že tím nemá čas výsledok preskúmať. Rozdelenie kontrol medzi pull request, nasadenie a release opisuje článok o automatizovaných testoch v CI/CD.

Keď sada trvá dlho alebo jej tím neverí

Pri dlhej sade najprv oddeľte čas vo fronte, prípravu prostredia, beh testov, pevné čakania a opakovania. Potom presuňte kombinácie na nižšiu úroveň, izolujte dáta, bezpečne paralelizujte, odstráňte duplicity a rozdeľte spätnú väzbu podľa rizika. Samotné vypnutie pomalých testov bez náhrady iba skryje nepokryté riziko. Podrobný postup ponúka návod, ako zrýchliť regresnú sadu.

Ak tím výsledkom neverí, začnite malou kritickou vrstvou. Sledujte výsledok prvého pokusu, nie iba konečný stav po opakovaní (retry), a pri každom zlyhaní rozlíšte aplikáciu, test, dáta a prostredie. Karanténa má byť dočasná, s dôvodom, vlastníkom a termínom nápravy. Rastúci počet preskočených testov alebo zelené výsledky po opakovaní sú signály, že sada stráca rozhodovaciu hodnotu; pomôže audit toho, prečo testovacie sady prestávajú pomáhať.

Čo tým získate

Vrstvená regresia poskytne rýchly signál pri malej zmene a širší dôkaz tam, kde je riziko väčšie. Tím vie, prečo sa konkrétny test spustil, čo znamená jeho zlyhanie a kto má reagovať. Taká sada podporuje rozhodnutie o release bez predstierania, že akýkoľvek počet zelených testov dokazuje neprítomnosť všetkých chýb.

Ďalší krok

Vyberte posledný release alebo incident a na jednu stranu zapíšte: čo sa zmenilo, ktoré ďalšie oblasti mohli byť zasiahnuté, aké testy sa spustili a ktoré rozhodnutie ich výsledok ovplyvnil. Potom existujúce testy rozdeľte na rýchlu, širšiu a plnú vrstvu. Ku každej doplňte spúšťač, maximálne prijateľný čas spätnej väzby, vlastníka zlyhania a riziko, ktoré zostáva mimo nej.