Testovací dokumentace podle IEEE Standard 829–1998 for Software Test Documentation

Plán testů

  • Identifikátor testovacího plánu  unikátní číslo nebo jméno
  • Úvod – odkazy na související dokumenty
  • Testovací položky – jména funkcí, modulů, vlastností, atd.
  • Vlastnosti k testování – odkazy na funkční specifikace
  • Co se nebude testovat
  • Postup – kdo, co, jakým způsobem pro různé vlastnosti systému.
    Termíny, konkrétní zdroje, které budou testovat, způsob rozhodování o dokončení testů
  • Kritéria pro úspěšnost/neúspěšnost testů u testovacích položek – podle čeho bude tester rozhodovat o úspěšnosti/neúspěšnosti testů
  • Kritéria pro ukončení/obnovení testů – za jakých podmínek dojde k ukončení testů a za jakých podmínek může být test obnoven.
  • Výstupy testů – jaké dokumenty budou výstupem testování
  • Prostředí – parametry testovacího prostředí – hardware, software, místo, testovací nástroje, databáze
  • Zodpovědnosti – jména skupin lidí nebo jednotlivců zodpovědných za řízení, návrh, přípravu, provedení, kontrolu, opravu, vybavení, atd.
  • Personální obsazení a požadavky na vyškolení – kolik lidí na na všech úrovních kvalifikace bude potřeba a jaká budou potřebná školení
  • Harmonogram – seznam všech milníků a přehled toho, jaké zdroje budou kdy potřebné
  • Rizika a opatření – Jaká jsou nejvážnější rizika testování? Co se může pokazit a jaká bude následná náprava?
  • Schválení – Kdo bude dokument schvalovat? Místa pro podpisy.

Seznam funkcí

  • Seznam funkcí popisuje, co všechno systém dělá.
    Je praktické začít s jednoduchým seznamem, který se zpřesňuje během testů. Nejdříve je dobré načrtnout hlavní funkční bloky, první testy ukáží, kterou část je nutné rozpracovat na detailní kroky.
  • Postupně se doplňují informace jako jména funkcí a jejich viditelné a testovatelné výstupy.
  • Všechny příkazy, které je možné v programu zadat.
  • Všechny vstupy a odpovídající očekávané výstupy
  • Každé menu a každou volbu v menu.
  • Každý vstup do každé části aplikace – z menu, z příkazové řádky nebo z webového odkazu.
  • Každý výstup z každé části programu.
  • Každá vstupní obrazovka, dialogové okno a zpráva. Posloupnost přechodů mezi obrazovkami/okny.
  • Obsluha všech chyb.

Kritéria pro přijetí do testů

  • Obsahuje jednoduchý test, který musí projít, aby se vůbec dalo začít s testem.
    Musí být přesný a vysvětlený vývojářům ještě před prvním kolem testů, aby měli motivaci vyřešit jasné chyby dřív, než vejdou ve známost ostatních.
  • Pokud neprojde tento test, považuje se aplikace za příliš nestabilní k testování
  • Účelem tohoto dokumentu je spojit související testované vlastnosti do logického celku.
  • Identifikátor specifikace návrhu testů – unikátní číslo nebo jméno
  • Vlastnosti, které se budou testovat – rozsah specifikace
  • Postup – rozšíření postupu z testovacího plánu. Popis specifických testovacích metod.
    Jak se budou analyzovat výsledky? Srovnávacím programem, visuálně? Popis hraničních hodnot nebo ostatních podmínek, které vedou k výběru konkrétních testovacích případů. Popisuje všechna omezení a společné požadavky všech testů této specifikace
  • Identifikace testů – kompletní seznam testovacích případů se stručným popisem každého testu, který souvisí s tímto návrhem. Jeden testovací případ může být uveden u většího počtu návrhů, pokud ověřuje různé vlastnosti systému.
  • Kritéria úspěšnosti/neúspěšnosti testů.

Specifikace testovacích případů

  • Identifikátor testovacího případu – unikátní číslo nebo jméno
  • Testované vlastnosti, moduly, funkce
  • Specifikace vstupů – rozsahy hodnot, jména souborů. Načasování pro vstupy, např. paralelní vstupy, rychlost vkládání dat, apod. Hodnoty přebírané z operačního systému, znění promptů(výzev ke vstupu dat) a vztahy mezi vstupy
  • Specifikace výstupů – seznam všech výstupů a zpráv. Pokud je to důležité, doby odezvy.
  • Požadované prostředí – zvláštní požadavky, vč. hardwaru, softwaru a personálního obsazení
  • Zvláštní procesní požadavky – všechna specifická a neobvyklá nastavení, testovací procesy nebo požadovaná analýza výstupů
  • Závislosti mezi testovacími případy – jaké testy musejí být provedeny před tímto testem, proč a co dělat, pokud program zhavaruje.

