Testovacia stratégia a audit

Smoke, sanity a akceptačné testy: čo znamenajú a kedy ich spustiť

Smoke, sanity a akceptačné testy sa v tímoch často zamieňajú, hoci odpovedajú na odlišné otázky. Smoke overuje, či je build alebo nasadenie vôbec rozumne testovateľné, sanity býva úzkou kontrolou zmeny alebo stability a akceptačné testovanie posudzuje zhodu s akceptačnými kritériami a potrebou používateľa či organizácie. Názov však nestačí: tím musí pri každej sade definovať cieľ, rozsah, vstupy, vlastníka a rozhodnutie, ktoré výsledok ovplyvní.

Prečo sa rovnaké slová používajú inak

Tieto označenia nevytvárajú tri technické priečinky, do ktorých možno každý test zaradiť iba raz. Opisujú najmä účel konkrétneho behu. Rovnaký automatizovaný scenár nákupu môže byť súčasťou smoke sady po nasadení, regresnej sady pred releasom a akceptačného overenia používateľského príbehu. Mení sa dôvod spustenia, požadovaný dôkaz a reakcia na výsledok.

Najväčší zmätok spôsobuje slovo sanity. Niektoré tímy ním označujú úzku kontrolu opravenej oblasti, iné malú podmnožinu regresie a ďalšie ho používajú takmer ako synonymum smoke testu. Preto nie je bezpečné prevziať názov z cudzieho projektu a predpokladať rovnaký význam. V tomto článku používame časté praktické rozlíšenie: smoke je široká a plytká kontrola overiteľnosti buildu či nasadenia, sanity je úzka kontrola zmenenej oblasti a akceptačné testovanie overuje, či riešenie spĺňa dohodnutú potrebu.

Smoke test: dá sa s týmto buildom zmysluplne pracovať?

Smoke test prejde malý počet základných kontrol naprieč systémom. Má rýchlo odhaliť, že build sa nespustí, služba neodpovedá, databázová migrácia zlyhala, konfigurácia smeruje na nesprávnu závislosť alebo sa nedá otvoriť kritická cesta. Je široký, pretože sa dotkne dôležitých častí, a plytký, pretože neskúša veľa kombinácií ani detailné hraničné prípady.

Po nasadení e-shopu môže smoke sada overiť, že sa načíta katalóg, funguje prihlásenie, produkt možno vložiť do košíka, checkout sa otvorí a objednávkové API prijme kontrolovanú požiadavku. Nemá dokazovať správnosť všetkých zliav, spôsobov dopravy a platieb. Zelený smoke výsledok znamená „prostredie a základné cesty sú pripravené na ďalšie testovanie“, nie „release je bezpečný“.

Takéto použitie podporuje aj ISTQB Advanced Level Test Analyst syllabus, ktorý smoke test uvádza pri overení pripravenosti testovacieho prostredia. V praxi ho možno spustiť aj nad lokálnym buildom, integračným prostredím alebo produkčným nasadením. Rozsah sa mení podľa prostredia: v produkcii majú byť scenáre kontrolované, nedestruktívne alebo po sebe bezpečne upratať dáta.

Sanity test: funguje zmenená oblasť natoľko, aby malo zmysel pokračovať?

Sanity test sa často používa po menšej zmene, oprave chyby alebo novom builde na úzke overenie dotknutej funkcie a jej najbližšieho okolia. Ak sa upravil výber odberného miesta, sanity sada môže skontrolovať jeho načítanie, výber, zachovanie pri prechode checkoutom a uloženie identifikátora do objednávky. Neoveruje pritom celý e-shop.

Jeho hranice sa čiastočne prekrývajú s confirmation testingom, teda retestom opravy, a s cielenou regresiou. Rozdiel si tím musí pomenovať. Môže sa dohodnúť, že retest vždy reprodukuje pôvodný defekt, zatiaľ čo sanity balík overí základnú stabilitu celej menenej oblasti. Iný tím môže termín sanity úplne vynechať a používať názov „cielená regresia“. Obe možnosti sú použiteľné, ak z výsledku každý rozumie rozsahu.

Pre sanity sadu neexistuje univerzálny počet scenárov ani časový limit. Má byť dostatočne úzka na skorú odpoveď a dostatočne hlboká na rozhodnutie, či pokračovať širším testovaním. Ak sa z nej časom stane hodinová kontrola nesúvisiacich funkcií, prestala plniť tento účel, aj keď si ponechala pôvodný názov.

