Jakmile jsou identifikovány testovací podmínky a je k dispozici dostatek informací a podkladů pro testování, je možné přejít k návrhu testovacích případů. Testovací případy specifikují, jak má být něco otestováno a je vhodné je přímo či nepřímo (přes testovací podmínky) vztáhnout na podklady pro testování, produktová rizika, strategické cíle a cíle testování.
Jako první krok před zahájením samotné tvorby testovacích případů je zapotřebí si ujasnit míru detailu testovacích případů v jednotlivých oblastech testování, protože ne ve všech oblastech testování a situacích musí být míra detailu stejná.
Konkrétní testovací případy (ve velkém detailu) poskytují veškeré specifické informace, data a skripty, které jsou potřebné při provádění testovacích případů a verifikaci výsledků [ISTQB, 2012b, s. 13]. Ve větší míře detailu jsou testovací případy navrhovány v případě, kdy požadavky na systém jsou dobře definované, testeři, kteří provádějí testy, nemají příliš zkušeností, nebo pokud jsou testovací případy předmětem auditu. Výhodou konkrétních testovacích případů je snadná ověřitelnost a reprodukovatelnost, kdy při provedení daného testu různými osobami v různém čase je dosaženo stále stejných výsledků. Nevýhodami jsou značný objem úsilí při vytváření a údržbě testovacích případů a potlačení flexibility testera při provádění testů.
Logické testovací případy (v malém detailu) poskytují pouze návody na to, co by mělo být otestováno, přičemž tester, který provádí testovací případ, může obměňovat testovací data i samotný skript přímo při provádění testu [ISTQB, 2012b, s. 13]. V menší míře detailu jsou testovací případy navrhovány v případě, kdy požadavky jsou špatně definovány, testeři, kteří provádějí testy, mají dostatek zkušeností s daným produktem i s testováním a pokud testovací případy nejsou předmětem auditu. Výhodou logických testovacích případů je možnost vyššího pokrytí testovacích podmínek, protože testovací případy se mohou modifikovat při každém spuštění. Větší flexibilita testera při provádění testů také umožňuje, aby se tester zabýval potenciálně zajímavými oblastmi, které v danou chvíli uzná za vhodné otestovat. Nevýhodou méně detailních testovacích případů je naopak malá reprodukovatelnost.
Problém s určením optimální míry detailu testovacích případů lze vyřešit postupným zpřesňováním testovacích případů od logických ke konkrétním. Při provádění testů se potom postupuje podle nejdetailnějších testovacích případů.
Druhým krokem před tvorbou testovacích případů je určení technik pro návrh testů, které optimálně pokryjí testovací podmínky. Technik, které je možné při návrhu testů využít, je celá řada. V úloze definice přístupu k testování je uvedena jejich základní kategorizace. Na úrovni plánu testování jsou techniky identifikovány v rámci přístupu k testování. Úkolem test analytika je uvážit, které z technik použije při návrhu testovacích případů pro konkrétní oblasti a v případě potřeby identifikovat další techniky, které dosud v plánu testování identifikovány nejsou. Známými a na úrovni systémových testů často používanými technikami, jsou techniky rozdělení tříd ekvivalencí a analýza hraničních hodnot, viz technika rozdělení tříd ekvivalencí a technika analýza hraničních hodnot. Podrobný popis dalších technik lze nalézt například v [Singh, 2012].
Po určení míry detailu a technik pro návrh testovacích případů je možné přistoupit k samotnému vytváření testovacích případů. To, jak má testovací případ vypadat je popsáno v pracovním produktu testovací případ. Zde uvádím doporučení, na která je vhodné při návrhu testovacích případů pamatovat:
· Testovací případy spolu s testovacími skripty by měly být výstižné a srozumitelné, aby je bez potíží mohly provádět i jiní testeři než jen autor testovacího případu. Nejen testerům, ale i ostatním zainteresovaným stranám by měly být testovací případy a skripty srozumitelné. Srozumitelnost je důležitá např. pro vývojáře, kteří při opravách defektů potřebují znát kroky, které předcházely selhání, ale také pro strany, které mají zájem na způsobu ověření kvality softwaru (auditoři, manažer produktu, projektový manažer, sponzor projektu, apod.).
· Při návrhu testovacích případů je třeba pokrýt různé interakce softwaru s jeho aktéry. Aktérem však nemusí být pouze koncový uživatel, ale i jiné systémy. Kromě defektů, které se objevují skrze selhání uživatelského rozhraní, mohou vznikat defekty při dávkovém zpracování, při komunikaci interních procesů, nebo na rozhraní několika objektů testování. Proto je důležité navrhnout testovací případy tak, aby i tato rizika byla pokryta.