RTH – Követelménykezelő és Teszt Központ

Az RTH (Requirements and Testing Hub) egy nyílt forráskódú tesztmenedzsment eszköz követelménymenedzsment és hibakezelő képességekkel ellátva. Az alkalmazás használata rendkívül egyszerű, a jól strukturált oldalain könnyű eligazodni.

Az eredeti eszköz fejlesztését 2006-ban fejezte be 2 német programozó. 2007-ben vették át mások az 1.6.0-ás verzióig jutott alkalmazás fejlesztését, ami napjainkban az 1.7.2-es változatnál tart, és a SourceForge projekt oldaláról tölthető le (http://sourceforge.net/projects/rth/). Az ingyenesen használható webalapú eszköz PHP, és MySQL technológiákra épül.

Tudni kell, hogy az alkalmazást jelenleg egyetlen ember fejleszti a munkája mellett. Szóval amikor ideje van törődni a lejelentett hibákkal, akkor tudja továbbfejleszteni a programot. Így érthető, hogy nem túl intenzív az új verziók kiadása. A legújabb 1.7.2-es verzió 2009 áprilisától érhető el. Azóta nem nagyon történt a szoftverben változás.

Régóta használok RTH-t a kisebb projektjeimen. A bevált verzió az 1.7.0-ás amit lassacskán 3 éve üzemeltetünk folyamatosan mindenféle hiba nélkül.

Installálás

Maga a telepítés nem okozott nagy problémát. Kövessük a rth\docs könyvtár INSTALL állományában leírtakat. A letöltött zip-et ki kell csomagolni, a fájlokat be kell másolni a webszerver dokumentum könyvtárába, létre kell hozni a MySql adatbázist, majd benne a táblákat, amelyhez használhatóak az \rth\sql mappában található szkriptek. Az API könyvtárban található properties_inc.php fájlt konfiguráljuk be, majd érdemes a DEMO sql-t lefuttatni, és a DEMO projekt könyvtárait bemásolni a megadott helyre. Gyakorlatilag az installálás itt ki is merült. Ha netán valamilyen hiba lépne fel a telepítés közben, akkor az INSTALL fájl végén leírtak, vagy az interneten fellelhető tudásanyag segítségünkre lehet. A sikeres installálás után jöhet az eszköz konfigurációja.

Konfigurálás

Lépjünk be adminként (admin/password) a felületre. Az RTH nem rendelkezik teljesen különálló admin felülettel, így adminként nemcsak az adminisztrációhoz szükséges menüket láthatjuk, hanem elérhető lesz minden funkció. Az adminisztráció szemszögéből két menüpont érdekes számunkra. Az első a Felhasználók (User) menüpont, azon belül is az Új felhasználó (Add new user) funkció. Itt tudjuk az új felhasználó adatait megadni, egyben a jogosultságát és a projektekhez való hozzáférését is rögzíteni. Minden egyes felhasználóhoz egy alapértelmezett projektet állíthatunk be, hogy bejelentkezés után ezen projekt adatait lássa. Ezt az alapértelmezett projektet maga a felhasználó is be tudja állítani. Az Új felhasználó képernyőn két eszköz hiányosság is kiderül:

• Jogosultsági rendszer nem teljesen kiforrott, mivel kizárólag 3 felhasználói csoportot támogat. (user, developer, manager)
• Minden projektben ugyanazzal a jogkörrel rendelkeznek a felhasználók.

Egyébként a felhasználók adminisztrálását rémisztően egyszerűen, és mindössze két képernyőn oldották meg. Az Összes felhasználó (All users) képernyőn törölhetjük vagy módosíthatjuk a felhasználók hozzáférését. Nemcsak az admin, hanem a manager is tudja a felhasználó adatait szerkeszteni, de új felhasználót csak az admin hozhat létre.

Térjünk át a menedzselés másik oldalára, a projektek karbantartására. Ennek a kidolgozása is elég egyszerűre sikeredett. Gyakorlatilag az Új projekt (Add project) menüpontban tudunk projektet létrehozni, kizárólag a nevének megadásával. Itt csak annyira kell figyelnünk, hogy a megfelelő projektkönyvtárhoz a fájl rendszerben írási jogunk legyen, mivel ilyenkor hozza létre a könyvtár struktúráját. Egy másik fülön pedig az eddig felvett projekteket tudjuk módosítani és törölni.

Használat

Az alkalmazás használata rendkívül egyszerű, a jól strukturált oldalain könnyű eligazodni. Egy böngészőben egyszerre egy felhasználó lehet bejelentkezve az alkalmazásba, mivel nincs különválasztva a session kezelés egy browser-en belül, így ha belépünk egy új felhasználóval egy másik fülön, akkor a belépő session-je jelenik meg a régebbi felhasználónál is. Különböző böngészőkből vagy IP-címről való bejelentkezések viszont nem keverednek össze.

A Követelmények (Requirements) modulban teszteket, release-eket vagy más követelményeket köthetünk az eddig felvett követelményeinkhez. A feltöltött követelmények verzió követéssel ellátottak, menti a rendszer az időpontot és a feltöltőt. (célmappa: \rth\rth_file_upload\XXX_req_docs\) A nyomonkövethetőségi mátrix (Traceability Matrix) segít kideríteni, hogy mely tesztek mely követelményeket fedik le. Elég sok funkcionalitást próbáltak belefejleszteni a modulba, de nem mindegyik működik tökéletesen. Pl.: Megtehetjük, hogy két követelmény egymás alá és felé rendeltje legyen egyszerre. Ekkor a könyvtár nézetben (Folder view) nem lesznek láthatóak ezek a követelmények. Így egy rossz mozdulattal egy egész fát láthatatlanná tudunk tenni ebben a nézetben. Ha meg akarjuk ezt szüntetni és a kettő közül az egyik követelményt kitöröljük, akkor sem fog minden kapcsolat eltűnni. Kénytelenek leszünk mindkét követelményt törölni a rendszerből, majd ismét létrehozni őket a megfelelő alá-fölé rendelési viszonnyal.

Teszteseteket létre tudunk hozni akár excel-fájlból, akár manuálisan. A létrehozás végtelenül egyszerű. A rögzített teszteseteinkhez megadhatjuk azok lépéseit, input adatait, valamint az elvárt eredményt is. Különböző követelményeket és dokumentumokat tudunk hozzácsatolni magához a tesztesethez. Megadható automatizált teszteset is (QTP és LoadRunner-eseteket említ a leírása), de ezt még a gyakorlatban nem próbáltam ki. A teszteset törlése után az esetleges korábbi Release-információk konzisztenciájának megőrzése érdekében nem tűnnek el a törölt teszteset adatai az adatbázisból. Az alkalmazás egy bizonyos projektméret felett már kényelmetlenné kezd válni. Száz feletti követelmény, teszteset vagy hibabejegyzés után számomra kicsit nehézkesé vált az átláthatósága és a használata.

A teszteket tesztkörökbe szervezhetjük. Minden tesztkör valamilyen release-hez és build-hez fog kapcsolódni. A Release és build elemekről, valamint a tesztkörökről elég a nevüket megadni, más adatot nem is nagyon tudunk rögzíteni. Lehetőségünk van rá, hogy tesztköröket másoljunk egyik Build-ből a másikba. A törlésnél járjunk el figyelmesen, mivel a Release eltávolításával a hozzá tartozó összes hivatkozás törlődik (Bulid-ek, Tesztkörök, dokumentumok). Személy szerint a Release modulban fontos funkciónak tartanék egy könyvtárnézetet, mivel így az egyes tesztköröket vadászni kell, melyik Release melyik Build-jében található.

Ugyanez a helyzet a Tesztfuttatások (Test Results) modulban is, nem túl komfortos a használata. A modulban gyakorlatilag mindenki mindenre jogosult. A megfelelő tesztkör kiválasztása után (Release -> Build -> Tesztkör) futtathatjuk a teszteseteket, és figyelemmel követhetjük a változásokat. A modulban monitorozni lehetne a futtatási eredményeket, de a kidolgozatlansága miatt számomra kényelmetlen volt használni.

Hibakezelés (Defects) rész három képernyőből áll. Az egyiken a felvett hibák listáját látjuk, a másikon új hibákat tudunk felvenni, míg a harmadik képernyő a rögzített hibák módosítására szolgál. A hibák listájában mindenki mindent láthat, ha hozzáférése van az adott projekthez. Ezt a kódban való turkálással és néhány sor módosításával meg lehet szüntetni. Alapból kizárólag a hibajegy törlése van jogosultsághoz kötve, sem a nézetre, sem pediglen a hibák módosításásra nincs szabály. A kiválasztott hibát bárki szerkesztheti. Sajnos nincs lehetőség workflow állítására, így bárki bármilyen státuszba állíthatja az adott hibát. A hibajegyek munkafolyamatainak kódolása kicsivel bonyolultabb feladat. Kisebb projektnél kevés résztvevővel nem feltétlenül szükséges a workflow precíz beállítása, viszont több résztvevő esetén luxus lenne ezt a megszorítást elhagyni.

A Riportok modulban mindenki megtekintheti az alábbi információkat a projektről:

• Tesztterületek
• Build státuszok
• Hibásan lefutott tesztlépések
• Követelménylefedettség
• Tesztesetek státuszinformációi
• Tesztkörök információi

Néhány helyen találunk grafikus megjelenítést is az adatokhoz. Általában igaz a tesztmenedzsment eszközökre, hogy a riportolási funkciók elnagyoltak. Nem mindig a megfelelő formában lehet adatokat kinyerni a rendszerből, és természetesen, amilyen riport kellene nekünk, pont az nincs beleépítve az alkalmazásba. Így aztán marad az excel-be való exportálás, és ezután ott állítjuk össze a szükséges riportot, grafikont.

Érdemes még megemlíteni a Szűrés/keresés funkciót. Nagyon sok problémát meg lehet szüntetni, ha a munkánkat azzal kezdjük, hogy beállítjuk a szűrő feltételeket. Pl.: alapértelmezés szerint a Hibakezelés részben nem mutatja a lezárt hibákat. Jó lenne egy Szűrőfeltételek törlése gomb a felületen, mert sok kattintástól megkímélné a felhasználót. Egyébként magát a szűrést, keresést és a találati lista rendezését nagyon jól lehet használni. A találati listás oldalak alján van egy csoportos műveleti rész, ahol a kijelölt elemek csoportján végrehajthatjuk ugyanazt a műveletet, mint például státuszok állítása vagy a hibák különböző felhasználókhoz való rendelése.

A nyelvi fájlok segítségével testre szabhatjuk rendszerünket. Alapszinten két nyelvet támogat az alkalmazás: az angolt és a franciát. (rth\lang\strings_english.txt; rth\lang\strings_french.txt). Ez a nyelvi fájl tartalmaz szinte minden olyan szöveget, ami a felületen megjelenik. A fájl szerkesztésével magyarosíthatjuk a rendszert. Átírhatunk bármit az adott szekcióban a hozzájuk kapcsolódó attribútumok közül. Például a hibák tulajdonságainál található Severity mezőnevet változtassuk Súlyosság névre és cseréljük le a Criticalértéket.## 
#SECTION 7: Bugs – words that are related to defects 
## 
… 
$l_bug_severity = ‘Súlyosság’; 
… 
… 
$l_severity_critical = ‘Kritikus’; 
…

A prioritásnál a Medium értéket Közepesre változtathatjuk:## 
#SECTION 1: Common – words common throughout the application or used on many pages 
## 
… 
# PRIORITY 
… 
$l_priority_medium = ‘Közepes’; 
… 
Vannak azért kivételek. Például a tesztesetek státuszértékeit csak a test_api.php -ben módosíthatjuk a test_get_status függvény tömbértékeinek megváltoztatásával.

Összegzés

Ha mérlegelni kell, hogy mi használható és mi nem az alkalmazásban, akkor elsősorban a következetes linkkezelést és egyszerű navigációt említeném meg, mint pozitívum. A modulok megfelelően vannak összekapcsolva egymással, és egy kisebb projektet a követelményektől kezdve a tesztesetek, tesztkörök, tesztfuttatásokon keresztül egészen a hibakezelésig adminisztrálni tudunk mindenféle extrém nehézség nélkül. Az installálás egyszerű, és az adminisztrálás sem igényel sok tapasztalatot. Én akkor használom a rendszert, amikor nagyon gyorsan (gyakorlatilag azonnal) valamilyen ingyenes megoldásra van szükségem. Olyan projektekre használom, ahol 2-3 ember dolgozik elég szorosan együttműködve. Egyértelműen kizáró tényező, ha a megrendelő is látni szeretné a hibákat, vagy használnia kell a hibakezelő modult. Egyébként a hibakezelő része nagyszerűen használható, csak a jogosultsági rendszer kidolgozatlansága miatt kaphat negatív pontot. A modul mindenféle sallang nélkül kizárólag a funkcionalitásra koncentrál. Ez a rész a legjobban kidolgozott, gyanítom, sokan kizárólag ezt használják az alkalmazásból.

Az eszköz hiányosságai közül az alábbi negatívumokat kell megemlíteni:

• Szűrésben lehetne pár funkcióval könnyíteni a munkát. Pl.: Reset gomb az összes adat törlésére, saját szűrések mentése, stb.
• A beviteli képernyőkön lévő mezők elrendezésével kényelmesebbé és átláthatóbbá válnának ezek a felületek is.
• Jogosultsági rendszer finomításával többszereplős projektekben is nagyszerűen lehetne alkalmazni.
• Nincsen állítható workflow a rendszerben. Ez, és a jogosultsági rendszer a legnagyobb hátránya. Ezek miatt nem ajánlatos nagyobb projektekben használni.
• A rendszerben sok a funkcionális hiba. (Habár ezekkel mindegyikkel együtt lehet élni, de figyelmesen, körültekintően kell néhány modult kezelni.) 

Értékelés (1-5)

• Telepítés: 5
• Testre szabhatóság: 1
• Használhatóság: 4
• Design: 4
• Összkép: 3

Szerző: Pongrácz János