Akceptačné testy: spĺňa riešenie dohodnutú potrebu?

Akceptačné testovanie validuje, či riešenie spĺňa podmienky, za ktorých ho príslušné zainteresované strany prijmú. Testovacím základom môžu byť akceptačné kritériá používateľského príbehu, biznis pravidlá, prevádzkové požiadavky, zmluva alebo regulačné podmienky. Kontrola môže byť manuálna aj automatizovaná a môže začať už počas vývoja, ak tím kritériá premení na vykonateľné príklady.

Akceptačné testovanie preto nie je iba user acceptance testing (UAT), pri ktorom budúci používateľ skúša hotový systém. ISTQB Foundation Level syllabus medzi formy akceptačného testovania zaraďuje používateľské, prevádzkové, zmluvné a regulačné akceptačné testovanie aj alpha a beta testovanie. Pre konkrétny produkt môžu byť relevantné iba niektoré z nich.

Príkladom funkčného akceptačného kritéria je: „Ak objednávka obsahuje iba tovar povolený pre odberné miesto a adresa je v podporovanej krajine, zákazník môže vybrať odberné miesto a jeho názov sa zobrazí v potvrdení.“ Prevádzková akceptácia môže navyše overiť, že kód odberného miesta príde do skladu, podpora ho vidí v administrácii a zlyhanú integráciu možno dohľadať. Samotná úspešná prezentácia funkcie na deme tieto dôkazy nenahrádza.

Porovnanie na jednej strane

Tabuľka je východisko, nie univerzálna norma pre názvy jobov v pipeline. Ak tím používa „sanity“ inak, má upraviť definíciu vo vlastnom slovníku a názov doplniť presnejším popisom, napríklad checkout-change-sanity.

Aké vstupy a výstupy potrebuje každý beh

Bez jasných vstupov sa rozsah mení podľa toho, kto test spustil. Bez jasného výstupu sa síce vytvorí report, ale nikto nevie, čo s ním urobiť.

Smoke potrebuje identifikáciu buildu a prostredia, dostupné základné závislosti, kontrolované testovacie dáta a zoznam kritických sond. Výstup má uviesť, ktoré komponenty boli dostupné, kde scenár skončil a či možno pokračovať ďalšími testami. Ak beží po nasadení, treba rozlíšiť chybu artefaktu od konfigurácie prostredia.

Sanity potrebuje popis zmeny, dotknuté komponenty, pôvodný defekt alebo akceptačné príklady a očakávané súvisiace väzby. Výstup nemá byť iba „5 z 5 prešlo“, ale aj potvrdenie testovanej verzie a hraníc: napríklad odberné miesto funguje, no doprava kuriérom zatiaľ nebola súčasťou behu.

Akceptačné testovanie potrebuje schválené a testovateľné kritériá, správne roly, reprezentatívne dáta a osobu oprávnenú vyhodnotiť výsledok. Výstupom sú dôkazy ku kritériám, odchýlky, otvorené riziká a rozhodnutie. Screenshot môže byť užitočný artefakt, ale nepreukáže spracovanie v API, databáze alebo nadväzujúcom systéme.

Kde patria v pipeline a release procese

Typické poradie vyzerá takto:

1. Build prejde statickými, unit a komponentovými kontrolami.
2. Po nasadení do testovacieho prostredia smoke test potvrdí, že prostredie a kritické časti sú overiteľné.
3. Sanity test alebo cielený retest preverí zmenu a jej najbližšie okolie.
4. Širšia regresná sada hľadá nežiaduce účinky v ďalších oblastiach.
5. Akceptačné testy potvrdia konkrétne kritériá a pripravenosť z pohľadu príslušných zainteresovaných strán.
6. Po produkčnom nasadení môže bezpečný smoke test potvrdiť skutočne nasadenú konfiguráciu a dostupnosť kritických ciest.

Toto poradie nie je pevná fáza pre každý projekt. Automatizované akceptačné príklady môžu bežať už pri pull requeste, zatiaľ čo prevádzková akceptácia potrebuje zostavený systém v reprezentatívnom prostredí. Sanity možno vynechať, ak rovnakú otázku jednoznačne pokrýva cielená regresia. Praktické rozdelenie behov opisuje článok čo spúšťať v CI/CD.

