Většina testovacích případů selže ještě předtím, 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 čtoucí stejný případ by se neshodli na tom, co znamená „prošel“. Výsledek: chyby proklouznou, testovací běhy nelze reprodukovat a kontrola kvality se stává úzkým hrdlem namísto záchranné sítě.
Při psaní dobrého testovacího případu nejde ani tak o testovací dovednosti, jako spíše o návrh ověřování. Ve finančních službách se tomuto procesu říká „maker-checker“. V oblasti jaderného velení se tomu říká „pravidlo dvou osob“. Princip je stejný: kritické úkony by nikdy neměly záviset na jediné neověřené 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 věcmi nelze přehlédnout.
Ukážeme vám, jak psát testovací scénáře, 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 popsané očekávané výsledky, aby bylo možné výsledek zkontrolovat. Tato příručka popisuje sedmikrokový proces psaní testovacích případů, uvádí tři praktické příklady a vysvětluje, jak zajistit spolehlivost testovací sady 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 testovací strategii) 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í do webové aplikace. 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 ukázkový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 „2026 State of Testing Report“ společnosti PractiTest využívá 76,8 % testovacích specialistů AI v oblasti zajištění kvality (QA), přičemž dvěma nejčastějšími způsoby využití jsou tvorba testovacích případů (69,6 %) a údržba skriptů (59,6 %). Tato změna se nejvíce projevuje u automatizovaných testovacích případů, proto stojí za to vědět, v čem se liší od těch manuálních.
| Parametr | Ruční testovací případy | Automatizované testovací scénáře |
|---|---|---|
| Provedení | Provádí lidský tester, který se řídí sadou zdokumentovaných kroků | Prováděno pomocí softwarových nástrojů, skriptů nebo agentů umělé inteligence |
| Rychlost | Pomalé a časově náročné, protože lidé musí ručně zadávat data a ověřovat výsledky | Umí spouštět stovky testovacích případů současně |
| Opakovatelnost | Náchylné k lidským chybám a nejednotnému výkladu jednotlivých kroků | Vysoká opakovatelnost a konzistentnost při řádné údržbě testovacích skriptů |
| 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é kompilaci |
| Údržba | Vyžaduje ruční aktualizace 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ý případ, jeden ho označí jako prošel, druhý nahlásí chybu, a tým teď 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 žádný 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ěňujete tacitní znalosti v opakovaně využitelné aktivum. Ve většině týmů má seniorní inženýr QA v hlavě neviditelnou mapu každého okrajového případu, každého workaroundu, každého „jo, nezapomeň zkontrolovat taky X“. Když tato osoba odejde na dovolenou nebo změní tým, ta mapa odejde s ní. Dokumentované testovací případy s explicitními předběžnými podmínkami a mezními hodnotami tyto znalosti zachovávají ve strukturované podobě. Nový tester, který se připojí k týmu, si může hned první den vybrat TC_LOGIN_005 a otestovat postup „zablokování účtu po pěti pokusech“, aniž by se musel kohokoli ptát, jaká je prahová hodnota nebo jak se resetuje časovač.
Chyby izolujete na konkrétní kroky, nikoli na obecné oblasti. Když 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í selhalo“. “ 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: „Kliknout na ‚Odeslat odkaz pro reset‘ → očekávaná zpráva o úspěchu, došlo k chybě 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é oblasti funkcí má hledat.
Uvidíte, co je pokryto a kde jsou slepá místa. Bez strukturovaných testovacích případů je pokrytí testů jen 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 máte testovací případy pouze pro tři z nich, je tato mezera viditelná a kvantifikovatelná. Právě tato přehlednost mění testování z pouhého „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 s funkcí přihlášení na web, 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í 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 vytváření reportů.
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 uzamčen.
- 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 spuštění 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í, jak by se systém měl chovat, 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 řídicí 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: Zaznamenávají 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 využít vaše dovednosti v psaní testovacích případů.
Věděli jste, že? Pouze 2,1 % týmů popisuje své postupy při testování AI jako optimalizované, zatímco více než 85 % se stále nachází v počáteční nebo experimentální fázi. 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)
Napsání testovacího případu zahrnuje sedm kroků: analýza požadavku, seznam scénářů, plánování struktury, sepsání kroků s očekávanými výsledky, doplnění kontextu, kontrola, provedení a zaznamenání výsledků.
Krok 1: Analyzujte požadavky
Než začnete psát testovací případ, ujistěte se, že rozumíte tomu, 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: Vyvíjí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 obnovení hesla, obdržet jej e-mailem a nastavit nové heslo?
- Co by se mělo stát po provedení těchto akcí, tj. zaš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á z funkcí nejasná nebo nedefinovaná? Pokud ano, vyjasněte si to s příslušnými zúčastněnými stranami.
Tato jasnost vám poskytne základ pro stanovení jednoho jasného cíle pro váš testovací případ.
Cíl: Ověřte, zda si registrovaný uživatel může úspěšně resetovat heslo prostřednictvím e-mailu.
Krok 2: Určete různé testovací scénáře
Dále si sepište seznam testovacích scénářů, které potřebujete ověřit. Testovací scénář představuje situaci na obecné úrovni – takovou, která se obvykle rozvětvuje do několika testovacích případů pokrývajících různé vstupy a výstupy.
V případě funkce 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-mailová adresa: 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 resetování.
- 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 zažádá o několik resetů 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 okrajový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 nastavte strukturu testovacích případů
Pro opakované regresní testování potřebujete strukturu, která vám umožní důsledně 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 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
- Tým pro bezpečnost: 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 AI?
- 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:
- Existuje uživatelský účet s e-mailovou adresou „test@example.com“
- Uživatel je odhlášen ze systému
- E-mailová služba je aktivní a schopná doručovat zprávy
- Testovací prostředí je dostupné 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ů
- Omezení: heslo musí přesně odpovídat minimálnímu a maximálnímu 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 nebo 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 | Na přihlašovací stránce se po kliknutí zobrazí odkaz „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 zpráva o úspěšném provedení: „Odkaz pro resetování byl odeslán na adresu test@example.com“ |
| Otevřete odkaz pro resetování 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 je 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 tvorbu dokumentace pro všechny vaše testovací případy.
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 ukazující, 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, které 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 zahrnující konkrétní verzi softwaru, požadovaný hardware, operační systém a případná nezbytná bezpečnostní oprávnění
- Pro testování API: specifikace OpenAPI nebo dokumentace koncových bodů s podrobnými informacemi o metodách požadavků, parametrech a očekávaných stavových kódech
Krok 6: Nechte si testovací případ zkontrolovat
Před spuštěním testu sdílejte napsaný testovací případ s kolegou nebo vedoucím týmu QA. Během kontroly ověřte, 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ě představují skutečný průběh provádění.
- Každý očekávaný výsledek označuje 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 příslušným testovacím případem. Pokud navíc dojde k neočekávanému chování, které nelze jednoznačně označit jako úspěšné nebo 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ích případů 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 online prodejce testuje proces platby před svátečními slevami. Tento proces zahrnuje několik stránek: košík → doprava → platba → potvrzení. Klíčovou 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 testu: 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:
- Existuje uživatelský účet s alespoň jednou uloženou kreditní kartou a jednou uloženou doručovací adresou
- Alespoň jedna položka je skladem a byla přidána 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 | Úspěšné/Neúspěšné |
| 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 |
| Klikněte na „Přejít k pokladně“ | Na stránce s doručením se načte předem vybraná uložená adresa | Jak se dalo očekávat | Složit |
| Vyberte možnost „Standardní doprava“ a klikněte na Pokračovat | Na stránce platby se po načtení zobrazí celková částka objednávky včetně nákladů na dopravu | Jak se dalo očekávat | Složit |
| Potvrďte uloženou kreditní kartu a klikněte na „Objednat“. | Zobrazí se stránka s potvrzením objednávky, na které je uvedeno číslo objednávky, souhrn položek a předpokládané datum 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 u uložených kreditních karet selhává. 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í, na které by bylo třeba 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 testu: 09. 05. 2026
ID testovacího případu: TC_API_USER_001
Popis: Ověřte, zda požadavek POST na /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 | Úspěšné/Neúspěšné |
| Odešlete požadavek POST na adresu /api/v1/users s platným obsahem: { "name": "Test User", "email": "newuser@testdomain. com", "role": "viewer" } | Odpověď vrací 201 Created s tělem JSON obsahujícím ID uživatele, jméno, e-mail a roli | 201 vráceno se správným tělem | Složit |
| Odešlete znovu stejný požadavek POST s identickým e-mailem | 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í |
| Odešlete požadavek POST s chybějícím polem „email“ | Odpověď vrací stav 400 Bad Request s chybou validace: „E-mail je povinný“ | 400 vráceno podle očekávání | Složit |
| 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 |
Shrnutí výsledků: Endpoint správně vytváří uživatele a ověřuje povinná pole, ale na úrovni databáze nedokáže zajistit jedinečnost e-mailových adres. Duplicitní záznamy byly vytvořeny bez chyby. Chyba byla zaznamenána se závažností: Vysoká.
Příklad 3: Řízení přístupu na základě rolí (bezpečnost, omezení 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ě zamítnuto. Očekávaným výsledkem u většiny kroků je blokování, nikoli úspěch.
Tester: Marcus L.
Datum testu: 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.
- Uživatel 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č vidí seznam projektů v režimu pouze pro čtení; tlačítko „Vytvořit projekt“ je skryté nebo deaktivované | Tlačítko je viditelné, ale je šedé | Složit |
| 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 |
| Otevřete existující projekt a zkuste upravit jeho název | Pole „Název“ nelze upravit, případně 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 odstranění je skrytá nebo je akce blokována chybou oprávnění | Možnost smazání není v nabídce viditelná | Složit |
Shrnutí výsledků: Oprávnění k vytváření a mazání jsou u uživatelů s rolí „Prohlížeč“ správně omezena, avšak oprávnění k úpravám nejsou vynucena na úrovni polí. Uživatel s rolí „Prohlížeč“ může upravovat 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 ve specializovaném nástroji pro kontrolu kvality (TestRail, Zephyr), v obecnějším nástroji pro projektové řízení (ClickUp, Jira) nebo v tabulkovém procesoru; správná volba závisí na tom, zda potřebujete integrované spouštění testů, nebo pouze jejich sledování.
ClickUp
ClickUp pro softwarové týmy je platforma pro řízení projektů, kde jsou testovací případy uloženy jako úkoly vedle sprintů, chyb a žádostí o začlenění, ke kterým se vztahují. Nejedná se o specializovaný nástroj pro správu testování, 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 bylo nutné používat 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 (nástěnka, 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 návodů k nastavení prostředí po boku testovacích případů, na které se vztahují
- Integrovaný chat pro komunikaci mezi QA a vývojáři 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 v rámci sprintových revizí
Omezení ClickUp
- Žádný nativní engine pro provádění testů
- Zprávy specifické pro testování (pokrytí podle požadavků, míra úspěšnosti v jednotlivých cyklech) vyžadují přizpůsobené řídicí panely, nikoli přednastavené reporty pro kontrolu kvality.
Ceny 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 ClickUpu?
Toto říká jeden z recenzentů na G2:
Na ClickUp se mi nejvíc líbí, že vše sdružuje na jednom místě. Úkoly, časové osy, poznámky i aktualizace jsou soustředěny v jednom systému, což omezuje neustálé přepínání mezi různými nástroji. Oceňuji také flexibilitu. Můžeme si přizpůsobit stavy, pole a zobrazení tak, aby odpovídaly skutečnému způsobu práce našeho týmu. 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í.
Na ClickUp se mi nejvíc líbí, že vše sjednocuje na jednom místě. Úkoly, časové osy, poznámky i aktualizace jsou uloženy 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 stejného úkolu.
Tuto část přeskočte, pokud: Váš testovací cyklus je z větší části automatizovaný. Pokud 80 % vaší testovací sady běží z CI pipeline, potřebujete nástroj, který automaticky načítá výsledky provedení, nikoli takový, kde stav aktualizuje člověk.
TestRail
TestRail je specializovaná platforma pro správu testování vytvořená pro týmy QA, které potřebují strukturovanou kontrolu nad celým procesem testování. Zajišťuje kompletní cyklus psaní, spouštění a vykazování testovacích případů, přičemž výsledky jsou přenášeny prostřednictvím integrací s DevOps a CI/CD.
Klíčové funkce TestRailu
- Centralizovaná správa testovacích případů a testovacích sad s testovacími případy, které lze opakovaně používat 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ů a 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 čítají v tisících, se orientace v organizaci založené na složkách stává obtížnou.
Ceny služby TestRail
- Professional: 39 $/uživatel/měsíc
- Enterprise: 78 $ za licenci za 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 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.
Ideální pro: Tým QA s pěti nebo více členy, 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“ přímo z dashboardu, nikoli z tabulky.
Přeskočte tento bod, pokud: Vaše sada obsahuje méně než několik set testovacích případů nebo pokud vaši testeři zároveň působí jako vývojáři. V takovém měřítku jsou náklady na jedno uživatelské místo a samostatné přihlášení zbytečné, protože získáte přehledy, které stejně nebudete sledovat.
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 přehledů 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 uživatele Jira, nikoli na 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 zajišťována prostřednictvím Atlassian Marketplace, což představuje další úroveň pro týmy zvyklé na přímou podporu od dodavatele.
Ceny služby 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ů)
- Advanced: od 8,73 $ za uživatele a měsíc (11–50 uživatelů)
Hodnocení a recenze aplikace 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:
Jedná se o 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.
Jedná se o 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.
Nejvhodnější pro: Týmy v regulovaných odvětvích nebo s častými audity (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 – to vše v rámci jedné instance Atlassian.
Tuto část přeskočte, pokud: Vaše instance Jira je rozsáhlá a váš tým QA je malý. Jira s kapacitou 200 uživatelů 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 ke správě sprintů, chyb a vývojových procesů. Ačkoli se nejedná o specializovaný nástroj pro správu testů, mnoho týmů jej 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 procesů
- Přizpůsobitelné pracovní postupy, typy úkolů a pole, které odpovídají způsobu, jakým váš tým sleduje práci
- Pokročilé plány 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í úkolů 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ě vlastní poplatek za každého uživatele.
- Pro uživatele bez technických znalostí 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ší funkce pro virtuální sledování výkonu 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ší funkce pro virtuální sledování výkonu ve své třídě, což mi usnadňuje dosahování všech mých profesních cílů.
Vhodné pro: Inženýrské týmy, které zvažují, zda vůbec potřebují specializovanou správu testování. Provedení několika testovacích cyklů nejprve jako vlastních typů úkolů v Jira ukáže, zda objem testování ospravedlňuje použití pluginu.
Tento krok přeskočte, pokud: Už 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 úkolů 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í sepsání 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í |
| Testovací případy se neaktualizují | Aktualizujte testovací případ, jakmile dojde k aktualizaci funkce, změně jejího chování nebo 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 smazán, košík vyprázdněn, relace ukončena), aby další testovací případ mohl začít z čistého stavu. |
| Pouze data z optimálního scénáře | Každé vstupní pole potřebuje alespoň jednu hodnotu, kterou by systém měl odmítnout. Zaznamenejte, jak se datový soubor generuje nebo načítá. |
| Nepřikládání priority testovacím případům | 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 informovanější rozhodnutí ohledně rozpočtu a testovacích metod |
Jak zajistit, aby testovací případy zůstaly užitečné i v dlouhodobém horizontu
Testovací sada zůstává spolehlivá, pokud je každý případ 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é po léta odhalují chyby, od těch, které jsou po druhém sprintu ignorovány.
Vytvářejte 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 testovací případ TC_CHECKOUT_003 předpokládá, že testovací případ TC_CHECKOUT_002 zanechal položku v košíku, jedna chyba se rozrostla na pět a vy strávíte dopoledne zjišťováním, která z nich 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í textu „zadejte test@example.com“ do kroku znamená, že při každé změně testovacího prostředí budete muset tento krok přepisovat. Udržujte kroky obecné („zadejte registrovanou e-mailovou adresu“) a skutečné hodnoty uložte do pole nebo souboru s testovacími daty. Stejné kroky pak lze spustit v testovacím, QA a předprodukčním prostředí bez úprav a nahrazení datovým souborem pro negativní test vyžaduje pouze změnu jednoho řádku.
Sledujte nestabilní testy a míru úniku chyb
Nestabilní test selhává nepravidelně, aniž by se jednalo o skutečnou chybu produktu, a každý takový test učí tým ignorovat červené výsledky. Sledujte, jak často se u jednotlivých sestavení mění výsledek každého testovacího případu mezi „prošel“ a „neprošel“. Pokud se u testovacího případu vyskytne nestabilita 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 na automatizaci, protože se spouštějí při každé kompilaci a málokdy se mění. Přesuňte je do skriptů ve vašem CI/CD procesu a tam, kde se prvky uživatelského rozhraní často mění, používejte nástroje podporované umělou inteligencí s lokátory s funkcí automatické opravy. Tím se uvolní lidští testeři 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.
Strukturovejte svou knihovnu testovacích případů. Vytvořte prostor pro svůj produkt, složku pro každou oblast funkcí (např. ověřování, platby, zapojení nových uživatelů) 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 komponenty, jako je ID testovacího případu, předpoklady, testovací data, úroveň priority a prostředí.
Napište testovací kroky přímo do úkolu. V popisu úkolu zdokumentujte postupné kroky provádění a očekávané výsledky. Kontrolní seznamy se hodí pro postupné toky, kde tester musí odškrtávat jednotlivé akce, zatímco popis obsahuje kontext, jako jsou předběžné podmínky a testovací data.
Sledujte průběh a výsledky. Vytvořte 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 agentovi ClickUp Codegen, který si přečte popis úkolu, propojené specifikace a komentáře, napíše návrh opravy a otevře pull request k revizi, přičemž průběh se zaznamená 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ý obraz.
Spouštějte testovací cykly pomocí různých zobrazení. Využijte zobrazení „Board View“ (tabule) 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“ (tabulka) funguje jako tradiční testovací matice, když potřebujete prohledat výsledky napříč desítkami testovacích případů. Filtrujte podle přidělené osoby, abyste vyvážili pracovní zátěž, nebo podle priority, abyste se při zkušební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 oblastmi funkcí, testovacími scénáři a hraniční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é), aniž byste museli přepínat mezi různými nástroji.
Efektivní správa testovacích procesů
Testovací případ si zaslouží své místo v okamžiku, kdy jej mohou nezávisle spustit dvě osoby a dospět ke stejnému výsledku – úspěšnému nebo neúspěšnému. Vše v tomto průvodci (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 do 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 je třeba otestovat 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ěřte resetování hesla“); testovací případ specifikuje jak se to má provést, včetně předpokladů, 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 správný 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ě: při zadání nesprávného hesla se zobrazí hlášení „Neplatné heslo“, aniž by došlo k 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 jedno spuštění, například „regresní sada pro verzi 2.1“. Testovací případ je základní jednotka v obou: jedna zdokumentovaná kontrola s jedním výsledkem (úspěch/neúspěch). Plán určuje strategii, sada určuje rozsah a případ určuje výsledek.