Full stack testing – komplexné testovanie od frontendu po databázu

Full stack testing (niekedy písané aj ako fullstack testing) je moderný prístup k testovaniu softvéru, ktorý zahŕňa overovanie funkčnosti aplikácie naprieč celým technologickým stackom – od používateľského rozhrania (frontend), cez aplikačnú logiku a API (backend), až po databázu a ďalšie systémy na pozadí. Cieľom full stack testingu je zabezpečiť, že všetky vrstvy aplikácie spolu správne spolupracujú a výsledný systém spĺňa požiadavky ako celok. Analogicky ako full stack developer pracuje na frontende aj backende, full stack tester alebo tím aplikujúci full stack testing preveruje aplikáciu komplexne na všetkých úrovniach.

Čo je full stack testing?

Full stack testing predstavuje holistický spôsob testovania, v ktorom sa aplikácia testuje end-to-end naprieč všetkými jej vrstvami. Namiesto toho, aby sa testovalo iba používateľské rozhranie alebo iba jednotlivé API volania izolovane, full stack prístup kombinuje viacero úrovní testov. Zahŕňa to napríklad automatizované testy používateľských scenárov v prehliadači, priame volania na backend API služby, kontrolu údajov priamo v databáze, a prípadne aj testy ďalších komponentov ako sú externé integrácie, front-endové a back-endové validačné logiky, či dokonca testy výkonu a bezpečnosti.

Jednoducho povedané, pri full stack testingu sa pozeráme na aplikáciu ako na jeden celok. Tester pri jednom scenári môže overiť nielen to, že napríklad webová stránka správne zobrazila údaje používateľovi, ale aj to, že tieto údaje sa správne preniesli cez API a uložili do databázy. Takýto prístup pomáha odhaliť chyby, ktoré by pri izolovanom testovaní jednotlivých častí zostali skryté. Full stack testing nie je úplne to isté čo klasické “end-to-end” testovanie z pohľadu používateľa – hoci end-to-end testy sú jeho súčasťou, full stack prístup zahŕňa aj detailnejšie kontroly “pod kapotou” (napríklad spomínanú kontrolu databázy či API odpovedí) v rámci týchto scenárov.

Prečo je full stack testing dôležitý a ako sa líši od iných prístupov?

V minulosti sa testovanie často delilo podľa vrstiev – napríklad jedna skupina testerov sa venovala len UI testom a iná zase testovala backend alebo databázu. Tradičné prístupy môžu zahŕňať iba manuálne klikanie cez používateľské rozhranie alebo písanie automatizovaných testov výhradne pre frontendovú časť. Naopak vývojári zas pokrývajú kód jednotkovými testami, ktoré však pokryjú len logiku v izolácii. Full stack testing tieto hranice stiera a sústreďuje sa na prepojenie všetkých vrstiev.

Tento prístup vznikol aj ako reakcia na moderné architektúry aplikácií. Dnešné systémy často nie sú monolitické – pozostávajú z množstva mikroservisov, frontend aplikácií komunikujúcich s API, databáz v cloude a integrácií na služby tretích strán. Ak by sme testovali iba jednu vrstvu (napríklad len UI alebo len jednotlivé služby oddelene), ľahko nám uniknú chyby na rozhraní medzi vrstvami. Napríklad automatický test môže cez webové rozhranie úspešne odoslať formulár platby a zobraziť správu o úspechu, ale bez kontroly databázy nezistíme, či sa platobná transakcia naozaj zapísala do systému. Podobne API môže vracať korektné odpovede pri izolovanom teste, ale až spojenie s frontendom môže odhaliť, že určité pole chýba a aplikácia kvôli tomu zlyhá. Full stack testing je dôležitý práve preto, že umožňuje zachytiť takéto medzery a zaručiť, že všetky časti systému spolu ladia.

Oproti tradičnému testovaniu zameranému len na jednu oblasť prináša full stack prístup viac istoty v kvalite. Tester, ktorý rozumie celému stacku aplikácie, dokáže efektívne komunikovať aj s vývojármi frontendu aj backendu a vie lepšie izolovať príčinu problému. Kým napríklad “bežný” tester by pri chybe viditeľnej na UI mohol len nahlásiť, že “niečo nefunguje” a čakať na analýzu vývojárov, full stack tester vie sám preskúmať, či problém nastal v frontende (napr. chybná validácia vstupu), v API (napr. nesprávny formát dát), alebo v databáze (napr. neuložené dáta). Tým sa urýchľuje odstraňovanie chýb a zlepšuje spolupráca medzi tímami. Full stack testing sa tiež líši od tzv. SDET (Software Development Engineer in Test) prístupu – kým SDET (často samotný vývojár) píše hlavne jednotkové a integračné testy na úrovni kódu, full stack tester pristupuje k systému skôr z perspektívy celkovej funkčnosti a používateľských scenárov, no zároveň neignoruje interné vrstvy.

Aké typy testovania zahŕňa full stack testing?

Ako už bolo naznačené, full stack testing nie je jeden konkrétny typ testu, ale skôr kombinácia viacerých druhov testovania naprieč vrstvami aplikácie. Medzi kľúčové súčasti patria:

• Testovanie frontendu (UI): Kontrola toho, čo vidí a robí koncový používateľ. Patrí sem funkčné testovanie webového alebo mobilného rozhrania – či už manuálne alebo pomocou automatizovaných nástrojov. Cieľom je overiť, že používateľské rozhranie správne zobrazuje údaje, reaguje na vstupy (kliknutia, zadávanie textu) a funguje na rôznych zariadeniach a prehliadačoch. Pri automatizácii frontend testov sa simulujú akcie používateľa (napr. vyplnenie formulára, kliknutie na tlačidlo) a kontroluje sa, že aplikácia na ne reaguje očakávaným spôsobom (zobrazenie potvrdenia, navigácia na inú stránku a pod.).
• Testovanie API a integrácií: Overovanie serverovej časti aplikácie – napríklad testy REST API alebo GraphQL rozhraní, ktoré používajú frontend alebo iné služby. Tieto testy sa zameriavajú na správnosť odpovedí (formát JSON/XML, status kódy), logiku biznis pravidiel na backendovej strane a aj na to, či API korektne komunikuje s databázou či inými službami. Do tejto kategórie patrí aj integračné testovanie medzi jednotlivými mikroslužbami a kontraktné testovanie (contract testing), ktoré zabezpečuje, že napríklad frontendový klient a backendová služba majú zhodné očakávania o formáte dát, ktoré si vymieňajú.
• Testovanie databázy a dátovej vrstvy: Kontrola správnosti uložených dát, databázových operácií a konzistencie údajov. Testuje sa, či sa požadované záznamy ukladajú do databázy, či sa dajú načítať a či napríklad nedochádza ku konfliktom alebo strate dát. Patrí sem aj overenie dátových migrácií, schémy databázy (či tabuľky obsahujú potrebné stĺpce, indexy, relácie) a testovanie rôznych scenárov práce s dátami (transakcie, rollback pri chybách, správne fungovanie CRUD operácií). Napríklad ak aplikácia má zobrazovať len aktívnych používateľov, tester nielenže skontroluje na UI, že na stránke vidí len používateľov označených ako aktívnych, ale zároveň môže vykonať dotaz priamo na databázu a overiť, že tabuľka používateľov obsahuje práve týchto aktívnych používateľov a žiadnych neaktívnych v danom výpise. Tým sa získa istota, že logika filtrovania funguje správne nielen navonok, ale aj na úrovni uložených dát.

Full stack testing v širšom zmysle môže zahŕňať aj ďalšie oblasti testovania, ako je výkonnostné testovanie (load/stress testy celého systému) alebo bezpečnostné testovanie (hľadanie zraniteľností naprieč aplikáciou). Avšak základom full stack testovacieho prístupu sú najmä funkčné testy naprieč frontend, API a databázovou vrstvou.

Full stack testing v praxi: nástroje a príklady

Pri zavádzaní full stack testingu sa využíva kombinácia rôznych testovacích nástrojov a rámcov, z ktorých každý je vhodný na inú vrstvu. Tu sú niektoré praktické príklady, ako možno testovať celý stack aplikácie:

Testovanie frontendu: Cypress a Playwright

