A tesztadatok projektinformációvá alakításának művészete

Nemrégiben egy kolléga tolem kért segítséget, hogy jobb vizsgálati jelentést készítsen jelenlegi projektjéhez. Azt a feladatot kaptam, hogy gondolkodjak el azon, milyen eltéro módokon kezelik a QA menedzserek az azonos információkat; és hogyan különbözteti meg, hogy a projektinformációk kezeléséhez a tesztelo csapatnak van joga, vagy mehet a “közösbe”.

Mindannyiunknak feladata rendszeresen jelenteni a munkánk eredményeit, ez kvázi a projekt előrehaladási állapotának kommunikálása. Az általunk használt tesztkezelő eszközök sokszor automatikusan jelentéseket készítenek, és csak ezeket az alapértelmezett jelentéseket használjuk fel, majd szétküldjük azokat az érintetteknek, de ez egy nagy hiba.

Megtanultam, ha a tesztcsapatunkon kívüli emberekkel dolgozunk, akkor úgy kell gondolkodnunk, mint ők, meg kell értenünk, milyen információra van szükségük, és milyen formában tudjuk azt átadni gyorsabban és érhetőbben. Gyakran előfordul, hogy az alapértelmezett “száraz számokkal” összeállított jelentésekkel nem a megfelelő üzenetet kapják meg.

Íme két egyszerűsített példa a különböző jelentésekre:

Példa 1. Teszt végrehajtási jelentés

A-csapat jelentése: 
Összes teszt a ciklusban: 376 
Elfogadott tesztek: 301 
Sikertelen tesztek: 28 
Nem futtatott tesztek: 57 

B csapat jelentése: 
Ebben a körben futtatott tesztek: 376 
Végrehajtott tesztek aránya: 87,5% 
Elfogadott tesztek aránya: 80%

Minden a megfogalmazáson múlik

A fenti egyszerű példában mindkét csapat ugyanazokat az adatokat adja meg. De ki nyújt értékesebb információt? A jelentés írásakor ne feledje, hogy az emberek nem szeretnek algebrai egyenleteket fejben megoldani. Fontos tudni, hogy milyen információkat keresnek. Ebben az esetben azt szeretnék megérteni, hogy (a) mennyit haladt a tesztelési ciklusban a csapat -> Végrehajtott tesztek %, és (b) mi az alkalmazás státusza ezen a ponton -> Elfogadott tesztek %.

Példa 2. hibajelentés

A-csapat jelentése: 
Összes észlelt hiba: 453 
Zárt hibák: 321 
Nyitott hibák: 76 
Elhalasztott hibák: 56 
A Release összes hibája: 397 
(Elhalasztott hibák – 56) 

B csapat jelentése: 
Lezárt aránya: 80,8% 
Nyitott aránya: 19,2% 
Hibafelderítési sebesség (2 hét): 3,2 hiba/ nap 
Hibalezárás sebessége (2 hét): 5,2 hiba / nap

Itt mindkét csapat ismét ugyanazokat az adatokat szolgáltatja, de a „B” csapat értékesebb információkat is nyújt. Nem csak a számokat mutatja meg százalékosan, hanem a projekt konvergenciaszintjét is jelzi, mivel az elmúlt két hétben a rögzítési arány meghaladta az észlelési arányt.

Néhány hasznos tipp

Számos példa létezik, de a jelentések definiálásakor a következőket kell figyelembe venni:

• Minél kevesebb embernek kell gondolkodnia, annál használhatóbb lesz a jelentés az érdekeltek számára, ezért amennyire csak lehetséges az adatokat adja meg százalékban vagy egymáshoz arányosítva.

• Számítson kérdésekre és előzetesen adja meg az információkat. Ha az állapotfelmérések során az emberek mindig egy konkrét adatrészletre kíváncsiak, akkor azt hasznos bevonni a jelentésbe. Nem szabad felesleges adatokkal túlzsúfolni a jelentést, a túl sok információ megfojtja a fontos dolgokat.
• Ha grafikont használ számok helyett, 3-5x több információt tud átadni

Végül a legfontosabb tanács: a jelentésnek magáért kell beszélnie, minél kevesebb magyarázatra van szükség, annál jobb munkát végzett. 

Jelentések készítése

Javasolnám továbbá, hogy készítsen különböző vizuális adatokat és jelentéseket a projekt különböző érdekeltjeinek, mivel minden egyes érdekcsoportnak különböző elvárásai vannak a projekt minőségbiztosításával kapcsolatban. Például, a vezetőket jobban érdekelheti a teszteléshez szükséges idő és annak költségei, valamint az, hogy a projekt milyen értéket hozott létre, míg a HR számára fontosabb a csapat termelőképessége, a felhasználók pedig inkább arra kíváncsiak, hogy mikor jelenik meg a legfrissebb verzió.

Ma már számos tesztkezelő eszköz rendelkezik műszerfallal (dashboard) és / vagy jelentési (reporting) funkcióval, amelyek segítenek ezen feladatok megoldásában. Tehát nagyon könnyű jelentéseket összeállítani, és csupán az jelent majd nehézséget, hogy megtervezze, hogy milyen adatokat jelenítsen meg, kinek és hogyan hozza azokat létre.

A mutatók tervének létrehozásához ajánlom az alábbi e-bookot: HOW TO PLAN AND MAINTAIN A USEFUL METRICS PROGRAM

A PractiTest tesztmendzsment eszköz tartalmaz egy részletes jelentéskészítőt, ami képes élő irányítópultokat(dashboard) létrehozni külső alkalmazásokon belüli vezérlőpaneleken. (Fordító megjegyzése: A PractiTest fő tervezője a cikk szerzője.)

Ez lehetővé teszi a felhasználók számára, hogy ne csak egyszerűen létrehozhassák, hanem megoszthassák és beágyazhassák vizuális jelentéseiket bárki projektjével kapcsolatban, és nem csak a projekt csapat tagjai számára. Itt többet olvashat erről a funkcióról.

Forrás: http://qablog.practitest.com/the-art-of-transforming-testing-data-into-project-information/ 
Szerző: Joel Montvelisky