Plán testování

V tomto příspěvku se dozvíte, co je to testovací plán, plán testování nebo chcete-li plán testů, jaká je jeho struktura a jaké informace by měl obsahovat.

Hned v úvodu bych chtěl zdůraznit, že plán testování není nic jiného, než dokument, který slouží k popsání toho, co se bude testovat a to kdy, kde, jak, kým a čím. Vzhledem k tomu, že testovacích plánů může vzniknout několik a dokonce v různých verzích, obzvlášť ve společnostech, které se vývojem a testováním SW zabývají, je nutné zajistit, aby se vždy pracovalo se správným testovacím plánem.

Každému testovacímu plánu by proto měl být přidělen jednoznačný identifikátor, který se nejčastěji sestavuje z názvu aplikace nebo modulu, který je předmětem testování a čísla vyjadřujícího verzi plánu. Jednoznačný identifikátor doporučuji uvádět nejen na hlavní stránce, ale i v záhlaví nebo zápatí každé stránky a stránky číslovat (číslo stránky / celkový počet stran).  Na první stránce by měl být též uveden text „Plán testování“ a poté by mělo následovat jméno osoby resp. osob, které jsou autory tohoto dokumentu. Dokument má obvykle následující strukturu:

Úvod (Introduction/Management summary)
V této kapitole je vhodné velice stručně uvést, k čemu SW, který se bude testovat, slouží, kdo ho používá a z jakých hlavních částí se skládá. Na jaké HW a SW konfiguraci systém bude běžet a na jaké HW a SW konfiguraci se bude testování provádět. Kdo, kde, kdy a jak bude testování provádět.

Dokumentace (Test items)
Zde by měly být uvedeny dokumenty, ze kterých se bude při návrhu testů vycházet. Obvykle se jedná o specifikaci softwarových požadavků (Software Requirements Specification), uživatelskou příručku (User Guide), příručku operátora (Operator Guide) a instalační příručku (Installation Guide). Pokud píšete testy ještě dřív, než se začne programovat, budete mít k dispozici jen SRS. Doporučuji jednoznačně identifikovat SW, který se má testovat, včetně čísla verze a jeho umístění. Určitě nechcete omylem otestovat starou verzi nebo provádět testy v jiném prostředí.

Vlastnosti, které budou testovány (Features to be tested)
Zde by měly být uvedeny všechny vlastnosti, které se mají testovat. Každá vlastnost by měla být popsána a měla by mít přidělen jednoznačný identifikátor.

Vlastnosti, které nebudou testovány (Features not to be tested)
Zde by měly být uvedeny vlastnosti, které se nemají testovat a proč. I zde doporučuji uvést u jednotlivých vlastností jednoznačný identifikátor. Především proto, že jedině tak lze zjistit, zda se na některé vlastnosti uvedené v SRS nezapomnělo.

Průběh testů (Approach)
Zde by měl být uveden stručný popis toho, jak jednotlivé testy budou probíhat a jaký způsob testování bude u jednotlivých typů testů použit. V této kapitole je třeba také uvést nad jakými daty a v jakém prostředí bude testování probíhat a zda se budou data obsahující např. osobní údaje nějakým způsobem modifikovat.

Přerušení testů (Suspension criteria and resumption requirements)
Zde by měly být uvedeny podmínky, za jakých je možno testy zastavit a co je nutné udělat pro to, aby se mohlo v testování pokračovat.

Výstupy z testování (Test deliverables)
Seznam dokumentů, které by měly v rámci testování vzniknout. Minimálně by se mělo jednat o dokumenty popisující: testovací případy, testovací procedury, testovací logy a závěrečnou zprávu o testování.

Harmonogram testování (Schedule)
Vzhledem k tomu, že testování je vhodné pojmout jako projekt, který se musí naplánovat a určit kdo, kdy a co má dělat, nejedná se tedy v podstatě o nic jiného, než o vytvoření WBS. Teoreticky by se sice dalo testovat do nekonečna, ale vzhledem k tomu, že disponujeme jen omezenými zdroji, není možné otestovat všechno a stejně detailně. V praxi prostě musíme něco otestovat velice důkladně, a něco jen zběžně. Většinou podle toho, které funkčnosti jsou pro zákazníka nejdůležitější. To je ostatně důvod, proč by měl být zákazník do testování zapojen.

Požadavky na zdroje (Environmental needs)
V této kapitole by měly být uvedeny veškeré požadavky na zdroje tzn. na HW a SW vybavení, nároky na prostory a jejich vybavení, přístupy do těchto prostor, přístupy do daného systému a aplikace, dodání dokumentace, testovacích dat.

Odpvědnosti (Responsibilities)
Stejně jako v jakémkoliv jiném projektu i při testování lze Identifikovat různé skupiny nebo jednotlivce, kteří mají odpovědnost za splnění jednotlivých úkolů. Typicky se jedná o osoby odpovědné za řízení celých testů, přípravu podmínek pro testování, vlastní testery, správce systému, vývojáře a v neposlední řadě i vlastníka dat. Odpovědnosti jednotlivých osob a skupin je vhodné uvést právě zde.

Personální zajištění (Staffing and training needs)
Počet členů jednotlivých skupin a požadavky na proškolení a znalosti testerů jsou obsahem této kapitoly. Je zřejmé,  že čím vyšší požadavky na znalosti testerů jsou kladeny, tím méně detailní potom musí být popis testovacích případů. A naopak, čím kvalitnější popis testovacích případů máme, tím nižší jsou nároky na znalosti testerů.

Rizika (Risks and contingencies)
Zde bychom měli popsat, jaká jsou rizika. Např. že nebude včas dodána verze SW, který se má testovat, nebude připraveno pracoviště pro testery apod.

Souhlas s testováním (Approvals)
Na poslední straně dokumentu se obvykle uvádí datum a jména osob, které svým podpisem odsouhlasí daný testovací plán.

Poznámka: Názvy jednotlivých kapitol uvádím jak v češtině, tak i v angličtině. Ne vždy se jedná o doslovný překlad, srovnejte např. s IEEE 829 Standard for software and system test documentation.

A jakou strukturu a obsah má váš plán testování?

Štítky: Testování SW

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.