Moderné webové aplikácie sa často testujú pomocou nástrojov ako Cypress alebo Playwright. Ide o automatizačné frameworky, ktoré umožňujú simulovať akcie používateľa priamo v prehliadači a overovať očakávané správanie aplikácie. Napríklad pomocou Cypressu vie tester napísať skript, ktorý otvorí webovú stránku s formulárom, vyplní do formulára testovacie údaje a odošle ho. Následne Cypress skontroluje, či sa na stránke zobrazilo potvrdenie o úspešnom odoslaní. Zároveň je možné sledovať sieťovú komunikáciu – Cypress aj Playwright umožňujú zachytávať HTTP požiadavky a odpovede – takže tester vie overiť, že odoslanie formulára vyvolalo napríklad API volanie na správny URL s očakávanými dátami a že server vrátil korektnú odpoveď. Týmto spôsobom už frontend test pokrýva nielen UI vrstvu, ale čiastočne aj backendovú logiku. Playwright je podobný nástroj (podporovaný Microsoftom) a okrem webových prehliadačov umožňuje aj automatizáciu mobilných aplikácií. Oba nástroje podporujú viacero programovacích jazykov a dokážu testovať vo viacerých prehliadačoch (Chrome, Firefox, Safari aj vo headless režime pre rýchlejšie behy testov). Tým pádom môže full stack tester overiť používateľské scenáre naprieč rôznymi platformami automatizovane.

Testovanie API a kontraktov: Postman a Pact

Pre testovanie API rozhraní sa osvedčili nástroje ako Postman alebo programové knižnice typu REST Assured (pre Java) či SuperTest (pre Node.js). Pomocou Postmana môže tester jednoducho posielať požiadavky na API endpointy a písať k nim automatizované testy (napríklad overiť, že volanie POST /api/login vráti status kód 200 a obsahuje v tele odpovede token). Tieto API testy možno zoskupovať do kolekcií a začleniť do CI/CD pipeline, takže sa spustia pri každej zmene kódu.

Špecifickou kategóriou je kontraktné testovanie s nástrojom Pact. Pact umožňuje definovať tzv. kontrakt medzi dvoma službami – typicky medzi klientom (napr. frontendovou aplikáciou) a serverovým API. Napríklad frontendový tím pomocou Pactu nadefinuje, že “očakáva od používateľskej služby API, že na volanie GET /api/v1/users vráti pole objektov s vlastnosťami id, name a status”. Tento kontrakt sa uloží a na druhej strane sa automaticky spustí test na backendovú službu, ktorý overí, či jej skutočná odpoveď tomuto kontraktu vyhovuje. Ak backend zmení formát dát (napr. premenuje status na state) a neinformuje o tom frontend, kontraktný test Pactu to odhalí ešte predtým, než sa služby spoja v reálnom prostredí. Pact tak pomáha tímom pracujúcim oddelene (mikroservisová architektúra, samostatné release cykly frontendu a backendu) zabrániť neočakávaným integračným chybám. Kontraktné testovanie je rýchle (beží len proti simulovaným požiadavkám) a môže výrazne zvýšiť dôveru v nasadenie, že jednotlivé časti systému budú spolu komunikovať správne, bez nutnosti čakať na plnohodnotné end-to-end testy v spoločnom prostredí.

Testovanie databázy a backendu: Testcontainers a integračné testy

Na úrovni databázy a serverovej logiky prichádzajú k slovu integračné testy, ktoré môžu byť písané napríklad v tom istom jazyku ako aplikácia. Aby boli tieto testy spoľahlivé a čo najviac sa podobali produkčnému prostrediu, dá sa využiť nástroj Testcontainers. Testcontainers je knižnica (dostupná pre viacero jazykov vrátane Java, Python, .NET), ktorá dokáže pred spustením testov automaticky rozbehnúť potrebné služby v Docker kontajneroch – typicky databázy, ale aj message queue systémy či iné závislosti. Tester alebo vývojár tak môže napísať test, ktorý napríklad vytvorí novú PostgreSQL databázu v kontajneri, aplikuje na ňu aktuálnu databázovú schému aplikácie a spustí proti nej sériu testov. V týchto testoch sa priamo volajú funkcie aplikácie (alebo API endpointy) a následne sa overuje obsah databázy. Napríklad test môže zavolať metódu aplikácie na vytvorenie novej objednávky a potom SQL dotazom overiť, že v tabuľke orders pribudol nový riadok s očakávanými hodnotami. Po dobehnutí testov Testcontainers kontajner s databázou zruší. Výhodou tohto prístupu je, že každá testová sada má izolované testovacie prostredie veľmi podobné produkcii – odpadá problém zdieľaných testovacích databáz, kde si testy navzájom prekazia dáta. Zároveň sa odhalia potenciálne problémy s kompatibilitou, ktoré by pri použití len v pamäti bežiacej „fake“ databázy (napr. SQLite namiesto PostgreSQL) mohli uniknúť. Integračné testy s reálnymi komponentmi sú síce pomalšie než jednotkové testy, ale v rámci full stack testingu poskytujú vysokú mieru istoty, že core logika aplikácie funguje správne v celom kontexte.