Specifikace testovacích procesů

  • Identifikátor testovacího procesu – unikátní číslo nebo jméno
  • Účel – na co je tento proces dobrý? Odkazy na všechny testovací případy, které se řídí tímto procesem.
  • Zvláštní požadavky – procesy, na kterých je tento proces závislý, požadované znalosti testerů, požadavky na testovací prostředí
  • Procesní kroky
    • Log – jakým způsobem se zaznamenávají výsledky testů
    • Nastavení – popis přípravy testů
    • Začátek – jak se spouští test
    • Vykonávání – všechny akce, které se provádějí během testování
    • Měření – jak se měří měřitelné charakteristiky (objemy dat, časy odezvy)
    • Přerušení – co je nutné udělat/dodělat před dočasným přerušením testů
    • Pokračování – kde a jak se má na testech pokračovat po dočasném přerušení
    • Zastavení – jak správně ukončit testy bez možnosti pokračovat
    • Obnovení – jak nastavit testovací prostředí do původního stavu
    • Zálohy – co dělat, když se nic nedaří

Protokol o předání do testů

  • Identifikátor protokolu o předání do testů
  • Předávané položky – jména programů nebo modulů a jejich verze nebo čísla revizí. Jména osob zodpovědných za předání
  • Umístění – kde jsou předávané položky – disk, páska, sdílený adresář a jejich označení
  • Stav – jak se změnily předávané položky od posledního testování? Které chyby byly odstraněny? Změnila se specifikace nebo chování? Jaké další změny se chystají?
  • Schválení – Dokument podepisují lidé, kteří jsou oprávnění a souhlasí s předáním do testů

Testovací scénář

  • Obecné instrukce – jak vyplňovat záznam o neshodě (problem report), kde najít vzory dokumentů, jak používat scénář, apod.
  • Úvod – seznámení s prostředím pro testování
  • Popis každého testovacího kroku pro každý test
  • Zaškrtávací formuláře pro zaznamenání každého kroku testu a jeho výsledku
  • Prostor pro popis podivného chování nebo nepochopených částí, otázky.

