Testovacia stratégia a audit

Druhy testovania softvéru: prehľad typov testov a kedy sa ktorý používa

Unit, regresný, API, akceptačný či výkonnostný test neoznačujú päť navzájom sa vylučujúcich možností. Každý názov odpovedá na inú otázku: akú veľkú časť systému overujeme, čo chceme zistiť, ako test vykonávame alebo prečo ho spúšťame práve teraz. Tento prehľad pomôže produktovým ľuďom, vývojárom aj testerom pomenovať pokrytie presne a vybrať test podľa rizika, nie podľa najznámejšieho termínu.

Prečo jeden zoznam typov testov nestačí

Predstavte si automatizovaný scenár, ktorý po nasadení zavolá objednávkové API, vytvorí objednávku a overí výslednú cenu. Môže byť súčasne dynamický, funkčný, integračný, API, regresný aj smoke test. Nie je v tom rozpor. „Integračný“ opisuje rozsah zapojených častí, „funkčný“ cieľ kontroly, „API“ rozhranie, „automatizovaný“ spôsob vykonania a „smoke“ úlohu v konkrétnom bode procesu.

Bez takéhoto rozlíšenia vznikajú neproduktívne debaty. Tím povie, že potrebuje viac integračných testov, hoci mu v skutočnosti chýba kontrola výkonu. Alebo označí každý test v prehliadači za end-to-end (E2E), aj keď používa simulované backendové služby a overuje iba jeden frontendový komponent. Výsledkom bývajú duplicity na jednej úrovni a slepé miesta inde.

Dobrá testovacia stratégia preto nevyberá jeden „správny druh“. Kombinuje viac pohľadov a pomocou rizikovo orientovaného testovania rozhoduje, kde má ktorý dôkaz najväčšiu hodnotu:

Názvy sa navyše medzi firmami líšia. Pred použitím metrík alebo plánovaním sady si preto k pojmu dopíšte hranicu testu, skutočné závislosti a očakávaný výsledok. Presný obsah je dôležitejší než štítok.

Druhy podľa úrovne: od jednej jednotky po celú cestu

Unit test, po slovensky jednotkový test, overuje malú jednotku správania v kontrolovaných podmienkach. Môže to byť funkcia pre výpočet DPH, validačné pravidlo alebo trieda, ktorá rozhoduje o nároku na zľavu. Databázu, sieť či hodiny často nahradí riadenou náhradou. Výsledok býva rýchly a príčina zlyhania dobre lokalizovateľná, no unit test sám nepotvrdí, že časti spolu správne komunikujú.

Komponentový test overuje väčší celok cez jeho verejnú hranicu. Komponentom môže byť frontendový formulár, knižnica alebo jedna nasaditeľná služba. Vnútorné časti môžu byť reálne, kým vzdialené služby zostanú nahradené. Tento názov je užitočný najmä vtedy, keď „unit“ znamená pre rôznych ľudí niečo iné.

Integračný test preveruje spojenie dvoch alebo viacerých reálnych častí: aplikácie s databázou, služby s frontou správ, klienta s API alebo viacerých modulov. Odhaľuje chyby v serializácii, schéme, konfigurácii, transakciách a protokole, ktoré izolovaný test neuvidí. Integrácia však môže byť úzka — iba jedna hranica — aj široká cez viac služieb. Rozsah treba uviesť priamo v názve alebo dokumentácii testu.

Systémový test pozoruje zostavený produkt ako celok voči systémovým požiadavkám.

End-to-end test sleduje ucelený tok od jedného konca po druhý, napríklad od odoslania objednávky po rezerváciu skladu a potvrdenie. Často ide cez UI, ale nie je to podmienka: koncový tok možno spustiť aj cez API. Rovnako nie každý UI test je E2E — izolovaný test formulára v prehliadači môže zostať komponentovým testom. Hranice podrobne porovnáva článok Unit, integračné a end-to-end testy.

Testovacia pyramída bez dogmy odporúča skladať sadu z testov rôznej granularity. Neurčuje univerzálne percentá. Praktická otázka znie: na akej najnižšej úrovni vieme dané riziko dôveryhodne overiť a na ktorých hraniciach ešte potrebujeme dôkaz, že celok drží pohromade?