Okrem Testcontainers existujú aj ďalšie pomôcky – napríklad rôzne in-memory databázy či simulované služby – tie však nemusia vždy dokonale napodobniť reálne prostredie. Preto sa čoraz viac preferuje testovanie s produkčným ekvivalentom komponentov (napr. použitie skutočného databázového engine v kontajneri namiesto h2 databázy). Full stack tester v praxi často kombinuje tieto prístupy: využíva testy na úrovni kódu a databázy počas vývoja (s podporou vývojárov), a následne celkové end-to-end scenáre cez UI, čím pokryje aplikáciu od základných jednotkových častí až po finálnu používateľskú skúsenosť.

Výzvy a problémy pri full stack testingu

Zavedenie full stack testing prístupu prináša aj viaceré výzvy, na ktoré treba pamätať:

• Flaky testy (nestabilné testy): Čím komplexnejší test (najmä end-to-end cez UI), tým väčšie riziko, že test raz prejde a inokedy zlyhá z nejasných príčin. Môže ísť o problémy so synchróniou (napr. test sa snaží kliknúť skôr, než sa načítala stránka), závislosti na sieťovej latencii, alebo zdieľané testovacie prostredie, kde sa testy ovplyvňujú navzájom. Flaky testy znižujú dôveru v testovaciu sadu – ak testy často padajú “na falošný poplach”, tím ich začne ignorovať, čo je nebezpečné.
• Dlhý čas behu testov: Testovanie celého stacku zvykne byť pomalšie než testovanie jednotlivo. End-to-end scenáre musia napríklad spustiť prehliadač, prejsť viacerými obrazovkami aplikácie a komunikovať so serverom a databázou, čo trvá rádovo sekundy až minúty na test. Pri väčšom počte takýchto testov môže testovacia fáza v CI pipeline trvať príliš dlho a spomaľovať nasadzovanie zmien.
• Komplexná údržba testov: Full stack testy často vyžadujú písanie kódu v rôznych nástrojoch (napr. JavaScript pre Cypress testy, Java/Python pre API alebo DB testy). Udržiavať všetky tieto skripty konzistentné a aktuálne je náročné. Ak sa zmení napríklad dizajn frontendu, musia sa upraviť UI testy (selektory, postupy). Ak sa refaktoruje API alebo databáza, je potrebné aktualizovať integračné testy a kontrakty. To kladie vyššie nároky na priebežnú údržbu – testy sa stávajú súčasťou kódu aplikácie, o ktorú sa treba starať.
• Náročnosť nastavenia prostredia: Aby full stack testy bežali spoľahlivo, potrebujeme testovacie prostredie, kde je dostupný frontend, backend aj databáza (prípadne ďalšie komponenty). To môže znamenať spúšťanie viacerých služieb naraz (napr. pomocou kontajnerizácie alebo v cloudovom testovacom prostredí). Nastaviť a udržiavať takú infraštruktúru pre testy môže byť zložité. Navyše, keď viacero testerov alebo CI agentov spúšťa testy súbežne, prostredie musí byť izolované (opäť úloha pre kontajnery alebo virtuálne stroje).
• Vyžaduje široké zručnosti: Full stack tester alebo tím praktizujúci tento prístup potrebuje znalosť viacerých technológií. Testeri sa musia vyznať v HTML/CSS a JavaScripte kvôli UI testom, zároveň rozumieť REST API, JSON či práci s databázovými dotazmi (SQL). Tiež prichádza do hry znalosť automatizačných nástrojov, programovania a možno aj základy DevOps (na spustenie kontajnerov, nastavenie CI). Pre jednotlivca je to výzva udržať si prehľad vo všetkých vrstvách, takže často ide o tímovú spoluprácu, kde si členovia delia kompetencie.

Tipy pre efektívny full stack testing

Aby full stack testing prinášal želané ovocie a neprevážili jeho úskalia, oplatí sa dodržiavať niekoľko osvedčených postupov:

• Začnite v malom a postupne rozširujte pokrytie: Nemusíte odrazu automatizovať všetky scenáre cez celý stack. Identifikujte najkritickejšie business scenáre (napríklad proces registrácie, platby, vytvorenie objednávky) a začnite nimi. Postupne pridávajte ďalšie testy. Tým zaistíte, že testovacia sada nebude spočiatku príliš pomalá a tím si stihne nastaviť procesy údržby.
• Dodržiavajte testovaciu pyramídu: Populárny koncept testovacej pyramídy hovorí, že najviac by malo byť rýchlych jednotkových testov, menej integračných a najmenej najťažších end-to-end testov. Fullstack testing neznamená mať stovky UI testov na každý detail – tie by sa stali nočnou morou. Namiesto toho kombinujte vrstvy: pokryte čo najviac logiky jednotkovými a API testami, a full stack (UI) testy použite pre kľúčové používateľské toky. Tak získate dobré pokrytie aj rýchlu spätnú väzbu.
• Automatizujte testy v rámci CI/CD: Integrujte vaše testy do kontinuálnej integrácie a nasadzovania. Každý nový commit by mal spustiť príslušné sady testov. Jednotkové a API testy môžu bežať pri každej zmene (sú rýchle), komplexnejšie full stack testy napríklad v nightly builde alebo pred releasom. Dôležité je, aby sa testy spúšťali pravidelne a spoľahlivo – len tak odhalia regresie včas. Využite paralelné behy (napr. viacero agentov spúšťa rôzne testy súbežne), aby ste skrátili čas čakania na výsledky.
• Dbajte na stabilitu a údržbu testov: Bojujte proti flakiness – píšte testy robustne. Používajte explicitné čakania alebo opakované pokusy tam, kde viete, že môže dochádzať k časovým oneskoreniam (napr. počkajte, kým sa načíta stránka alebo kým API vráti odpoveď). Vyhýbajte sa magickým konštantám typu “sleep 5 seconds” – radšej čakajte na konkrétny prvok alebo udalosť. Ak test občas zlyhá z nejasných príčin, venujte čas analýze príčiny – nestabilné testy radšej dočasne označte a opravte, než by ste ich mali ignorovať. Takisto priebežne refaktorujte testy spolu so zmenami v kóde aplikácie. Ideálne je, ak vývojári pri zmene funkcionality upravia aj zodpovedajúce testy (či už jednotkové alebo integračné). Udržujte testovací kód čistý a prehľadný podobne ako produkčný kód.
• Izolujte testovacie prostredia: Ak je to možné, nastavte si pre automatizované testy vlastné prostredie (napr. staging databázu, testovací server), kde máte kontrolu nad dátami. Používajte nástroje ako Testcontainers alebo kontajnerovú orchestráciu (docker-compose, Kubernetes) na spúšťanie celého stacku pre testovacie účely. Tým predídete ovplyvňovaniu produkčných dát a zároveň zabezpečíte, že testy budú reprodukovateľné (každý test začne s čistým prostredím).
• Zdieľajte znalosti a spolupracujte: Full stack testing presahuje kompetencie jednej osoby. Zapojte do testovania vývojárov – napríklad pri nastavovaní kontraktných testov alebo pri príprave testovacích hookov (API na vyčistenie databázy a podobne). Naopak, tester by sa mal zaujímať o architektúru aplikácie a nové technológie v projekte. Pravidelne komunikujte v tíme o tom, čo sa automaticky pokrýva testami a kde sú rizikové miesta. Spoločným cieľom je predsa kvalitný softvér, a full stack testing funguje najlepšie, keď QA a vývoj ťahajú za jeden povraz.

FAQ: Časté otázky o full stack testingu

Čo presne znamená full stack testing?
Ide o prístup k testovaniu, kde sa softvér testuje naprieč všetkými vrstvami technológie – od frontendu (používateľského rozhrania) cez aplikačný backend a API až po databázu a ďalšie komponenty. Full stack testing znamená, že tester (alebo automatizovaný test) preveruje, či systém funguje korektne ako celok. Na rozdiel od testovania zameraného len na jednu úroveň tak dokáže odhaliť chyby v integrácii medzi vrstvami (napr. nekonzistenciu medzi tým, čo zobrazuje UI a čo je uložené v databáze).

