Většina testovacích případů selže ještě dříve, než odhalí jedinou chybu. Jsou napsány jako vágní kontrolní seznamy, postrádají předběžné podmínky, sdružují více akcí do jednoho kroku nebo popisují očekávané výsledky tak neurčitě, že dva testeři, kteří čtou stejný případ, by se neshodli na tom, co znamená „úspěšný“. Výsledek: chyby proklouznou, testovací běhy nelze reprodukovat a zajištění kvality se stává úzkým hrdlem namísto záchranné sítě.
Psaní dobrého testovacího případu není tolik o testovacích dovednostech, jako spíše o návrhu ověřování. Ve finančních službách se tomu říká proces „maker-checker“. V jaderném velení se tomu říká pravidlo dvou osob. Princip je stejný: kritická práce by se nikdy neměla spoléhat na jedinou neověřenou akci. Dobře napsaný testovací případ vnáší stejnou přísnost do softwaru. Odděluje to, co očekáváte, od toho, co pozorujete, takže rozdíl mezi těmito dvěma je nemožné přehlédnout.
Ukážeme vám, jak psát testovací případy, proč jsou důležité a jak postupně zlepšovat jejich kvalitu.
TL;DR
Testovací případ definuje přesné kroky, vstupní údaje a očekávané výsledky potřebné k ověření, že daná funkce pracuje správně. Každý z nich musí mít jedinečné ID, předběžné podmínky a očekávané výsledky, aby bylo možné výsledek zkontrolovat. Tato příručka popisuje sedmikrokový proces psaní, uvádí tři praktické příklady a vysvětluje, jak zajistit spolehlivost sady testů i při změnách produktu.
Co jsou testovací případy?
Testovací případ je strukturovaný dokument, který definuje přesné kroky, vstupy, předpoklady a očekávané výsledky potřebné k ověření, zda se konkrétní software chová správně. Nejedná se o testovací plán (který nastiňuje strategii testování) ani o testovací skript (automatizovaný kód, který kroky provádí programově). Testovací případ je specifikace, na které jsou oba tyto dokumenty založeny.
Příklad: Testujete funkci přihlášení ve webové aplikaci. Testovací případ pro tuto funkci by definoval následující prvky:
- Akce, které popisují kroky prováděné uživatelem a očekávané reakce systému
- Podmínky, které definují pravidla, která musí být splněna, aby systém mohl pokračovat v jednotlivých krocích
- Zadejte vstupní data s příkladovými hodnotami, abyste otestovali různé výsledky a ověřili scénáře s úspěšným i neúspěšným výsledkem.
Srovnání manuálních a automatizovaných testovacích případů
Umělá inteligence (AI) je dnes součástí většiny testovacích procesů. Podle zprávy PractiTest „2026 State of Testing Report“ využívá 76,8 % testovacích odborníků AI v oblasti zajištění kvality, přičemž nejčastějšími oblastmi použití jsou tvorba testovacích případů (69,6 %) a údržba skriptů (59,6 %). Tato změna je nejvíce patrná u automatizovaných testovacích případů, proto stojí za to vědět, v čem se liší od manuálních.
| Parametr | Ruční testovací případy | Automatizované testovací případy |
|---|---|---|
| Provedení | Provádí lidský tester, který postupuje podle sady zdokumentovaných kroků | Prováděno softwarovými nástroji, skripty nebo agenty umělé inteligence |
| Rychlost | Je to pomalé a časově náročné, protože lidé musí ručně zadávat data a ověřovat výsledky | Dokáže provádět stovky testovacích případů současně |
| Opakovatelnost | Náchylné k lidským chybám a nejednotnému výkladu jednotlivých kroků | Při řádné údržbě testovacích skriptů je zajištěna vysoká opakovatelnost a konzistence |
| Integrace CI/CD | Obtížná integrace do rychle se měnících dodávkových procesů kvůli lidským úzkým místům | Integruje se přímo do CI/CD pipeline, aby bylo možné spouštět testy při každém sestavení |
| Údržba | Vyžaduje ruční aktualizaci dokumentů při každé změně požadavků | Vyžaduje technickou údržbu za účelem aktualizace skriptů v případě změn uživatelského rozhraní nebo logiky |
| Ideální pro | Průzkumné testy | Opakované a regresní testy |
Proč jsou dobře napsané testovací případy důležité
Odhalíte regrese ještě předtím, než uživatelé nahlásí chyby. Každá změna kódu s sebou nese riziko, že naruší něco, co již funguje. Dobře napsaný testovací případ se stává stálým kontrolním bodem, který se spouští po každém nasazení. Když vývojář po roce přepracuje váš přihlašovací kód a omylem naruší správu relací, právě tento testovací případ na to upozorní ve stagingovém prostředí.
Udělejte z „prošel/neprošel“ fakt, ne názor. Nejasné očekávané výsledky, jako je „systém reaguje odpovídajícím způsobem“, nutí každého testera interpretovat, co „odpovídajícím způsobem“ znamená. Dva testeři spustí stejný testovací případ, jeden ho označí jako úspěšný, druhý nahlásí chybu, a tým pak místo ladění softwaru řeší neshodu mezi nimi. Pokud váš očekávaný výsledek zní „systém zobrazí chybovou zprávu: ‚Neplatné heslo‘ a ponechá uživatele na přihlašovací stránce“, není zde prostor pro interpretaci. Výsledek buď odpovídá, nebo neodpovídá. To je pravidlo dvou osob v praxi: testovací případ je tvůrcem, tester je kontrolorem a oba musí mluvit stejným jazykem.
Proměňte tacitní znalosti v opakovaně využitelné aktivum. Ve většině týmů má zkušený inženýr QA v hlavě neviditelnou mapu všech okrajových případů, všech workaroundů a všech těch „jo, nezapomeň zkontrolovat i X“. Když tato osoba odejde na dovolenou nebo změní tým, mapa odejde s ní. Zdokumentované testovací případy s explicitními předpoklady a mezními hodnotami tyto znalosti strukturálně uchovávají. Nový tester, který se připojí k týmu, si může hned první den vzít TC_LOGIN_005 a otestovat postup „zablokování účtu po pěti pokusech“, aniž by se kohokoli ptal, jaká je prahová hodnota nebo jak se resetuje časovač.
Chyby izolujete na konkrétní kroky, nikoli na obecné oblasti. Pokud testovací případ sdružuje „přejít na stránku, zadat přihlašovací údaje a kliknout na Odeslat“ do jediného kroku a test selže, víte pouze to, že „něco v procesu přihlášení nefungovalo“. “ Pokud je každá akce samostatným krokem s vlastním očekávaným výsledkem, selhání se přiřadí ke kroku 4: „Klikněte na ‚Odeslat odkaz pro resetování‘ → očekávaná zpráva o úspěchu, ale objevila se chyba 500.“ Tato přesnost výrazně zkracuje čas potřebný na odladění, protože vývojář přesně ví, která interakce chybu vyvolala, a ne jen v jaké funkční oblasti má hledat.
Uvidíte, co je pokryto a co je slepá skvrna. Bez strukturovaných testovacích případů je pokrytí testů pouhým odhadem. S nimi můžete každý případ přiřadit k příslušnému požadavku a okamžitě odhalit mezery. Pokud má vaše funkce pro resetování hesla šest scénářů (úspěšný reset, vypršený odkaz, opakovaně použitý odkaz, neregistrovaná e-mailová adresa, neplatný formát, více požadavků) a vy máte testovací případy pouze pro tři z nich, je tato mezera viditelná a kvantifikovatelná. Právě díky této viditelnosti se testování mění z „otestovali jsme to“ na „toto přesně jsme otestovali, toto jsme neotestovali a toto je riziko, které přijímáme“.
Složky dobrého testovacího případu
Užitečný testovací případ neobsahuje pouze popis toho, co se má testovat. Zachycuje kontext, kroky provedení a očekávané chování systému, aby mohl jiný tester, vývojář nebo produktový manažer test zopakovat a ověřit výsledek.
Součásti testovacího případu jsou:
- Jedinečný identifikátor
- Účel nebo popis
- Předpoklady
- Kroky provedení
- Očekávané výsledky
- Skutečné výsledky pro srovnání
V případě příkladu funkce přihlášení na webové stránce, který jsme uvedli výše, by váš testovací případ měl obsahovat:
ID testovacího případu: Každý testovací případ potřebuje jedinečný identifikátor. Při testování určité funkce týmy QA často vytvářejí více testovacích případů, které ověřují podobné podmínky. ID testovacího případu pomáhá je snadno sledovat, organizovat a odkazovat na ně během ladění nebo při vypracovávání zpráv.
Příklad: TC_LOGIN_001
Popis: Vysvětluje, jakou funkčnost testovací případ ověřuje. Obsahuje krátké shrnutí, aby každý, kdo si testovací případ přečte, okamžitě pochopil jeho účel.
Příklad: Ověřte, zda se registrovaný uživatel může úspěšně přihlásit do aplikace pomocí platných přihlašovacích údajů.
Předpoklady: Předpoklady popisují stav systému, který je nutný před spuštěním testovacího případu. Bez nich by testeři mohli spustit stejný test za různých podmínek a získat nekonzistentní výsledky.
Příklady:
- Uživatelský účet musí v systému již existovat
- Uživatelský účet musí být aktivní a nesmí být zablokován
- Přihlašovací stránka by měla být přístupná
Kroky: Jedná se o akce, které uživatel nebo tester provádí za účelem provedení testovacího případu. Každý krok by měl být jasný a logicky navazující, aby test mohl reprodukovat kdokoli z týmu.
- Uživatel přejde na přihlašovací stránku
- Uživatel zadá registrovanou e-mailovou adresu
- Uživatel zadá správné heslo
- Uživatel klikne na tlačítko Přihlásit se
Očekávané výsledky: Definují, co by měl systém udělat, pokud funkce pracuje správně.
- Jsou-li přihlašovací údaje platné, systém uživatele ověří.
- Uživatel je přesměrován na hlavní panel
- Uživatelská relace byla úspěšně vytvořena
Pokud jsou přihlašovací údaje neplatné, měl by systém zobrazit příslušnou chybovou zprávu.
Skutečné výsledky: Tyto výsledky zachycují pozorování testera po spuštění testovacího případu. Pokud se pozorované chování liší od očekávaného výsledku, je problém zaznamenán jako chyba.
Příklad pozorování:
- Zadali jste platné přihlašovací údaje, ale zobrazila se chybová zpráva „Neplatné heslo“
Nyní pojďme vaše dovednosti v psaní testovacích případů využít v praxi.
Věděli jste, že... Pouze 2,1 % týmů popisuje své postupy testování umělé inteligence jako optimalizované, zatímco více než 85 % se stále nachází v počáteční fázi nebo ve fázi experimentování. Nejčastějším využitím je generování testovacích případů (69,6 %), nikoli strategická činnost, jako je identifikace rizik (19,9 %).
Jak psát testovací případy (postup krok za krokem)
Psaní testovacího případu zahrnuje sedm kroků: analýza požadavku, sepsání scénářů, naplánování struktury, sepsání kroků s očekávanými výsledky, doplnění kontextu, nechat si jej zkontrolovat, následně provést a zaznamenat.
Krok 1: Analyzujte požadavky
Než začnete psát testovací případ, ujasněte si, co má daná funkce dělat. V této fázi si prostudujte dostupné dokumenty – PRD (dokumenty s požadavky na produkt), uživatelské příběhy, specifikace funkcí a návrhové dokumenty – a identifikujte všechny funkce, které je třeba ověřit.
Příklad: Vytváříte funkci, která uživatelům umožňuje resetovat heslo prostřednictvím e-mailu. Chcete-li k tomu vytvořit testovací případ, musíte pochopit:
- Jaký problém tato funkce řeší, tj. může uživatel znovu získat přístup ke svému účtu, pokud zapomene heslo?
- Jaké akce může uživatel provést, tj. požádat o odkaz pro resetování, obdržet jej e-mailem a nastavit nové heslo?
- Co by se mělo stát po provedení těchto akcí, tj. odešle systém odkaz pro resetování a umožní uživateli úspěšně změnit heslo?
- Existují nějaká omezení, tj. vyprší platnost odkazu po určité době nebo se stane neplatným po jednom použití?
- Existují nějaká ověření nebo pravidla, tj. musí nové heslo splňovat konkrétní požadavky na formát nebo délku?
- Je některá funkce nejasná nebo nedefinovaná? Pokud ano, vyjasněte si to s příslušným zainteresovaným subjektem
Tato jasnost vám poskytne základ pro vymezení jednoho jasného cíle pro váš testovací případ.
Cíl: Ověřit, zda si registrovaný uživatel může úspěšně resetovat heslo prostřednictvím e-mailu.
Krok 2: Identifikujte různé testovací scénáře
Dále si sepište seznam testovacích scénářů, které potřebujete ověřit. Testovací scénář je obecná situace, která se obvykle rozvětvuje do několika testovacích případů pokrývajících různé vstupy a výstupy.
Pro funkci obnovení hesla by vaše scénáře mohly vypadat například takto:
- Úspěšné resetování: Ověřte, zda si registrovaný uživatel může vyžádat odkaz pro resetování a nastavit nové heslo
- Neregistrovaný e-mail: Otestujte, co se stane, když je odeslán e-mail, který v systému neexistuje.
- Neplatný odkaz: Ověřte, zda systém zablokuje přístup, když je po uplynutí platnosti kliknuto na odkaz pro obnovení.
- Opakovaně použitý odkaz: Otestujte, zda již použitý odkaz pro resetování nelze použít znovu
- Neplatné nové heslo: Ověřte, zda jsou hesla, která nesplňují požadavky na formát, odmítnuta
- Více žádostí o reset: Otestujte, který odkaz zůstane platný, když uživatel zadá několik žádostí za sebou
Každý zde uvedený scénář se promítne do jednoho nebo více testovacích případů pokrývajících konkrétní vstupy a podmínky. Rozčlenění funkce tímto způsobem zajistí, že budete mít testovací pokrytí jak očekávaného chování, tak i hraničních případů, s nimiž se skuteční uživatelé nevyhnutelně setkají.
Přečtěte si více: Jak vytvořit a zavést kontrolní seznam pro zajištění kvality
Krok 3: Naplánujte test a stanovte strukturu testovacích případů
Pro opakované regresní testování potřebujete strukturu, která vám umožní konzistentně dokumentovat testovací případy a jejich výsledky. Dobře definovaná šablona testovacího případu zajišťuje tuto konzistenci a umožňuje opakované použití, aniž byste museli pokaždé začínat od nuly.
Naplánujte si provedení testů tím, že si ujasníte tyto prvky:
Kdo bude test provádět?
Jakou roli nebo kvalifikaci musí mít osoba provádějící tento test? V závislosti na složitosti testu a míře nutného lidského zásahu přiřaďte role:
- Tester QA: Funkční a regresní testy, jako je ověřování postupů přihlášení, validace formulářů nebo procesů dokončení nákupu
- Bezpečnostní tým: Testy zaměřené na zranitelnosti v oblasti autentizace, řízení přístupu nebo úniku dat
- Vývojář: Jednotkové testy pro jednotlivé funkce, jako je hashování hesel nebo generování tokenů
Jak bude test proveden?
- Na jakých zařízeních a operačních systémech bude test probíhat?
- Jaké nástroje nebo testovací frameworky budou použity?
- Bude test proveden ručně nebo prostřednictvím agenta s umělou inteligencí?
- Jak budou výsledky zaznamenány – v nástroji pro správu testů, v tabulce nebo v systému pro sledování chyb?
Jaké jsou předpoklady?
Uveďte všechny podmínky, které musí být splněny před krokem 1, a zajistěte, aby každou z nich mohl tester ověřit:
Příklad:
- Uživatelský účet s e-mailovou adresou „test@example.com“ existuje
- Uživatel je odhlášen ze systému
- E-mailová služba je aktivní a schopná doručovat zprávy
- Testovací prostředí je přístupné a v provozu
Jaká testovací data budou použita?
Definujte přesné vstupní hodnoty potřebné ke spuštění testu – platná data, neplatná data a hraniční hodnoty.
Příklad:
- Platné: registrovaná e-mailová adresa „test@example.com“, heslo splňující požadavky na formát
- Neplatné: neregistrovaná e-mailová adresa, heslo nedosahuje minimálního počtu znaků
- Hraniční případ: heslo přesně na minimálním a maximálním počtu znaků
Krok 4: Napište testovací kroky a očekávané výsledky
Rozčleňte proces provádění na jednotlivé kroky. Používejte jednotnou terminologii a zajistěte, aby každý krok obsahoval pouze jednu akci. Při definování kroků také uveďte očekávaný výsledek a kritéria pro úspěch či neúspěch.
V návaznosti na náš postup pro resetování hesla by testovací kroky vypadaly následovně:
| Kroky | Očekávaný výsledek |
| Přejděte na přihlašovací stránku | Přihlašovací stránka se načte s klikatelným odkazem „Zapomněli jste heslo?“ |
| Klikněte na „Zapomněli jste heslo?“ | Uživatel je přesměrován na stránku žádosti o resetování hesla |
| Zadejte e-mailovou adresu do pole E-mail | E-mail je přijat bez chyby ověření |
| Klikněte na „Odeslat odkaz pro resetování“ | Zobrazí se hlášení o úspěšném odeslání: „Odkaz na resetování byl odeslán na adresu test@example.com“ |
| Otevřete odkaz pro obnovení z e-mailu | Uživatel je přesměrován na stránku pro vytvoření nového hesla |
| Zadejte platné nové heslo | Pole pro heslo přijímá zadání bez chyby |
| Klikněte na „Obnovit heslo“ | Zobrazí se zpráva o úspěšném provedení a uživatel bude přesměrován na přihlašovací stránku |
Nyní definujte kroky a očekávané výsledky pro alternativní scénáře (o nichž jsme hovořili dříve). Uveďte, co se stane, když uživatel zadá neplatnou e-mailovou adresu nebo pokud heslo nesplňuje předem stanovená kritéria.
Bonus: Zde se dozvíte, jak můžete pomocí umělé inteligence automatizovat dokumentaci všech svých testovacích případů.
Krok 5: Přiložte relevantní přílohy
Přiložte relevantní dokumenty nebo přílohy, které testerům pomohou provést testovací případ v plném kontextu a bez nejasností. Může se jednat například o:
- Označené snímky obrazovky uživatelského rozhraní v klíčových krocích
- Nahrávky obrazovky, které ukazují, jak provést test v různých scénářích a jaké výsledky lze očekávat
- Systémové protokoly nebo konfigurační soubory pomáhají diagnostikovat problémy na straně backendu v případě selhání testu
- Dokumentace požadavků, která přiřazuje testovací případ k uživatelskému příběhu nebo akceptačním kritériím, která ověřuje
- Soubory s testovacími daty obsahující platné i neplatné vstupy nebo generovaná data, jako jsou čísla kreditních karet, náhodné adresy či přihlašovací údaje uživatelů
- Vytvořte dokumentaci, která bude obsahovat informace o konkrétní verzi softwaru, požadovaném hardwaru, operačním systému a případných nezbytných bezpečnostních oprávněních
- Pro testování API použijte specifikace OpenAPI nebo dokumentaci koncových bodů, která podrobně popisuje metody požadavků, parametry a očekávané stavové kódy.
Krok 6: Nechte si testovací případ zkontrolovat
Před spuštěním testovacího případu jej sdílejte s kolegou nebo vedoucím týmu QA. Během revize zkontrolujte, zda:
- Testovací případ je komplexní a pokrývá všechny možné scénáře odvozené z požadavků.
- Kroky jsou jasné a postupně znázorňují skutečný průběh provádění
- Každý očekávaný výsledek popisuje pozorovatelný výstup (zprávu, přesměrování, stavový kód), nikoli vlastnost typu „funguje správně“.
- Testovací data a předpoklady jsou úplné a přesné
- Veškeré předpoklady učiněné během psaní jsou výslovně zdokumentovány
Krok 7: Spusťte testy a zaznamenejte výsledky
Proveďte test a zaznamenejte skutečný výsledek vedle každého očekávaného výsledku. V každém kroku označte test jako úspěšný nebo neúspěšný. U každého neúspěšného kroku okamžitě nahlaste chybu a propojte ji s testovacím případem. Pokud navíc dojde k neočekávanému chování, které nelze jednoznačně označit jako úspěšné či neúspěšné, poznamenejte si to do pole pro komentáře k dalšímu posouzení.
Přečtěte si více: Jak využít umělou inteligenci pro zajištění kvality
Příklady psaní testovacích případů
Tyto tři příklady ukazují, jak se stejná struktura testovacího případu přizpůsobuje různým typům testování softwaru. Každý z nich využívá komponenty a formát kroků popsané dříve v této příručce, ale složitost, testovací data a režimy selhání se liší v závislosti na tom, co ověřujete.
Příklad 1: Proces platby v e-shopu (uživatelské rozhraní, vícestupňový pracovní postup)
Tým QA u jednoho online prodejce testuje proces placení před svátečními slevami. Tento proces zahrnuje několik stránek: košík → doprava → platba → potvrzení. Zvláštní výzvou je zde závislost na stavu: každý krok závisí na správném dokončení předchozího kroku a testovací data (obsah košíku, doručovací adresa, způsob platby) musí být zachována ve všech krocích.
Tester: Rahul D.
Datum zkoušky: 09.03.2026
ID testovacího případu: TC_CHECKOUT_003
Popis: Ověřte, zda přihlášený uživatel může dokončit nákup s použitím uložené kreditní karty a standardní dopravy.
Předpoklady:
- Uživatelský účet existuje a obsahuje alespoň jednu uloženou kreditní kartu a jednu uloženou dodací adresu
- Alespoň jeden kus je skladem a byl přidán do košíku
- Testovací prostředí běží na prohlížeči Chrome 128 v systému macOS
| Krok | Očekávaný výsledek | Skutečný výsledek | Splněno/Nesplněno |
| Přejděte na stránku košíku | Košík zobrazuje správnou položku, množství a mezisoučet | Jak se dalo očekávat | Složit zkoušku |
| Klikněte na „Přejít k pokladně“ | Na stránce s objednávkou se při načtení předvolí uložená adresa | Jak se dalo očekávat | Složit zkoušku |
| Vyberte možnost „Standardní doprava“ a klikněte na Pokračovat | Na stránce platby se načte celková částka objednávky včetně nákladů na dopravu | Jak se dalo očekávat | Složit zkoušku |
| Potvrďte uloženou kreditní kartu a klikněte na „Objednat“ | Zobrazí se stránka s potvrzením objednávky s číslem objednávky, přehledem položek a předpokládaným datem doručení | Stránka platby se znovu načítá s chybou: „Nelze zpracovat platbu“ | Selhání |
Shrnutí výsledků: Proces dokončení objednávky správně zpracovává přechod z košíku k doručení, ale zpracování platby selhává u uložených kreditních karet. Zaznamenaná chyba: vyhledávání tokenizované karty vyprší, pokud platební brána odpoví později než za 3 sekundy.
Příklad 2: Koncový bod REST API (bez uživatelského rozhraní, ověření vstupů a výstupů)
Backendový inženýr testuje koncový bod API „Vytvořit uživatele“ ještě předtím, než jej začne využívat frontendový tým. Neexistuje žádné rozhraní, ve kterém by bylo možné klikat: testovací případ přímo ověřuje obsah požadavků, kódy odpovědí a trvalost dat. Klíčovou výzvou je testování smlouvy mezi systémy, nikoli uživatelského zážitku.
Testerka: Sarah S.
Datum zkoušky: 09. 05. 2026
ID testovacího případu: TC_API_USER_001
Popis: Ověřte, zda požadavek POST na adresu /api/v1/users vytvoří nového uživatele a vrátí správnou odpověď.
Předpoklady:
- Testovací prostředí API je spuštěno a přístupné
- Byl vygenerován a je platný autentizační token s oprávněními správce
- V databázi neexistuje žádný uživatel s e-mailovou adresou „newuser@testdomain.com“
| Krok | Očekávaný výsledek | Skutečný výsledek | Splněno/Nesplněno |
| Odešlete požadavek POST na /api/v1/users s platným datovým obsahem: { "name": "Test User", "email": "newuser@testdomain. com", "role": "viewer" } | Odpověď vrací kód 201 Created s tělem v formátu JSON obsahujícím ID uživatele, jméno, e-mail a roli | 201 vráceno se správným tělem | Složit zkoušku |
| Odešlete znovu stejný požadavek POST s identickou e-mailovou adresou | Odpověď vrací kód 409 Konflikt se zprávou: „Uživatel s touto e-mailovou adresou již existuje“ | Vráceno 200 OK; byl vytvořen duplicitní uživatel | Selhání |
| Odeslat POST s chybějícím polem „email“ | Odpověď vrací chybu 400 Bad Request s chybou validace: „E-mail je povinný“ | 400 vráceno podle očekávání | Složit zkoušku |
| Proveďte dotaz GET /api/v1/users/{id} s použitím ID z kroku 1 | Odpověď vrací stav 200 OK a údaje o uživateli se shodují s původním datovým obsahem | Jak se dalo očekávat | Složit zkoušku |
Shrnutí výsledků: Endpoint správně vytváří uživatele a ověřuje povinná pole, ale nedokáže zajistit jedinečnost e-mailových adres na úrovni databáze. Duplicitní záznamy byly vytvořeny bez chyby. Chyba zaznamenána se závažností: Vysoká.
Příklad 3: Řízení přístupu na základě rolí (bezpečnost, hranice oprávnění)
Bezpečnostní tým před auditem shody testuje, zda aplikace správně omezuje akce na základě uživatelských rolí. Klíčovou výzvou je, že netestujete, zda funkce funguje, ale zda je její použití správně odepřeno. Očekávaným výsledkem u většiny kroků je blokování, nikoli úspěch.
Tester: Marcus L.
Datum zkoušky: 09. 08. 2026
ID testovacího případu: TC_RBAC_002
Popis: Ověřte, zda uživatel s rolí „Viewer“ nemůže vytvářet, upravovat ani mazat projekty.
Předpoklady:
- Existují dva účty: jeden s rolí „Admin“ a jeden s rolí „Viewer“
- V pracovním prostoru existuje alespoň jeden projekt, který vytvořil správce.
- Prohlížeč je přihlášen ve Firefoxu 130, Windows 11
| Krok | Očekávaný výsledek | Skutečný výsledek | Úspěšný/Neúspěšný |
| Přejděte na stránku Projekty | Prohlížeč zobrazuje seznam projektů v režimu jen pro čtení; tlačítko „Vytvořit projekt“ je buď skryté, nebo deaktivované | Tlačítko je viditelné, ale je šedé | Složit zkoušku |
| Zkuste kliknout na „Vytvořit projekt“ | Systém brání provedení akce; formulář pro nový projekt se nenačte | Formulář nebyl načten; v popisku se zobrazuje „Nemáte oprávnění“ | Složit zkoušku |
| Otevřete existující projekt a zkuste upravit název | Pole „Název“ nelze upravit, nebo systém blokuje uložení | Pole „Název“ bylo editovatelné; změny byly úspěšně uloženy | Selhání |
| Zkuste projekt smazat pomocí nabídky se třemi tečkami | Možnost smazání je skrytá nebo je akce zablokována kvůli chybě oprávnění | Možnost „Odstranit“ není v nabídce viditelná | Složit zkoušku |
Shrnutí výsledků: Oprávnění k vytváření a mazání jsou u uživatelů s rolí „Viewer“ správně omezena, ale oprávnění k úpravám nejsou vynucena na úrovni polí. Uživatel s rolí „Viewer“ může měnit názvy projektů, přestože má přístup pouze pro čtení. Chyba zaznamenána se závažností: Kritická (brání dodržení předpisů).
Jaké nástroje jsou nejvhodnější pro správu testovacích případů?
Testovací případy lze spravovat v specializovaném nástroji pro zajištění kvality (TestRail, Zephyr), v obecném nástroji pro projektové řízení (ClickUp, Jira) nebo v tabulkovém procesoru; správná volba závisí na tom, zda potřebujete integrované provádění testů, nebo pouze jejich sledování.
ClickUp
ClickUp for Software Teams je platforma pro řízení projektů, kde jsou testovací případy uloženy jako úkoly společně se sprinty, chybami a žádostmi o začlenění, ke kterým se vztahují. Nejedná se o specializovaný nástroj pro správu testů, ale díky flexibilní struktuře úkolů umožňuje týmům vytvářet pracovní postupy pro testovací případy pomocí vlastních stavů, polí a typů úkolů, aniž by potřebovaly samostatný nástroj.
Klíčové funkce ClickUp
- Flexibilní hierarchie pro organizaci testovacích případů v rámci prostorů, složek a seznamů s vlastními poli pro typ testu, prioritu a prostředí
- Více než 15 zobrazení v ClickUp (tabule, seznam, tabulka) pro sledování provádění testů podle stavu, přidělené osoby nebo sprintu
- Dokumenty pro uchovávání PRD, testovacích plánů a průvodců nastavením prostředí vedle testovacích případů, na které se vztahují
- Integrovaný chat pro komunikaci mezi vývojáři a pracovníky QA bez nutnosti přepínat na Slack nebo e-mail
- Souhrny úkolů založené na umělé inteligenci prostřednictvím ClickUp Brain pro rychlý přehled o kontextu během sprintových revizí
Omezení ClickUp
- Žádný nativní engine pro provádění testů
- Zprávy specifické pro testování (pokrytí podle požadavků, úspěšnost v jednotlivých cyklech) vyžadují přizpůsobené řídicí panely, nikoli standardní reporty pro zajištění kvality.
Ceny služby ClickUp
Hodnocení a recenze ClickUp
- G2: 4,6/5 (více než 14 100 recenzí)
- Capterra: 4,6/5 (více než 4 600 recenzí)
Co říkají skuteční uživatelé o ClickUp?
Toto říká jeden z recenzentů na G2:
Na ClickUp se mi nejvíc líbí, že vše sjednocuje na jednom místě. Úkoly, časové osy, poznámky i aktualizace jsou soustředěny v jednom systému, což omezuje přecházení mezi různými nástroji. Oceňuji také flexibilitu. Můžeme si přizpůsobit stavy, pole a zobrazení tak, aby odpovídaly tomu, jak náš tým skutečně pracuje. Díky tomu je snazší udržet pořádek a máme jasný přehled o tom, kdo za co odpovídá a v jaké fázi se projekty právě nacházejí.
Na ClickUp se mi nejvíc líbí, že vše sjednocuje na jednom místě. Úkoly, časové osy, poznámky i aktualizace jsou soustředěny v jednom systému, což omezuje přecházení mezi různými nástroji. Oceňuji také flexibilitu. Můžeme si přizpůsobit stavy, pole a zobrazení tak, aby odpovídaly tomu, jak náš tým skutečně pracuje. Díky tomu je snazší udržet pořádek a máme jasný přehled o tom, kdo za co odpovídá a v jaké fázi se projekty v daném okamžiku nacházejí.
Ideální pro: Vedoucího QA, který chce, aby se neúspěšný test jedním kliknutím proměnil v ticket s chybou pro vývojáře, přičemž PR, testovací kroky i sprint jsou viditelné v rámci jednoho úkolu.
Tuto část přeskočte, pokud: Váš testovací cyklus je z větší části automatizovaný. Pokud se 80 % vaší testovací sady spouští z CI pipeline, potřebujete nástroj, který automaticky načítá výsledky provedení, nikoli takový, u kterého stav aktualizuje člověk.
TestRail
TestRail je specializovaná platforma pro správu testů vytvořená pro týmy QA, které potřebují strukturovanou kontrolu nad celým procesem testování. Zajišťuje kompletní cyklus tvorby, spouštění a vyhodnocování testovacích případů, přičemž výsledky jsou přiváděny prostřednictvím integrace s DevOps a CI/CD.
Klíčové funkce TestRailu
- Centralizovaná správa testovacích případů a testovacích sad s možností opakovaného použití testovacích případů napříč projekty
- Testovací plány a milníky pro organizaci a plánování testovacích běhů v rámci sprintů a verzí
- Podrobné reporty s analýzou pokrytí, sledováním pokroku a historií provedení
- Integrace s Jira, GitHub, Jenkins, Azure DevOps a více než 20 dalšími nástroji DevOps
- REST API pro automatizaci úkolů a synchronizaci testovacích dat s externími systémy
Omezení TestRailu
- Chybí nativní funkce pro správu požadavků nebo sledování problémů – týmy se musí spoléhat na externí nástroje, jako je Jira, což může narušit sledovatelnost.
- S rostoucím počtem testovacích repozitářů, které se počítá na tisíce, se orientace ve struktuře složek stává obtížnou.
Ceny TestRailu
- Professional: 39 $ za licenci a měsíc
- Enterprise: 78 $/uživatel/měsíc
Hodnocení a recenze TestRailu
- G2: 4,4/5 (více než 600 recenzí)
- Capterra: 4,3/5 (více než 160 recenzí)
Co říkají skuteční uživatelé o TestRailu?
Toto říká jeden z recenzentů na G2:
Na TestRailu si nejvíce cením toho, že našemu týmu QA poskytuje bezpečné a přehledné prostředí pro správu testovacích plánů, testovacích případů a testovacích běhů. Oceňuji, jak snadné je strukturovat a implementovat testovací sady a také znovu využívat dříve vytvořené testovací případy. Díky integraci s Jirou a nástroji CI/CD je náš pracovní postup soudržnější a snáze sledovatelný. Možnost sledovat průběh testování a pokrytí v reálném čase je neuvěřitelně užitečná pro plánování sprintů a vykazování. V mé každodenní práci jako inženýrky QA mi používání TestRailu také ušetřilo značné množství času.
Na TestRailu si nejvíce cením toho, že našemu týmu QA poskytuje bezpečné a přehledné prostředí pro správu testovacích plánů, testovacích případů a testovacích běhů. Oceňuji, jak snadné je strukturovat a implementovat testovací sady a také znovu používat dříve vytvořené testovací případy. Díky integraci s Jira a nástroji CI/CD je náš pracovní postup soudržnější a snáze sledovatelný. Možnost sledovat průběh testování a pokrytí v reálném čase je nesmírně užitečná pro plánování sprintů a vykazování. V mé každodenní práci jako inženýrky QA mi používání TestRailu také ušetřilo značné množství času.
Nejvhodnější pro: Tým QA o pěti nebo více členech, který provádí formální testovací cykly pro každou verzi, kde manažer potřebuje zjistit, „jaké procento verze 2.0 bylo otestováno a úspěšně absolvovalo testy“, a to přímo z dashboardu, nikoli z tabulky.
Tuto část přeskočte, pokud: Vaše sada obsahuje méně než několik set testovacích případů nebo pokud vaši testeři zároveň pracují jako vývojáři. V takovém měřítku vám náklady na jedno pracovní místo a samostatné přihlášení přinesou pouze reporty, které stejně nebudete číst.
Zephyr
Zephyr je plugin společnosti SmartBear pro správu testů v Jira, který umožňuje pracovat s testovacími případy přímo z rozhraní Jira. Podporuje jak manuální, tak automatizované testování a nabízí výkonné funkce pro vytváření reportů a sledovatelnost, určené pro agilní i podnikové týmy.
Klíčové funkce Zephyru
- Nativní integrace s Jira – vytvářejte, propojujte a provádějte testovací případy přímo z úkolů v Jira
- Hierarchické knihovny testů napříč projekty pro opakované použití a organizaci testovacích případů ve velkém měřítku
- Více než 70 předdefinovaných reportů pokrývajících pokrytí testů, průběh provádění a sledování chyb
- Podpora BDD se syntaxí Gherkin pro pracovní postupy vývoje řízeného chováním
- Integrace CI/CD s Jenkinsem, GitHubem, GitLabem, Bitbucketem a Bamboo
Omezení nástroje Zephyr
- Licence se uděluje na každého uživatele Jira, nikoli na každého testera
- Orientace ve velkých repozitářích testů (tisíce případů) může být složitější než v samostatných nástrojích, jako je TestRail
- Podpora je poskytována prostřednictvím Atlassian Marketplace, což představuje další úroveň pro týmy zvyklé na přímou podporu od dodavatele
Ceny produktu Zephyr
- Essential: od 5,99 $ za uživatele a měsíc (11–50 uživatelů)
- Standard: od 6,81 $ za uživatele a měsíc (11–50 uživatelů)
- Pokročilá úroveň: od 8,73 $ za uživatele a měsíc (11–50 uživatelů)
Hodnocení a recenze Zephyr
- G2: 4,1/5 (více než 80 recenzí)
- Capterra: Nedostatek recenzí
Co říkají skuteční uživatelé o Zephyru?
Toto říká jeden z recenzentů na G2:
Toto je nejlepší nástroj pro import testovacích případů přímo z tabulky Excel. Díky tomuto nástroji je práce testerů méně náročná než při importu testovacích případů do Jiry. Další skvělou funkcí tohoto nástroje je možnost označit testovací případy jako úspěšné nebo neúspěšné a přidávat přílohy.
Toto je nejlepší nástroj pro import testovacích případů přímo z tabulky Excel. Díky tomuto nástroji je práce testerů méně náročná než při importu testovacích případů do Jiry. Mezi nejlepší funkce tohoto nástroje patří také možnost označit testovací případy jako úspěšné nebo neúspěšné a přidávat přílohy.
Vhodné zejména pro: Týmy v regulovaných odvětvích nebo podléhající častým auditům (fintech, zdravotnictví), které potřebují, aby každý test byl přiřazen k požadavku v Jira a každá chyba byla propojena s testem, který ji odhalil – a to vše v rámci jedné instance Atlassian.
Přeskočte to, pokud: Vaše instance Jira je velká a váš tým QA je malý. Jira s 200 uživatelskými místy a 10 testery znamená platit za 190 licencí Zephyr, které nikdo nepoužívá; samostatný nástroj s cenou za každého testera vyjde levněji.
Jira
Jira je platforma společnosti Atlassian pro řízení projektů a sledování úkolů, kterou široce využívají technické a QA týmy k řízení sprintů, chyb a vývojových pracovních postupů. Ačkoli se nejedná o specializovaný nástroj pro správu testů, mnoho týmů ji používá společně s řešeními jako Zephyr Scale nebo Xray, aby mohli spravovat testovací případy v rámci svého stávajícího nastavení Jira.
Klíčové funkce Jira
- Scrumové a Kanbanové tabule pro správu sprintů, backlogů a agilních testovacích workflow
- Přizpůsobitelné pracovní postupy, typy problémů a pole, které odpovídají způsobu, jakým váš tým sleduje práci
- Pokročilé plánovací mapy pro plánování napříč týmy a sledování závislostí (Premium)
- Více než 1 000 integrací s platformami, včetně GitHub, Confluence, Slack a nástrojů CI/CD
- Pravidla automatizace pro spouštění akcí napříč projekty na základě aktualizací problémů nebo změn stavu
Omezení Jira
- Správa testovacích případů vyžaduje plugin z Marketplace (Zephyr Scale, Xray), za který se kromě předplatného Jira platí ještě samostatný poplatek za každého uživatele.
- Pro uživatele bez technického zázemí je učení náročnější a náklady na zaškolení se u větších týmů mohou výrazně navýšit
Ceny Jira
- Zdarma
- Standard: 7,91 $/uživatel/měsíc
- Premium: 14,54 $/uživatel/měsíc
- Enterprise: Ceny na míru
Hodnocení a recenze Jira
- G2: 4,3/5 (více než 7 900 recenzí)
- Capterra: 4,4/5 (více než 15 400 recenzí)
Co říkají skuteční uživatelé o Jira?
Toto říká jeden z recenzentů na G2:
Jira je jedním z mých oblíbených digitálních programů pro sledování a vizualizaci výkonu všech mých pracovních projektů ve spolupráci se všemi členy mého pracovního týmu, protože nabízí nejlepší virtuální výkonnostní možnosti ve své třídě, což mi usnadňuje dosahování všech mých profesních cílů.
Jira je jedním z mých oblíbených digitálních programů pro sledování a vizualizaci výkonu všech mých pracovních projektů ve spolupráci se všemi členy mého pracovního týmu, protože nabízí nejlepší virtuální výkonnostní funkce ve své třídě, což mi usnadňuje dosahování všech mých profesních cílů.
Vhodné pro: Technické týmy, které zvažují, zda vůbec potřebují specializovanou správu testů. Provedení několika testovacích cyklů nejprve pomocí vlastních typů úkolů v Jira ukáže, zda objem testů ospravedlňuje použití pluginu.
Přeskočte tuto část, pokud: Již víte, že potřebujete správu testů. Přechodem přímo na plugin nebo samostatný nástroj se vyhnete migraci, až se vlastní typy problémů přestanou dát škálovat.
Časté chyby, kterým je třeba se při vytváření testovacích případů vyvarovat
Vyhněte se těmto chybám při psaní testovacích případů, které mohou snížit jejich celkovou účinnost.
| Chyba | Co dělat místo toho |
|---|---|
| Příliš pozdní psaní testovacích případů | Zapojte testery do fází sběru požadavků a návrhu, abyste identifikovali potenciální problémy ještě před zahájením programování |
| Neaktualizujte testovací případy | Aktualizujte testovací případ, jakmile dojde k nové aktualizaci dané funkce, ke změně funkčnosti nebo ke změně uživatelského rozhraní. |
| Žádné postpodmínky | Uveďte, jak by měl systém vypadat po dokončení testu (uživatel byl odstraněn, košík vyprázdněn, relace ukončena), aby následující případ začínal z čistého stavu |
| Pouze data z optimálního scénáře | Každé vstupní pole vyžaduje alespoň jednu hodnotu, kterou by systém měl odmítnout. Zaznamenejte, jak se datový soubor generuje nebo načítá |
| Neupřednostňování testovacích případů | Každému testovacímu případu přiřaďte prioritu na základě dopadu na podnikání, frekvence použití a rizika selhání. To vám pomůže soustředit úsilí na testování a činit rozumnější rozhodnutí ohledně rozpočtu a testovacích metod. |
Jak zajistit, aby testovací případy zůstaly užitečné i v průběhu času
Testovací sada zůstává důvěryhodná, pokud je každý test nezávislý, zaměřuje se na vstupy, u nichž je nejvyšší pravděpodobnost selhání, a je vyřazen v okamžiku, kdy přestane poskytovat spolehlivý výsledek. Těchto šest postupů odlišuje testovací sady, které odhalují chyby po celá léta, od těch, které jsou po druhém sprintu ignorovány.
Pište nezávislé, atomické testy
Testovací případ by měl nastavit svůj vlastní stav a nikdy by neměl záviset na tom, že byl předtím spuštěn jiný případ. Pokud případ TC_CHECKOUT_003 předpokládá, že případ TC_CHECKOUT_002 zanechal položku v košíku, jedna chyba se rozroste na pět a vy strávíte dopoledne tím, že budete zjišťovat, která chyba byla skutečná. Pokud název testu obsahuje slovo „a“, rozdělte jej na dva případy.
Testujte na hranicích
Chyby se hromadí na okrajích povoleného rozsahu vstupních hodnot, nikoli uprostřed. Pokud pole pro heslo přijímá 8 až 128 znaků, otestujte 7, 8, 128 a 129, ne jen pohodlné 12znakové heslo. Analýza hraničních hodnot je formální technikou v normě pro návrh testů ISO/IEC/IEEE 29119-4 právě z tohoto důvodu: odhaluje chyby typu „off-by-one“, které náhodné vstupy přehlédnou.
Využijte rozdělení na ekvivalenční třídy k omezení nadbytečných případů
Seskupte vstupy, které by systém měl zpracovávat stejně, a poté otestujte jeden reprezentativní příklad z každé skupiny. Každý platný formát e-mailu se v přihlašovacím formuláři chová stejně, takže stačí jeden platný e-mail. Testování adres user@example.com, jane@company.com a bob@domain.org jako tří samostatných případů ztrojnásobí vaši zátěž při údržbě, aniž by se zvýšilo pokrytí.
Oddělte testovací data od testovacích kroků
Pevné zakódování „zadejte test@example.com“ do kroku znamená, že při každé změně testovacího prostředí je nutné tento krok přepisovat. Udržujte kroky obecné („zadejte registrovaný e-mail“) a skutečné hodnoty uchovávejte v poli testovacích dat nebo v souboru. Stejné kroky se pak spustí na testovacím, QA a předprodukčním prostředí bez úprav a nahrazení novým datovým souborem pro negativní test představuje změnu o jediném řádku.
Sledujte nestabilní testy a míru úniku vad
Nestabilní test selhává nepravidelně, aniž by v produktu byla skutečná chyba, a každý takový test vede tým k tomu, aby ignoroval červené výsledky. Sledujte, jak často se u jednotlivých sestavení výsledek daného testu střídá mezi úspěšným a neúspěšným. Pokud test selhává více než několikrát za měsíc, přepište jej nebo odstraňte. Spojte to s mírou úniku chyb (chyb nalezených v produkčním prostředí, které měl testovací případ odhalit), abyste zjistili, kde je pokrytí nedostatečné, a ne jen kde dochází k falešným poplachům.
Automatizujte testy, které provádíte nejčastěji
Regresní, kouřové a vysoce frekventované funkční testy jsou nejvhodnějšími kandidáty pro automatizaci, protože se spouštějí při každé nové verzi a málokdy se mění. Přesuňte je do skriptů ve vašem CI/CD pipeline a v místech, kde se prvky uživatelského rozhraní často mění, používejte nástroje podporované umělou inteligencí s lokátory s funkcí samoopravy. Tím se lidským testerům uvolní ruce pro explorativní práci a typy testování softwaru, které vyžadují úsudek, jako je testování použitelnosti a hledání hraničních případů.
Jak psát a spouštět testovací případy v ClickUp
V sekci „Nástroje“ výše je popsáno, kde ClickUp najde uplatnění. Tato sekce ukazuje konkrétní nastavení, které odpovídá krokům popsaným dříve v tomto průvodci.
Uspořádejte si knihovnu testovacích případů. Vytvořte prostor pro svůj produkt, složku pro každou oblast funkcí (např. ověřování, platby, onboardování) a seznam pro každý testovací cyklus nebo sprint. Každý úkol se stane samostatným testovacím případem. Pomocí vlastních polí v ClickUp zaznamenávejte údaje jako ID testovacího případu, předběžné podmínky, testovací data, úroveň priority a prostředí.
Zadejte testovací kroky přímo do úkolu. V popisu úkolu zdokumentujte postupné kroky provedení a očekávané výsledky. Kontrolní seznamy se osvědčují pro postupné toky, kde tester musí odškrtávat jednotlivé akce, zatímco popis obsahuje kontext, jako jsou předpoklady a testovací data.
Sledujte průběh a výsledky. Vytvářejte vlastní stavy, které odrážejí váš testovací pracovní postup: Nezahájeno → Probíhá → Úspěšné → Neúspěšné → Blokováno. Pokud test selže, převedete jej na úkol s chybou nebo vytvoříte propojený úkol přiřazený vývojáři, včetně priority, závislostí a termínu. Díky integraci s GitHubem a GitLabem můžete tuto chybu přímo propojit s pull requestem, který ji způsobil. Pokud je příčinou chyba v kódu, můžete tento úkol s chybou přiřadit agentu ClickUp Codegen, který si přečte úkol, propojené specifikace a komentáře, napíše opravu a otevře pull request s informacemi o postupu, které se promítnou zpět do úkolu.
Tip pro profesionály: Vedoucí QA mohou získat okamžitý přehled o jakémkoli úkolu tím, že požádají ClickUp Brain o shrnutí otevřených úkolů týkajících se chyb. Tímto způsobem mají k dispozici veškerý kontext potřebný pro revize sprintů, aniž by museli prohledávat jednotlivé úkoly, aby si udělali celkový obrázek.
Provádějte testovací cykly s využitím různých zobrazení. Použijte zobrazení „Board View“ seskupené podle stavu, abyste během testovacího běhu na první pohled viděli rozložení úspěšných a neúspěšných testů. Zobrazení „Table View“ funguje jako tradiční testovací matice, když potřebujete prohledat výsledky napříč desítkami případů. Filtrujte podle přidělené osoby, abyste vyvážili pracovní zátěž, nebo podle priority, abyste se při kouřovém testování nejprve zaměřili na kritické cesty.
Šablona pro správu testování v ClickUp vám nabízí centralizovaný způsob, jak na jednom místě spravovat celý pracovní postup testování napříč různými funkčními oblastmi, testovacími scénáři a okrajovými případy. Využijte ji ke sledování zpětné vazby od uživatelů, správě harmonogramů testů, monitorování průběhu testů a vyhodnocování výsledků (úspěšné/neúspěšné) bez nutnosti přepínat mezi různými nástroji.
Efektivní řízení vašich testovacích procesů
Testovací případ splňuje svůj účel v okamžiku, kdy jej mohou nezávisle spustit dvě osoby a dospět ke stejnému výsledku – úspěchu nebo neúspěchu. Vše v této příručce (jedna akce na krok, jasně stanovené předpoklady, očekávané výsledky bez prostoru pro interpretaci) slouží právě tomuto jedinému standardu. Pokud již plánujete sprinty v ClickUp, výše popsané nastavení vám umožní psát, spouštět a sledovat testovací případy spolu s chybami, které odhalí, aniž byste museli přidávat další nástroj.
Zaregistrujte se na ClickUp zdarma
Často kladené otázky týkající se testovacích případů
Kolik testovacích případů by měl mít jeden požadavek?
Jeden požadavek může vyžadovat jeden testovací případ nebo i deset, v závislosti na tom, kolik scénářů, okrajových případů a variant vstupů zahrnuje. Cílem je pokrýt všechny realistické cesty a zajistit dostatečné pokrytí bez redundance.
Jaký je rozdíl mezi testovacími případy a testovacími skripty?
Testovací případ dokumentuje, co se má testovat a jaký výsledek lze očekávat, a je určen k ručnímu provedení. Testovací skript je naopak automatizovanou verzí: kód, který tyto stejné kroky provádí programově.
Jak podrobné by měly být testovací kroky?
Rozdělte test na logické, postupné kroky, které lze snadno sledovat i bez předchozího kontextu. Neslučujte více akcí dohromady a nepřidávejte zbytečnou složitost.
Testovací scénář v jednom řádku uvádí, co se má testovat („Ověřit resetování hesla“); testovací případ specifikuje jak se to má provést, včetně předběžných podmínek, kroků, testovacích dat a očekávaných výsledků. Jeden scénář obvykle generuje 3 až 10 testovacích případů pokrývajících normální průběh, neplatné vstupy a hraniční podmínky. Scénáře přicházejí na první místo a určují plánování pokrytí; testovací případy přicházejí na druhé místo a řídí provádění testů.
Pozitivní testovací případ používá platný vstup a očekává úspěch: správná e-mailová adresa a heslo uživatele přihlásí. Negativní testovací případ používá neplatný nebo neočekávaný vstup a očekává, že systém selže elegantně: nesprávné heslo zobrazí hlášení „Neplatné heslo“ bez vytvoření relace. Vyspělé testovací sady mají poměr pozitivních a negativních testů přibližně 1:3 až 1:5, protože většina chyb v produkčním prostředí se vyskytuje v chybových scénářích, nikoli v úspěšných scénářích.
Testovací plán definuje rozsah, přístup, zdroje a harmonogram celého testovacího úsilí. Testovací sada je soubor testovacích případů seskupených pro jeden průběh, například „regresní sada pro verzi 2.1“. Testovací případ je základní jednotkou v obou: jedná se o jednu zdokumentovanou kontrolu s jedním výsledkem (úspěch/neúspěch). Plán stanovuje strategii, sada určuje rozsah, případ určuje výsledek.