Jeden release e-shopu, tri rozdielne dôkazy

E-shop pridáva doručenie na odberné miesto. Po nasadení kandidáta smoke sada načíta katalóg, pridá produkt do košíka, otvorí checkout, vytvorí kontrolovanú objednávku a overí dostupnosť objednávkového API. Ak checkout padá pre chýbajúcu konfiguráciu dopravcu, ďalšie testovanie sa zastaví a tím rieši nasadenie.

Po zelenom smoke behu sanity sada cielene preverí novinku: zoznam miest sa načíta pre podporované PSČ, výber zostane zachovaný pri návrate medzi krokmi, poplatok sa prepočíta a identifikátor miesta sa uloží do objednávky. Ak posledný bod zlyhá, build je síce všeobecne testovateľný, ale zmena nie je pripravená na širšie overenie.

Akceptačné testy potom prejdú každé dohodnuté kritérium vrátane nepovoleného tovaru, potvrdenia pre zákazníka, zobrazenia v administrácii a exportu pre sklad. Product owner vyhodnotí funkčné kritériá, prevádzka dátový tok a tester pripraví dôkazy a okrajové prípady. Samostatná regresia ešte overí, že existujúce doručenie kuriérom, zľavy a platba zostali funkčné. Žiadna z troch zelených kontrol sama nenahrádza ostatné.

Kto má testy vlastniť

Vlastník nemusí všetky scenáre osobne vykonať. Zodpovedá však za rozsah, dôveryhodnosť a reakciu. Smoke často udržiavajú vývojári, testeri a platformový tím spoločne, pretože zlyhanie môže byť v aplikácii aj nasadení. Sanity patrí čo najbližšie k ľuďom, ktorí rozumejú zmene. Pri akceptácii musí byť jasné, kto má právomoc potvrdiť biznis, používateľské, prevádzkové alebo iné kritériá; tester môže proces viesť, ale nemá sám vymýšľať potrebu produktu.

Ku každej sade zapíšte aj zástupcu vlastníka a eskaláciu. Automatizovaný job bez človeka, ktorý vyhodnotí červený výsledok, nie je release kontrola. Rovnako nestačí, ak product owner formálne „odklikne UAT“ bez znalosti nepokrytých kritérií a zvyškového rizika.

Na čo si dať pozor

• Smoke sada, ktorá skúša každú kombináciu, bude dávať základný signál neskoro. Detailné pravidlá presuňte do vhodnej vrstvy podľa testovacej pyramídy.
• Sanity bez tímovej definície vytvára falošné očakávania. Do README alebo stratégie zapíšte jeho otázku, hranice a rozdiel oproti retestu a regresii.
• Akceptácia bez merateľných kritérií sa zmení na subjektívne demo. Kritériá majú obsahovať aj negatívne a prevádzkové scenáre, ak sú pre prijatie podstatné.
• Zelený post-deploy smoke test nenahrádza monitoring. Potvrdzuje konkrétne kontrolované cesty v danom čase, nie nepretržitú skúsenosť všetkých používateľov.
• Opakovaný pokus nesmie potichu premeniť nejasný prvý pád na dôveryhodnú zelenú. Uložte výsledok prvého behu a určte príčinu nestability.

Čo tým získate

Presné pomenovanie skráti diskusiu pri release: tím vie, či rieši neoveriteľný build, problém v zmenenej oblasti, nesplnené kritérium alebo regresiu mimo nej. Každý beh môže mať primeraný rozsah a výsledok sa dostane k človeku, ktorý má právomoc konať. Namiesto jedného neurčitého „testy prešli“ vzniknú oddelené dôkazy s jasnými hranicami.

Ďalší krok

Otvorte konfiguráciu poslednej pipeline a ku každému jobu dopíšte päť položiek: otázku, na ktorú odpovedá, spúšťač, vstupy, vlastníka a rozhodnutie po zelenom či červenom výsledku. Potom označte joby nazvané smoke, sanity alebo acceptance, ktorých obsah tejto definícii nezodpovedá. Premenujte ich alebo upravte rozsah skôr, než podľa nich budete rozhodovať o ďalšom release.