Ako sa líši full stack testing od end-to-end testovania?
End-to-end (E2E) testovanie zvyčajne označuje testy, ktoré simulujú reálne použitie aplikácie z pohľadu používateľa – napríklad test prejde celý scenár od prihlásenia až po vytvorenie objednávky a skontroluje očakávaný výsledok. Full stack testing toto zahŕňa, ale ide o širší pojem. Kým end-to-end testy obvykle prebiehajú cez používateľské rozhranie, full stack testing zahŕňa aj testy, ktoré bežia “pod povrchom”. Napríklad okrem E2E scenára cez UI môže full stack tester otestovať tú istú funkcionalitu priamo cez volanie API a kontrolu databázy. Full stack testing teda kombinuje end-to-end testy s ďalšími druhmi testovania tak, aby bola pokrytá celá architektúra aplikácie.

Kto je full stack tester?
Je to tester (QA inžinier), ktorý má schopnosti a znalosti pokrývajúce viacero vrstiev aplikácie. Full stack tester vie testovať webové rozhranie (napr. písať automatizované skripty v Cypress/Playwright), rozumie API volaniam a formátom dát (vie napríklad pracovať s nástrojmi ako Postman alebo písať skripty využívajúce API), a zároveň sa vyzná aj v databázach či logoch servera, takže dokáže overiť správnosť údajov priamo na úrovni databázových záznamov. Takýto tester dokáže efektívne navrhovať testy, ktoré prelínajú všetky tieto časti – napríklad pripraviť testovací scenár, ktorý odošle požiadavku na server, skontroluje odpoveď a následne otvorí webovú stránku, aby overil, že údaje zodpovedajú tomu, čo bolo uložené. Full stack tester býva veľmi cenný v agilných tímoch, kde sa vyžaduje flexibilita a široký prehľad.

Aké nástroje sa používajú na full stack testing?
Kombinujú sa nástroje pre rôzne úrovne. Na automatizované testovanie frontendovej časti sú populárne Cypress a Playwright (prípadne Selenium WebDriver či TestCafe). Pre testovanie API sa používajú napríklad Postman, REST Assured, SoapUI alebo Pact (na kontraktné testy). Databázové testy a integračné testy backendu sa dajú robiť buď priamo v kóde (napr. pomocou unit test frameworkov daného jazyka spolu s knižnicou Testcontainers na sprístupnenie databázy v testoch), alebo pomocou nástrojov ako DBUnit. Okrem toho v rámci full stack testingu môžu prísť vhod nástroje na testovanie výkonu (napr. JMeter, Gatling) a bezpečnostné skenery (napr. OWASP ZAP) – tie síce často vykonávajú špecialisti, ale zapadajú do overenia kvality celého stacku. Výber nástrojov vždy závisí od konkrétnej technológie a potrieb projektu.

Ako začať s full stack testingom v tíme?
Odporúča sa začať postupne. Identifikujte kritické end-to-end scenáre, ktoré majú najväčší dopad na biznis (napríklad spomínané objednávky, platby, registrácia nového užívateľa). Začnite ich automatizovať pomocou vhodných nástrojov – napríklad vytvorte niekoľko skriptov v Cypress, ktoré prechádzajú tieto flows. Paralelne nastavte testovanie API – môžete si vytvoriť kolekciu testov v Postmane alebo písať integračné testy v kóde aplikácie. Zapojte vývojárov, aby vám pomohli nastaviť testovaciu databázu alebo API endpoints pre testy (napr. endpoint na vygenerovanie testovacích dát). Zavádzajte tiež kontraktné testy, ak máte viacero služieb. Dôležité je komunikovať v tíme, že kvalita je spoločná zodpovednosť – fullstack testing nie je úloha navyše pre testerov, ale spôsob práce, kde vývoj aj QA spolupracujú na pokrytí celého systému testami. Postupne môžete rozšíriť testovaciu sadu, pridať ju do CI pipeline a dolaďovať procesy (reportovanie chýb, vyhodnocovanie testov, údržba). Začnite s malým počtom spoľahlivých testov a postupne budujte širšie pokrytie.

Zdroje:

• QA Touch – Demystifying the Role of a Full Stack Tester: What You Need to Know (Cristina Barnutiu, 2023)
• testRigor – Full-Stack Tester: Role and Skills (Hari Mahesh)
• Testscenario – What is Full Stack Testing? (Rimpal Mistry, 04/04/2025)
• Testcontainers – What is Testcontainers, and why should you use it? (official documentation)
• Pact Docs – Introduction to Pact (Contract Testing)