Správné použití a načasování test-reportů

(PR článek)

U mnoha projektů se z pohledu sledování testingu používají jenom dva základní typy reportů: sumární stav testů dané fáze/kola/cyklu/buildu/ a sumární stav defektů. A to je podle mě škoda. Že by jiné pohledy pro projekt nebyly potřebné? Pravý opak je pravdou. Navíc když se odborníci na takový projekt podívají zblízka, zjistí, že vlastně neznají jeho skutečný stav.

Proč?

Je to především z důvodu, že se nedívají na projekt z různých úhlů pohledů. Ztrácí se tím komplexnější pohled a možnost predikce, kterou takovéto pohledy umožňují. Obecně lze proto doporučit, abychom sledovali stav všech entit, které jsou pro daný projekt důležité. Z pohledu testování by měl být sledován a reportován stav především u těchto entit:

• požadavky
• testovací případy a jejich běhy
• testovací sady
• chyby/defekty/incidenty
• issues (identifikovaná rizika+problémy)
• release/buildy/…

Jenom tak získáme komplexní pohled na projekt a jeho stav.

Sledovat bychom ale neměli jen aktuální stav dané entity, ale také její časové změny tj. vývoj stavu. Kromě komplexního sumárního pohledu tak získáme také informaci o jeho vývoji v čase. A jedině vývoj nám umožňuje predikci do budoucna. Právě predikce je z pohledu vyspělosti řízení projektových a testovacích procesů prvním krůčkem ke změně z reaktivního módu chování na proaktivní. Správné a komplexní reportování je tedy součástí zvyšování vyspělosti projektových procesů. Umožňuje aktivně řídit celý projekt a případné nesnáze řešit v dostatečném předstihu nebo o nich alespoň včas informovat.

Řeknete si: pěkná teorie. Ale kdo a kdy má tyto reporty připravovat? Kdo je má vyhodnocovat a přijímat pak odpovídající opatření? Prostě: kde na to vzít zdroje a čas? Moje odpověď je: Jde o nesprávně položené otázky! Správný dotaz je: Jaké informace potřebujeme pro úspěšné a efektivní zvládnutí projektu? Když si tuto otázku zodpovíme, zjistíme, že zajištění zdrojů pro přípravu a analýzu reportů je vlastně součástí naší strategie. A na strategické aktivity (mezi které monitoring a reporting určitě patří), plánujeme zdroje už dopředu. Jenom měřený projekt může totiž být aktivně řízený.

Samozřejmě v rámci zvýšení efektivity monitorujeme a reportujeme jenom ty entity, které v dané fázi projektu mají smysl. Při řízení testů proto běžně používám přiloženou tabulku, kterou mám rozčleněnou do tří základních aktivit testingu (analýza, plánovaní a realizace testů).

Nejde o nic nového – je to seznam potřebných reportů z pohledu testingu. Tento seznam doporučuji použít jako výchozí rámec, který si můžete doplnit podle podmínek vašeho projektu. Může ho použít test manager pro nastavení plánu reportingu na daném projektu. S úspěchem ho ale může použít také projektový manager pro výběr entit, které chce v průběhu projektu sledovat.

Jaroslav Strharský, Quality Assurance and Testing, Ness Technologies

Chcete se dozvědět více o testování a dalších IT službách? Potřebujete snížit náklady na firemní informační technologie? Využijte služeb společnosti Ness Technologies!