Testovací scénář

V tomto příspěvku se dozvíte, co je to testovací scénář a jak se testovací scénáře vytváří.

Testovacímu scénáři by měl být přidělen jednoznačný identifikátor a měl by obsahovat odkaz na Plán testování (ten by zase měl jednoznačně identifikovat testovací scénáře). Testovací scénář je tvořen sadou testovacích případů. Může se jednat o testovací případy, které na sebe navazují a musí být vykonány v přesně uvedeném pořadí. Nebo na pořadí, v jakém jsou jednotlivé testovací případy prováděny, nezáleží. Testovací scénář může mít stejnou hierarchickou strukturu jako má specifikace požadavků. Cílem test designera by mělo být pokrytí všech požadavků odpovídajícími testovacími případy. Běžně se postupuje tak, že se provede návrh testovacích scénářů, následně dojde k jejich posouzení a poté k jejich případné opravě. Testovací scénář, pokud má podobu dokumentu, mívá obvykle tuto strukturu:

  • Vlastnosti, které budou testovány (Features to be tested) – co bude obsahem této kapitoly už asi tušíte. Všimněte si ale, že zde není kapitola Vlastnosti, které nebudou testovány (Features not to be tested). Tak je to správně, protože co se nebude testovat, jsme si již uvedli v Plánu testování a bylo by naprosto zbytečné to tady znovu opakovat.
  • Přístup k testování (Test approach) – způsoby testování a typy testů jsme si popsali již v samostatných článcích.
  • Testovací případy – v této kapitole se uvádí jednotlivé testovací případy a případně i testovací skripty, které budou pro dané testovací případy použity.
  • Kritéria – (Pass/Fail criteria) – zde se obvykle uvádí kritéria, na základě kterých je možno rozhodnout o tom, zda test prošel nebo ne.

Vzhledem k tomu, že některé testovací případy mohou být použity i v jiném testovacím scénáři nebo dokonce i v rámci testování úplně jiné aplikace, pravděpodobně se v praxi s dokumentem tohoto typu nesetkáte. Je to proto, že ten kdo se testováním vážně zabývá, používá obvykle nějaký SW nástroj, který mu umožňuje jednotlivé testovací případy a scénáře efektivně spravovat a využívat. Tímto způsobem je možné dosáhnout vysoké znovupoužitelnosti (reusability) testovacích případů a snížit tak náklady na testování.

Poznámka: V tomto příspěvku se úmyslně dopouštím určité nepřesnosti vůči IEEE 829. Ten totiž pojem testovací scénář vůbec nepoužívá. Místo něj hovoří o návrhu testů. Rozdíl je v tom, že zatímco design může v angličtině zastupovat jak sloveso (navrhnout) tak i podstatné jméno (návrh), tak scenario zastupuje jen podstatné jméno – scénář. Vycházím z jednoduchého předpokladu, že test designer navrhuje, jak by měl test probíhat a vytváří tak scénář nebo chcete-li test design.

A jaký nástroj na správu testovacích případů a scénářů používáte vy a jaký byste doporučili ostatním čtenářům?

Pokud vás tento článek zaujal, můžete odkaz na něj sdílet.

Štítky:


K článku “Testovací scénář” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: