Artifact: Report o stavu testování |
| |
|
Dokument, který sumarizuje aktivity testování a jejich výsledky a který je vytvářen v pravidelných intervalech pro účely reportování průběhu testovacích aktivit ve srovnání s původním plánem testování [ISTQB, 2012c, s. 46]. |
Domains: Monitoring, reporting a řízení testování |
|
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
Proces testování je průběžně monitorován. Výsledky sledování a měření průběhu testovacích aktivit jsou pravidelně sumarizovány do reportu o stavu testování.
V terminologickém slovníku ISTQB je report o stavu testování, na rozdíl od standardu IEEE 829, nazýván jako report o průběhu testování (test progress report), ale jedná se o tentýž pracovní produkt. Report o průběhu testování je dle [ISTQB, 2012c, s. 46] slovníku definován jako dokument, který sumarizuje aktivity testování a jejich výsledky a který je vytvářen v pravidelných intervalech pro účely reportování průběhu testovacích aktivit ve srovnání s původním plánem testování.
Za vytváření průběžných neformálních reportů o stavu testování uvnitř testovacího týmu jsou zodpovědní testeři a test analytici, kteří dávají test manažerovi průběžná hlášení o aktuálním stavu testování na projektu. Test manažer poté hlášení dodaná členy testovacího týmu reviduje a sumarizuje do formálního reportu o stavu testování, který předává mimo testovací tým projektovému manažerovi a případně dalším na projektu zainteresovaným stranám.
Dle standardu IEEE 829 report o stavu testování zahrnuje informace, které zachycuje následující tabulka.
Položky reportu o stavu testování, zdroj: [IEEE, 2008, s. 63-64]
Položky reportu o stavu testování |
Popis |
Shrnutí stavu testování |
Shrnuje aktuální výsledky provedených testů ve srovnání s plánovanými testy a sumarizuje aktuální versus očekávaný stav defektů. |
Změny oproti plánům |
Souhrn testů, které měly být podle plánu provedeny, ale dosud provedeny nebyly, včetně důvodů, proč nemohly být provedeny. Dále jsou zde uvedeny informace o změnách ve zbylých testech, jako jsou změny v harmonogramu provádění testů, seznam testů, které již nebudou prováděny a seznam testů, které musí být provedeny opětovně. |
Stav metrik testování |
Poskytuje průběžný stav metrik, jejichž sledování je vyžadováno v plánu testování a popisuje všechny rozdíly aktuálních hodnot metrik proti deklarovaným cílům. |
Tato struktura je obecným rámcem pro představu, jaké informace by měl report o stavu testování obsahovat. Konkrétní informace zahrnuté do reportu o stavu testování závisí na informačních potřebách zainteresovaných stran, kterým je report dodáván. Pro projektového manažera budou pravděpodobně důležité detailní informace o defektech, kdežto pro byznys manažera budou důležitější informace o pokrytí produktových rizik.
Pro podporu vytváření reportů o stavu testování nabízí nástroj IBM Rational Quality Manager celou řadu předdefinovaných reportů. Je možné vygenerovat například seznam defektů na základě vybraných parametrů, trend vytváření a uzavírání defektů, přehled provedených testů a jejich výsledků, trend aktuálního průběhu testů proti plánovanému průběhu, aktuální pokrytí požadavků testovacími případy a další. Kromě přednastavených reportů je možné si také definovat vlastní šablony reportů a vytvářet tak reporty pro specifické potřeby projektu. [IBM, 2012] |
Tailoring
Impact of not having |
Pokud nejsou vytvářeny reporty o stavu testování, projektový manažer nemá žádný podklad pro
rozhodování a korektivní akce a je závislý na stanovisku test manažera. Bez reportů o stavu testování má test manažer
problémy při obhajování zpoždění testování oproti harmonogramu, protože členové projektového týmu neznalí testování
často nechápou důvody zpoždění testování a testovací tým je vnímán jako brzda projektu, i když vina nemusí být nutně na
straně testovacího týmu. Naopak pokud test manažer dodává informace o průběhu testování ve srozumitelné podobě, kde je
jasně vidět, proč testování neprobíhá podle plánu a kdo na tom nese svou vinu, projektový manažer se na základě
dodaných podkladů může rozhodnout, jak se bude postupovat dále a jestli je nutná např. redukce rozsahu testování nebo
zastavení testování a předání release aplikace zpět vývojovému týmu k opravám.
|
Reasons for not needing |
Reporty o stavu testování je třeba vytvářet vždy. |
Representation Options |
Forma reportu o stavu testování není striktně dána a závisí na potřebách na projektu
zainteresovaných stran a na specifikách projektu a organizace. Pro podporu vytváření reportů o stavu testování je vhodné
využít předdefinovaných reportů v IBM Rational Quality Manager, nebo si nadefinovat vlastní šablonu pro
report. |
|