Druhy podľa cieľa: funkčnosť a vlastnosti kvality

Funkčné testovanie overuje, čo má systém urobiť. Kontroluje napríklad správny výpočet ceny, zamietnutie neplatného kupónu, oprávnenie používateľa alebo prechod objednávky do povoleného stavu. Pri identite musí pokrytie zohľadniť aj odlišné toky 2FA, OAuth a sociálneho prihlásenia. Zahŕňa pozitívne prípady, chybové vetvy, hraničné hodnoty aj obchodné pravidlá. Funkčný test môže bežať na ktorejkoľvek úrovni — od unit testu výpočtu až po celý nákup.

Nefunkčné testovanie skúma, ako systém svoju úlohu plní a aké vlastnosti má pri určených podmienkach. Nie je to jedna sada „ostatných“ testov. Každá vlastnosť potrebuje vlastné otázky, dáta, prostredie a kritériá:

• Výkonnostné testovanie meria odozvu, priepustnosť, využitie zdrojov a stabilitu pri definovanom zaťažení. Výkonnostné testovanie API a mikroslužieb ukazuje, čo merať pod UI; Core Web Vitals a záťažové testy zase oddeľujú skúsenosť v prehliadači od kapacity backendu. Rozdiel medzi load, stress, spike a soak testom spočíva v tvare a účele záťaže, nie iba v počte virtuálnych používateľov. Kapacitu preto nemožno odvodiť bez modelu prevádzky; praktický postup opisuje článok koľko používateľov web unesie. Pred behom určte aj to, čo možno bezpečne merať na stagingu a čo v produkcii. Pri vyhodnotení sledujte rozdelenie časov, pretože p95 a priemer hovoria o inom správaní.
• Bezpečnostné testovanie hľadá zneužiteľné slabiny v konkrétnom rozsahu. Môže zahŕňať kontrolu oprávnení, závislostí, konfigurácie, vstupov, autentifikácie či odolnosti proti známym triedam útokov. Automatický sken, revízia kódu a penetračný test poskytujú rozdielny typ dôkazu. Bezpečnostný test nie je automaticky úplný bezpečnostný audit ani potvrdenie súladu.
• Testovanie prístupnosti overuje, či ľudia s rôznymi schopnosťami dokážu obsah vnímať a ovládať. Automatická kontrola vie nájsť iba časť problémov, preto samotný skener prístupnosti nestačí. Užitočná kombinácia zahŕňa napríklad ručný prechod klávesnicou, kontrolu názvov a stavov prvkov a realistické scenáre, ako je prístupný checkout a formuláre. Audit voči zvoleným kritériám má širší rozsah než jeden automatizovaný test.
• Testovanie kompatibility preveruje podporované kombinácie prehliadačov, operačných systémov, zariadení, rozlíšení, jazykov, verzií alebo dátových formátov. Výber má vychádzať z podpornej politiky a používania, nie z pokusu pokryť všetko. Pri webe pomôže stratégia cross-browser testovania spolu s kontrolou jazykov, mien, dátumov a náhradného obsahu. Vzhľad naprieč kombináciami môže doplniť vizuálne regresné testovanie. Pri mobile treba rozumne kombinovať emulátory a reálne zariadenia a osobitne overiť systémové vstupy, napríklad notifikácie a deep linky Androidu. Desktopové aplikácie prinášajú vlastné hranice, ktoré približuje testovanie WPF a WinForms vrátane spúšťania WPF a WinForms testov v CI.

Funkčný a nefunkčný cieľ sa môžu stretnúť v jednom scenári, ale kritériá sa nesmú zliať. Nákup môže funkčne prejsť a zároveň trvať neprijateľne dlho; rýchla odpoveď zasa nemusí obsahovať správnu cenu. Každé tvrdenie potrebuje samostatné overenie.

Statické a dynamické, manuálne a automatizované

