Az egyik ügyfelünktől körülbelül másfél éve kaptunk megbízást arra, hogy az általuk bevezetés alatt álló SpiraTeam tesztmenedzsment eszközükre riportokat készítsünk. Az előzetes elképzeléseiket megküldték excel-formátumban is.

Teljesen észszerű riportigényekkel álltak elő, olyanokkal, amelyeken szívesen dolgozik a csapatunk, a megvalósításra szánt reporting eszköztől viszont nem voltunk elájulva. De az eszköz választásánál az ügyfél szempontjait is tökéletesen értettük, hiszen egy pilot-projektről volt szó, így ez volt számukra a legkézenfekvőbb (legköltséghatékonyabb) a meglévő licenceik mellett. Amennyiben viszont beválik és cégszerte megbarátkoznak az új fejlesztés kínálta lehetőségekkel, akkor még mindig lehet költeniük egy korszerű üzleti intelligencia szoftvercsomagra a lehetőségek jobb, szerteágazóbb és megjelenésében is nagyságrendekkel szebb kiaknázása végett, anélkül, hogy az addig elkészített reporting alapjai kárba vesznének.

A projekt indulásáig csapatunk csak hallomásból ismerte ezt a tesztmenedzsment eszközt, így természetesen az első dolgunk az volt, hogy elkezdtünk utánaolvasni a lehetőségeiről, használatáról, hogy az ügyféllel az első közös egyeztetésre egy kicsit már felkészültebben érkezzünk.

A SpiraTeam
A marylandi Inflectra által fejlesztett jól használható eszköz testreszabható belső riportokkal szolgál, jól paraméterezhető, és széles körűen képes támogatni a tesztelési folyamat összes érintettjét. Belső reportingja ugyanakkor csak nagyon alapszintű riportigényeket képes kiszolgálni, az általa szolgáltatott információk pedig néha félrevezetők lehetnek. A piacon ugyanakkor elérhető számos olyan eszköz, amik jóval több lehetőséget kínálnak, igaz a többletszolgáltatásért cserébe magasabb az áruk is.

Meglepődve vettük észre, hogy az eszköz rendelkezik belső riportokkal, melyek egész testreszabhatónak és tetszetősnek néztek ki, sőt, némelyik kimutatás alapvetően az ügyfél által megvalósítani kívánt vizualizációkat szolgáltatja. Így felmerült bennünk a kérdés: Miért akar az ügyfél olyan riportokat készíttetni, melyek már alapból elérhetőek a rendszerben?

Nos… a kérdésünkre igen hamar választ kaptunk: A Spira egy kétségkívül jól paraméterezhető eszköz és széles körűen tudja támogatni a tesztelési folyamat összes érintettjét és stádiumát, de belső reportingja csak nagyon alapvető riportigényeket tud kiszolgálni, továbbá a kimutatásokban megtalálható információk néha még félrevezetők is.

Mivel már volt tapasztalatunk más tesztmenedzsment eszközre épített reportinggal, így ezek alapján a félelmünk a projekttel kapcsolatban a Spira alatti adatbázis-struktúra volt, hiszen egy reporting-projekt esetében ezen nagyon sok múlik, többek között az is, hogy milyen arányban delegáljunk a projektre adatbázis illetve BI szakértőt.

A riportigények és reporting eszköz ismeretében azt az utat válaszottuk, hogy adatbázis-nézetekre és ütemezett tárolt eljárásokkal töltött, napi szintű hisztorikus adatokat tartalmazó táblákra építjük az ügyfél által elvárt vizualizációkat.

Egy projekten egy számunkra ismeretlen adatbázis struktúra feltérképezése, megértése még leírással is igen időigényes és bonyolult feladat, így nagy izgalommal vártuk az adatbázisos kollégával az első projekten töltött napot, amikor először szembesülhettünk vele.

A projekten töltött első pár nap célja az volt számunkra, hogy valamelyest átlássuk a rendszer adatbázis-struktúráját, próbáljuk feltérképezni a projekt szempontjából kritikus táblákat, nézeteket és a közöttük levő kapcsolatokat.

Ezzel szemben már az első nap (!) tudtunk egy riportkezdeményt mutatni az ügyfélnek, ami egyrészt az ügyfelet is megnyugtatta, hogy a projekt sikeres lehet, nekünk pedig olyan lendületet adott, ami egészen az élesítésig kitartott. Ez természetesen nem csak azért történhetett meg, mert értünk ahhoz, amit csinálunk, hanem azért, mert a Spira adatbázis-struktúrája az egyik legátláthatóbb, legegyértelműbb, amivel valaha is „dobozos termék” esetében találkoztunk. Teljesen tiszta tábla és mezőelnevezések, joinok valamint előre gyártott nézetek megkönnyítik az egyedi igények kivitelezését.

Az egyedi igényekből pedig volt bőven: Céges szintű projekt-áttekintő, Top X hiba, napi státuszváltozások, státuszokban eltöltött átlagos idők stb. stb. Ezek a fejlesztések pedig lehetővé tették, hogy olyan cégszintű standard kimutatásokat váltsunk ki, melyeket eddig kézzel-lábbal, fáradtságos és időigényes munkával gyűjtöttek össze excelekbe és készítettek PowerPoint prezentációkat. Így, hogy ma már pár kattintással előállnak a riportok, az ezáltal megspórolt időt „értelmesebb” tevékenységre lehet fordítani.

Természetesen az, hogy egy projekt sikeres legyen, nagyban függ a megrendelő elhivatottságától és szakértelmétől is és jelen esetben szerencsére ebben sem volt hiány: a felmerülő kérdéseket szinte azonnal tisztázni tudtunk, így a fejlesztés végig zökkenőmentesen zajlott

A projekt végül sikeresen zárult, és utána is érkeztek még riportigények, módosítások, finomítások, sőt, a cégen belül is kezd terjedni az „ige” és már az általunk gyártott riportokat tekintik a Spira hivatalos reportingjának.

Reméljük, hogy az „ige” elterjedésével egyre nagyobb igény (és ezzel párhuzamosan rá allokált budget) fog mutatkozni arra, hogy egy modernebb riportáló eszközzel minél jobban ki tudják és ki is akarják használni a lehetőségeket.

Gondolunk itt arra, hogy például egy szemantikus réteg bevezetésével (ez teremti meg az adatbázis és az üzleti réteg közötti kapcsolatot) egy adatbázishoz egyáltalán nem értő üzleti felhasználó önmaga, IT-s kolléga segítsége nélkül is képes lenne riportokat, vezetői dashboardokat létrehozni (önkiszolgáló BI), így külső segítséget csak a bonyolultabb igények megvalósításakor kellene igénybe venni. Ez a szemantikus réteg biztosítaná cégen belül az egységes fogalomtár bevezetését is, például, hogy az egyes riportokban a cég minden felhasználója ugyan azt értse a nyitott vagy éppen egy adott napon belül módosított incidensek számán.

Illetve annak megvalósítása sem okozna problémát, hogy minden projektvezető, tesztmenedzser bizonyos időközönként kapna egy e-mailt, ami kizárólag csak a saját projektjeiről adna kulcsfontosságú információkat pdf formátumban, illetve egy sor szintű adathozzáférési jogosultság bevezetésével megoldható lenne, hogy a webes reporting-portálon ugyanaz a riport az egyes felhasználóknak csak a saját projektjeikről mutasson információkat, ennek az az óriási előnye, hogy csak egy riportot kell karbantartani.

Összefoglalva tehát, hogy mit lehet kihozni a SpiraTeam reportingjából? Annak csak a riportáló eszköz képességei, a képzelet és a budget szab határt.