SpiraTest – Teszteszköz sokrétű tudással

Spiratest. Ha valaki rákeres erre a névre az interneten, akkor elképzelhető, hogy egy alkoholkimutató indikátorcső termékre bukkan. Vagyis alkoholszondáról, annak tulajdonságáról és az áráról tájékozódhat. A cikk nem erről a termékről szól. 🙂

A Spiratest az Inflectra Inc. (http://www.inflectra.com) megvásárolható, web alapú tesztmenedzsment terméke. Az árát a “low-budget” kategóriába lehet sorolni. Körülbelül egy jól fizetett informatikus havi béréből megvásárolható, és ezt a díjat nem kell évente megismételni. A support (amennyiben szükséges) évente a vételi ár töredéke. Tesztmenedzsment eszközként a teljes tesztelési életciklust lefedi a tudása. Ha nagy költségvetésű hasonló termékkel mérjük össze, akkor természetesen alul marad, de van néhány figyelemreméltó tulajdonsága. 

A kipróbáláshoz letölthető egy 30 napig teljes értékűen használható verzió. Ehhez regisztrációra van szükség a honlapon, ahol a letöltés után adnak egy 30 napos licence-kódot. Ha nem akarunk a telepítéssel bajlódni, akkor arra is van mód, hogy az Inflectra oldalán „béreljünk” ingyenesen egy teljes értékű feltelepített SpiraTest-et 30 napig. Ebben adminisztrátorként úgy garázdálkodhatunk, ahogy akarunk. 

A cikk írásakor a 3.1.0.0 verziót nyűttem. Ebben a verzióban sok kényelmetlenséget megszüntettek az előző verziókhoz képest. A rendszert folyamatosan fejlesztik és a javításokat is azonnal kiadják.

Telepítés

Mivel a rendszer ASP alapú, így a telepítés Windows környezetben oldható meg. A telepítéshez szükségesek:

• MS Windows alapú webszerver (IIS)
• MS SQL szerver (az Express Edition kiadások is megfelelőek)
• Microsoft .NET Framework 4.0 (vagy nagyobb)
• Microsoft ASP.NET 4.0 (vagy nagyobb)
• Java Plug-in 1.6

Rendszerigényre minimum 2 GB memóriát írnak. Saját tapasztalatom, hogy ha már 5-10 fő használja párhuzamosan a programot (kliens oldalról), akkor a legalább 4 GB-ra van szükség a hatékony működéshez. (Komolyabb munkánál az SQL- és a webszervert nem egy rendszerre, hanem külön érdemes telepíteni.) 

A telepítés néhány kérdéses, next-next típusú. Nálam gond csak akkor adódott, ha nem volt megfelelő .Net környezet a gépen. Ilyenkor előfordult, hogy a feltelepítést meg kellett ismételni (egy “letelepítés” után).A telepítés végén a “http://hosztnév/SpiraTest” címről tudjuk indítani a programot:

• Az adminisztrátor felhasználó neve: “Administrator”,
• Jelszava első belépéskor: “PleaseChange“.

“Belakás”

A telepítés után az alkalmazást egy böngészőből tudjuk használni. A rendszerbe (a telepítéskor megadott jelszóval) adminisztrátorként tudunk belépni az első indítás alkalmával. Alapértelmezésben angolul szól hozzánk a rendszer. A magyarítás csak trükközéssel oldható meg, nem publikált módon kell több állományt is szerkeszteni. 

A beállításokhoz csak a megfelelő jogosultságú felhasználók férnek hozzá. Az összes beállítást az „Administration” menüpontból érjük el. 

Sok más eszközhöz hasonlóan ez is projekt alapú, azaz több projektet kezel párhuzamosan. Minden projekten külön-külön beállíthatóak a felhasználók, a jogosultságok, a munkafolyamatok (workflow). Lehetőség van a projekteket csoportokba foglalni és bizonyos szempontból ezeket együtt kezelni. Ennek a jogosultságoknál és a riportoknál van jelentősége. (Például a belső munkatársak látják a csoportba tartozó összes projektet együtt, a külső munkatársak csak azt az egy projektet, amihez rendelve vannak.) 

Első lépésként hozzunk létre egy projektet.

Projektek

Ha több projektünk van, akkor a beállítások mindig az aktuálisan kiválasztott projektre lesznek érvényesek. Az aktuális projektet a jobb felső sarokban látható legördülő lista aktuális eleme mutatja. (Hasonlóan más, projekt alapú rendszerekhez.)

Projektcsoportot az „Edit Project Groups” menüpontból tudunk létrehozni. Ha már hoztunk létre csoportot, akkor egyesével tudjuk a csoporthoz rendelni a projektjeinket („View / Edit Projects” / Edit). 

A felhasználókat a „Project Membership” menüpont alul tudjuk jogosultságcsoportonként a projekthez rendelni. A jogosultság csoportokat mi állíthatjuk össze, alapvető jogosultságok mátrixának a megadásával. Bármennyi jogosultságcsoportot készíthetünk (View / Edit Roles).

Projektenként beállíthatjuk a bejegyzéstípusokat és a priority, severity és status értékeket. A priority és severity értékekhez színeket is megadhatunk. A status értékek felsorolásánál arra kell vigyáznunk, hogy projektenként csak egy kezdő (default) státuszunk lehet, tehát nem lehet két különböző bejegyzéstípusnak más kezdő státusza. Az összes státuszt fel kell sorolni, amit a projektben valamilyen bejegyzéstípusnál alkalmazni akarunk. Minden státusznál meg kell adnunk, hogy lezárt vagy nyitott állapotról van-e szó. Lezárt állapotból több is lehet.

Munkafolyamat testre szabás

Több workflow-t készíthetünk. Akár minden bejegyzéstípushoz különbözőt. A bejegyzéstípusoknál tudjuk a típushoz a workflow-t rendelni („Edit Types”). 

A workflow-k meghatározása úgy történik, hogy

• minden állapotnál megadunk átmeneteket (Transitions), amik meghatározzák, melyik más állapotra van lehetőség onnan áttérni,
• minden állapotnál meghatározzuk, hogy milyen aktív és milyen kötelezően kitöltött mezőket lehet látni
• minden átmenetnél meghatározzuk,
  • hogy kinek van joga azt állítani (csak a jogosultak látják az átmenethez tartozó linkeket),
  • hogy ki kapjon értesítést az adott állapotváltozáshoz.

Levelezés

Bár a workflow-k tartalmazhatnak értesítést, de ezek csak a bejegyzésekre vonatkoznak. Különböző eseményekhez lehet értesítéseket rendelni megadott felhasználóknak, felhasználó csoportoknak („Notification Events”). Ezeknek az értesítőknek a formáját is testre szabhatjuk („Notification Templates”).

Saját mezők

Van lehetőség projektenként saját mezők definiálására, amik részt vesznek a szűrésekben és a riportokban. Jelenleg csak szöveges és lista típusú saját mezőket tudunk létrehozni korlátos számban („Edit Custom Properties”). A lista típusú mezőkhöz előbb listát kell készítenünk („Edit Custom Lists”). Bosszantó, hogy a saját mezők mindenhol csak külön fülön láthatóak. Így, ha például van egy „web böngésző” listánk, amit a hiba felvételekor kötelezővé teszünk, akkor aki felveszi a hibát, a képernyőn nem látja ezt a listát. Vagy ismeri már a rendszert és a külön fülre klikkelve kitölti ezt a mezőt is (nem kényelmes), vagy ha nem ismeri a rendszert, akkor a hiba mentésekor kap egy figyelmeztetést, hogy a kötelező mező nincs kitöltve és nem biztos, hogy megtalálja a listánkat.

Használat

A Spiratest felépítése azt az alapvető tesztelési szemléletet tükrözi, hogy 

• Követelményeket veszünk fel. (Planning/Requirements)
• Verziókat jelölünk ki. (Planning/Releases)
• Megírjuk a teszteseteket. (Testing/Test Cases)
• Tesztesetekből futtatásra kijelölt csomagokat állítunk össze, amiket a tesztelők futtatnak. (Testing/Test Sets)
• A futtatások eredményeit követhetjük, áttekinthetjük (Testing/Test Runs)
• Hibákat (és egyéb típusú bejegyzéseket) kezelünk. (Tracking/Incidents)
• A követelményekből, tesztesetekből, a futtatások eredményéről, a hibákról riportokat, elemzéseket, jelentéseket gyártunk. (Reporting)
• Mindezeket segíti két összefoglaló képernyő.
  • My Page: A felhasználóhoz köthető (tulajdonos vagy felelős) projektek, követelmények, tesztesetek, feladatok, bejegyzések listái
  • Projekt Home: Egy adott projekt táblázatos és grafikonos összefoglaló interaktív riportjai.

Mi mást várunk egy tesztmenedzsment eszköztől? 🙂 

Látható a fenti rövid összefoglalóból, hogy minden teszteléssel kapcsolatos tevékenységet támogat a rendszer. Egy ilyen rendszer ereje azonban nem abban rejlik, hogy ezeket a részfeladatokat képes támogatni (ezt alapnak gondolom), hanem egyrészt ezek a funkciók mennyire könnyen, hatékonyan használhatók, másrészt, hogy ezek között a feladatok között milyen kapcsolatokat képes teremteni. Minden tesztelésben részt vevő tudja, hogy a tesztesetek a követelményekhez kapcsolódnak (és viszont), hogy a hibák teszteset futtatásokhoz kapcsolhatók (és viszont). A funkciók részletesebb leírásában ezekre a kapcsolatokra, illetve a megvalósításukra is ki fogok térni.

Szerző: Szőke Ármin