Statické testovanie hodnotí pracovný produkt bez spustenia testovaného kódu. Patrí sem revízia požiadaviek, návrhu, zdrojového kódu či testovacích prípadov a tiež automatická analýza. Dokáže odhaliť nejednoznačnú akceptačnú podmienku alebo rizikový tok ešte pred tým, než vznikne spustiteľná funkcia. Statické neznamená manuálne: analyzátor môže pracovať automaticky.

Dynamické testovanie testovaný kód spúšťa a porovnáva pozorované správanie s očakávaním. Môže ísť o ručný prieskumný scenár, unit test aj záťažový beh. Dynamický test ukáže správanie pri zvolených podmienkach; nepreukazuje, že sa systém správa správne pri všetkých možných vstupoch.

Pri manuálnom testovaní vykonáva kroky a vyhodnocuje výsledok človek. Je vhodné tam, kde rozhoduje pozorovanie, učenie a úsudok — napríklad pri prieskumnom testovaní novej funkcie alebo posúdení zrozumiteľnosti rozhrania. Pri automatizovanom testovaní vykoná opakovateľnú kontrolu nástroj. Hodí sa na časté, stabilné a jednoznačne vyhodnotiteľné scenáre, ale vyžaduje návrh, dáta, prostredie a údržbu.

Nejde o súboj dvoch tímov. Manuálne a automatizované testovanie sa dopĺňajú a rozhodnutie treba robiť po scenároch. Platí to aj pre malý tím bez samostatného testera, kde sa zodpovednosti rozdelia, ale potreba ľudského úsudku nezmizne. Pomôžu otázky kedy sa automatizácia oplatí a čo sa neoplatí automatizovať, nie cieľ dosiahnuť ľubovoľné percento automatizácie.

Black-box, white-box a prieskumné testovanie

Ďalšie názvy opisujú, z akých informácií test vychádza. Pri black-box testovaní sa tester pozerá na vstupy a pozorovateľné výstupy bez toho, aby test odvodzoval z vnútornej implementácie. Takto možno overovať verejné API, formulár aj celý systém. Znalosť obchodného kontextu pritom nie je zakázaná; „čierna skrinka“ pomenúva pohľad na správanie, nie neinformovanosť človeka.

Pri white-box testovaní návrh kontroly využíva znalosť kódu alebo štruktúry. Test môže cieliť na konkrétnu vetvu rozhodovania, dátový tok alebo ošetrenie výnimky. Štrukturálne pokrytie pomôže nájsť nevykonané miesta, no samotný prechod riadkom ešte neukazuje, že test overil správny výsledok. Grey-box testovanie je praktické pomenovanie kombinácie: test používa verejnú hranicu, ale scenáre a diagnostiku vyberá so znalosťou architektúry, databázy či protokolu.

Prieskumné testovanie je spôsob práce, pri ktorom sa učenie o produkte, návrh testu a jeho vykonanie priebežne ovplyvňujú. Tester si môže určiť časovo ohraničenú misiu, napríklad preskúmať správanie košíka pri súbežnej zmene ceny, a podľa zistení meniť ďalšie kroky. Nie je to náhodné klikanie bez cieľa ani opak manuálneho scenára. Automatizované nástroje môžu pomôcť pripravovať dáta, meniť vstupy či zbierať dôkazy, zatiaľ čo smer skúmania určuje človek.

Ani tieto pojmy neurčujú úroveň. Black-box kontrola môže byť komponentová aj E2E; white-box prístup sa môže použiť v integračnom teste. Pri plánovaní si preto zaznamenajte, či potrebujete potvrdiť požiadavku zvonka, preskúmať vnútornú štruktúru alebo objavovať riziká, ktoré ešte nemajú pevný scenár.

API a UI testy opisujú vstup do systému

API test komunikuje cez programové rozhranie bez preklikávania obrazoviek. Vie presne pripraviť vstup, overiť stavový kód, telo odpovede, schému, oprávnenie aj vedľajší účinok. Pre rozhodovanie pomôže zoznam čo testovať na API a praktický postup testovania REST API. Asynchrónne hranice potrebujú aj scenáre pre podpis, duplicity a oneskorené webhooky či pre spúšťače a duplicity transakčných e-mailov. Pri cudzej službe treba vedome zvoliť mock, sandbox alebo reálnu službu. Pri vzťahoch medzi službami pridáva iný druh istoty kontraktné testovanie, ktoré stráži zaznamenané očakávania klienta a poskytovateľa.