Záznam o testech

  • Identifikátor záznamu
  • Popis – co se testovalo, v jakých verzích, kde se testovalo, na jakém zařízení a všechny informace o konfiguraci.
  • Seznam aktivit a událostí
    • Popis testovacího procesu – identifikátor procesu, realizátoři a jejich role
    • Výsledek procesu – co se stalo, co se dalo pozorovat a kde jsou uloženy výstupy
    • Prostředí – jaké změny prostředí se prováděly specificky pro tento testovací proces?
    • Anomálie – neočekávané události, co se stalo před a po jejich výskytu
    • Čísla záznamů o neshodách

    Záznam o neshodě (problem report)

    Cílem zápisu do problem reportu je odstranění chyby. Důležitá je stručnost a srozumitelnost popisu chyby a nezanedbatelný je i tón sdělení. Správný problem report přesně popisuje, jak reprodukovat problém co nejjednodušším způsobem. Postup pro reprodukování chyby je dobré důkladně ověřit. Testeři si často stěžují, že programátoři "notoricky" odkládají chyby jako nereprodukovatelné, přestože skutečný problém spočívá v tom, že testeři "notoricky" píší nepřesné a nekompletní problem reporty.

    Součástí taktiky testera je udržet funkční pracovní vztahy s programátorem, proto je dobré se vyhnout formulacím, které jej mohou iritovat a demotivovat při odstraňování chyb.

    Problem report typicky obsahuje:

      Oblast pro testera

    • Identifikátor – unikátní číslo
    • Program nebo modul, který se testuje
    • Verze: Release a verze (např. 2.13m, kde 2.13 je release a m je verze)
    • Typ chyby – typy chyb se mohou dohodnout v projektovém týmu, nebo je možné použít následující klasifikaci
      • programátorská chyba – program poskytuje výsledky v rozporu s očekáváním
      • chyba návrhu – program pracuje podle návrhu, ale návrh je podle názoru testera chybný
      • návrh – tester má návrh na změnu funkcionality aplikace
      • dokumentace – program se nechová podle popisu v helpu nebo v dokumentaci, sem spadají i funkce, které fungují správně, ale nejsou v dokumentaci
      • hardware – program nepracuje správně s nějakým typem hardware (tiskárna, čtečka, apod.)
      • sporné – program pracuje neočekávaně nebo nepochopitelně a tester si není jistý, jestli je to požadováno. Používá se i v případech, kdy je užitečné vysvětlení programátorem.
    • Závažnost – tester uvádí své hodnocení závažnosti. Může být zaveden systém číslování nebo slovní popis, pokud je to nejasné, je možné začít se slovní klasifikací jako Malá, Vážná, Fatální. Důležitá se týmová shoda na významu těchto kategorií.
    • Přílohy – dodatečné informace, které programátorovi usnadní práci při reprodukování chyby. Mohou to být data, sekvence kláves, makra apod.
    • Shrnutí – stručný popis problému, který vystihuje jeho podstatu. Každý problem report má mít unikátní shrnutí
    • Reprodukování problému – Ano/Ne/Někdy – popisuje, nakolik spolehlivě je tester schopný zreprodukovat chybu. Musí počítat s tím, že pokud je odpověď Ano nebo Někdy, může být požádán aby chybu osobně zreprodukoval. Při odpovědi Ne je dost pravděpodobné, že se chybou nebude nikdo zabývat. Většinou bývá dost těch, které se zreprodukovat dají.
    • Problém a jeho reprodukce – popis toho, v čem vidí tester chybu a kroky, které vedou z definovaného výchozího stavu k jeho vyvolání. Polopatismus není na škodu.
    • Navrhované opatření – volitelné pole, které tester vyplní, pokud se domnívá, že má rozumný návrh na odstranění chyby
    • Jméno testera – musí být vyplněno, aby programátor přidělený k odstranění problému věděl, na koho se má obrátit v případě nejasností.
    • Datum a čas realizace testu
    • Oblast pro programátora

    • Funkční oblast – podle dohody vývojového týmu je vhodné rozparcelovat systém na oblasti, které se dají snadno identifikovat
    • Přiřazeno – jméno vývojové skupiny, která má za úkol řešit problém
    • Komentáře – stručný komentář o tom, jak byl problém vyřešen nebo proč byl odložen. V elektronické verzi je v této oblasti veškerá komunikace o průběhu řešení chyby, včetně komentářů testerů, dokumentaristů, produktových manažerů apod.
    • Stav – každý problém začíná ve stavu Otevřený. Po vyřešení nebo po dohodě o tom, že problém již neexistuje přejde do stavu Uzavřený. V některých případech se zavádí stav Vyřešený, což je indikátor určený testerům a upozorňuje na to, že je systém v této oblasti nutné přetestovat.
    • Priorita – důležitost problému z hlediska projektového manažera. Škála priorit je závislá na dohodě v projektovém týmu, např.
      • 1. Vyřešit okamžitě (všechno ostatní stojí)
      • 2. Vyřešit co nejdřív
      • 3. Vyřešit před uzavřením dalšího milníku projektu
      • 4. Vyřešit před dokončením
      • 5. Vyřešit, pokud to okolnosti dovolí
      • 6. Vyřešit volitelně – podle možností řešitele
      Jenom projektový manažer má právo měnit prioritu a jenom vedoucí testů nebo tester samotný má právo měnit závažnost. Mají možnost nesouhlasit ohledně významnosti a často se to děje.
    • Řešení – definuje aktuální stav problému
      • Čeká – pokud se problém právě předkládá k řešení nebo pokud nové informace o problému jsou v rozporu s uvedeným statusem. Pokud programátor označí problém jako vyřešený a tester je schopen znovu demonstrovat chybu, tester Řešení do stavu Čeká. To je signál pro projektového manažera, že se má problémem znovu zabývat.
      • Vyřešeno – spolu s označením Vyřešeno programátor zaznamenává verzi, ve které je řešení hotové
      • Neopakovatelné – programátor není schopen podle popisu testera zreprodukovat chybu. Pokud se dostane problém zpět k testerovi, ten by měl ověřit, že je chyba reprodukovatelná, ev. přidat další kroky a vysvětlení tak, aby byl postup jednoznačnější. Potom dá problému stav Čeká a v komentářích uvede co doplnil.
      • Odsunuto – projektový manažer připouští chybu, ale rozhodl se ji neřešit v aktuálním release.
      • Podle návrhu – problém není chyba. Chování programu odpovídá zadání
      • Zrušeno testerem – pokud tester dojde k přesvědčení, že report neměl být napsán, může ho, jedině on sám, zrušit.
      • Nutné další informace – programátor má další otázky, ke kterým se tester musí vyjádřit
      • Nesouhlas s návrhem – nebudou se dělat žádné změny v návrhu podle doporučení
      • Duplikuje – existuje report, který už daný problém popisuje. Pokud se takto označí chyby, které jsou jen podobné a ne identické, může to být riskantní. Programátor odstraní jen část chyb. Vždy by mělo být uvedeno i to, s jako/jakými reporty je tento report identický.
    • Podpisy – volitelně v případě, že se pracuje s papírovou dokumentací.