UI test ovláda alebo vykresľuje používateľské rozhranie. Potvrdí, že človek dokáže prvok nájsť, vyplniť a použiť a že vrstvy pod ním sú správne prepojené v rozsahu testu. Býva však citlivejší na stav dát, časovanie a zmeny rozhrania. Preto nie je účelné presúvať každú kombináciu cez prehliadač; článok prečo stovky UI testov nenahradia API testy vysvetľuje rozdiel v type pokrytia.

Obe rozhrania možno použiť na rôznych úrovniach. API test môže izolovať jednu službu alebo prejsť celý systém. UI test môže overiť komponent alebo kompletný nákup od košíka po platbu. O rozsahu rozhodujú skutočne zapojené časti, nie použitý ovládač.

Smoke, sanity, regresné a akceptačné testy

Tieto názvy opisujú najmä účel výberu a okamih, v ktorom test spúšťame:

• Smoke test je krátka, široká kontrola, či zostava alebo nasadenie vôbec umožňuje pokračovať v ďalšom testovaní. Overí napríklad štart aplikácie, prihlásenie, načítanie katalógu a dostupnosť kľúčového API. Nemá nahradiť hĺbkovú regresiu.
• Sanity test je úzky, cielený výber po menšej zmene alebo oprave. Potvrdí, že upravená oblasť dáva základný zmysel a že sa oplatí investovať do ďalších kontrol. V praxi firmy termíny smoke a sanity niekedy zamieňajú; dôležitejší je dohodnutý rozsah a brána, ktorú výsledok ovláda.
• Regresné testovanie zisťuje, či zmena nepoškodila predtým fungujúce správanie. Výber môže byť malý pri pull requeste a širší pred releasom alebo v noci. Dobrý regresný balík sa riadi dosahom zmeny a rizikom, nie mechanickým spustením všetkého; pravidelne v ňom posúďte aj ktoré testy možno zmazať bez straty dôležitého pokrytia.
• Akceptačné testovanie overuje, či riešenie spĺňa dohodnuté potreby a podmienky prijatia. Môže byť automatizované aj manuálne a prebiehať na API či UI. Akceptačný test teda nie je synonymom E2E; jednoduché obchodné pravidlo možno akceptovať aj na nižšej úrovni, ak tam vzniká dôveryhodný dôkaz.

Tieto výbery sa môžu prekrývať. Jeden kľúčový akceptačný scenár môže patriť aj do regresie a jeho skrátená verzia do smoke sady. V CI/CD je užitočné rozdeliť testy podľa bodu a rýchlosti spätnej väzby namiesto jedného dlhého balíka pre každú zmenu. Ak rovnaké testy lokálne prejdú, ale v CI padajú, samostatne overte rozdiely prostredia, dát, paralelizácie a času.

Ako vybrať vhodnú kombináciu testov

Začnite rozhodnutím, nie katalógom názvov. Pre jednu funkciu alebo zmenu prejdite tento postup:

1. Pomenujte následok zlyhania. Čo sa stane používateľovi a firme, ak je výsledok nesprávny, pomalý, nedostupný, neprístupný alebo zneužiteľný? Zohľadnite závažnosť aj pravdepodobnosť.
2. Rozdeľte tok na pravidlá a hranice. Pri objednávke sú pravidlami výpočet ceny a povolené stavy; hranicami databáza, sklad, platba, e-mail a UI. Každá kritická hranica potrebuje primeraný dôkaz.
3. Zvoľte najnižšiu dôveryhodnú úroveň. Kombinácie zliav patria prevažne k unit alebo komponentovým testom. Serializácia objednávky a zápis do databázy k integračným. Niekoľko reprezentatívnych ciest potvrdí systémový alebo E2E scenár.
4. Doplňte ciele kvality. Funkčný scenár nepovie, koľko súbežných objednávok systém unesie, či je ovládateľný klávesnicou ani či bežný používateľ získa cudzie dáta. Pre relevantné riziká určte samostatné nefunkčné kontroly a kritériá.
5. Vyberte rozhranie a spôsob. API býva účelné pre množstvo dátových kombinácií; UI pre kľúčové interakcie. Opakovanú stabilnú kontrolu zvážte na automatizáciu, novú alebo nejednoznačnú oblasť preskúmajte človekom. Potrebné dáta navrhujte zámerne — kópia produkčnej databázy nie je testovacia dátová stratégia a E2E behy potrebujú nezávislé, opakovateľné testovacie dáta.
6. Určte okamih behu a reakciu. Rýchla sada môže bežať pri každej zmene, smoke test po nasadení a širšia regresia podľa rizika. Pri každom zlyhaní musí byť jasné, či blokuje zlúčenie, nasadenie alebo vyžaduje vyšetrovanie. Sledujte aj nestabilitu; náhodne padajúce testy znižujú dôveru vo výsledok.
7. Skontrolujte dôkaz a medzery. Test musí mať zmysluplné očakávanie, vlastníka a čitateľný výsledok. QA metriky majú ukázať riziko a čas spätnej väzby, nie iba rastúci počet testov.

Takto môže jeden release obsahovať stovky rýchlych unit kontrol pravidiel, desiatky komponentových a integračných testov, kontrakty medzi službami, malý počet E2E ciest, cielenú regresiu, smoke po nasadení a osobitný výkonnostný či prístupnostný test. Presný pomer závisí od architektúry a rizík produktu.

Testovanie, monitoring a audit nie sú to isté

Testovanie vytvára dôkaz o správaní pri vybraných podmienkach a v konkrétnom čase. Monitoring priebežne zbiera signály z bežiacej prevádzky a má podporiť odhalenie a riešenie incidentu. Syntetická kontrola môže technicky vykonávať podobný scenár ako automatizovaný test, ale jej prevádzkový účel, frekvencia, bezpečné dáta a upozornenia sú iné. Rozdiel približuje syntetický monitoring po release aj porovnanie syntetického a reálneho používateľského monitoringu. Produkčný scenár treba navrhnúť tak, aby nevytváral falošné objednávky ani nepoškodzoval dáta. Samotný signál dostupnosti navyše nemusí odhaliť pokazený nákup, preto uptime nestačí.

Audit je systematické posúdenie vymedzeného produktu, procesu alebo dôkazov voči dohodnutým kritériám. Môže používať výsledky testov, revízie aj rozhovory, ale nie je synonymom testovacieho behu. QA audit napríklad hodnotí pokrytie rizík, proces, prostredia a zdravie sady; nepridáva automaticky chýbajúce testy ani nepreberá nepretržité sledovanie produkcie.

Tieto tri činnosti sa dopĺňajú. Testy znižujú neistotu pred zmenou, monitoring ukazuje skutočnú prevádzku a audit pomáha nájsť systémové medzery. Jedna vrstva však nemá vytvárať falošný pocit, že nahradila ostatné.

Čo získate presnejším pomenovaním

Keď tím triedi testy podľa viacerých osí, ľahšie uvidí, že má napríklad veľa automatizovaných UI regresií, ale žiadne integračné kontroly platobnej hranice alebo výkonnostné kritérium. Presnejšie názvy tiež zlepšujú diagnostiku: zlyhaný úzky integračný test ukazuje inú oblasť než celý E2E tok.

Prínosom nie je dokonale vyplnená taxonómia. Je ním kratšia cesta k dôveryhodnému výsledku, menej duplicitných kontrol a vedomé pokrytie rizík, ktoré môžu zasiahnuť používateľa alebo firmu.

Ďalší krok

Vyberte desať najdôležitejších scenárov produktu a ku každému vytvorte jeden riadok so šiestimi údajmi: riziko, testovaná vlastnosť, hranica systému, úroveň, rozhranie a okamih spustenia. Potom označte duplicity, chýbajúce hranice a testy bez jasného očakávania. Tento malý audit vám dá konkrétny zoznam presunov a doplnení skôr, než začnete kupovať nástroj alebo rozširovať sadu.