Master Test Plan. Demonstrátori Órarend. Készítették: Birkás Tamás Ficand Tamás Kicsi András Pintér Krisztián

Átírás

1 Master Test Plan Demonstrátori Órarend Készítették: Birkás Tamás Ficand Tamás Kicsi András Pintér Krisztián Szegedi Tudományegyetem, Teszt Menedzsment Kurzus 2016

2 Tartalom Contents Tartalom... 2 Identifier... 3 References... 3 Introduction... 3 Test items (functions)... 3 Smoke teszt... 3 Prototípus vagy modul teszt... 3 Integrációs teszt... 4 Terheléses teszt... 4 Biztonsági teszt... 4 Software Risk Issues... 6 Features to be Tested... 7 Features not to be Tested Approach (Strategy) Item Pass/Fail Criteria Suspension Criteria and Resumption Requirements Test Deliverables Remaining Test Tasks Environmental Needs Staffing and Training needs Responsibilities Schedule Planning Risks and Contingencies

3 Identifier A teszt tervet a TMNT (Test Management Ninja Team) készítette, az IEEE 829 szabvány alapján. A teszt terv azonosítója: TMNT DemOr Kommunikáció és kapcsolatfelvétel a teszteléssel kapcsolatban a következő egyénekkel lehetséges: Birkás Tamás ( tamas.birkas1993@gmail.com ) Ficand Tamás ( ficandtamas92@gmail.com ) Kicsi András ( kicsiandras92@gmail.com ) Pintér Krisztián ( krile2822@gmail.com ) References A tesztelési terv elkészítéséhez egy olyan dokumentumot használtunk fel, amely részletesen taglalja a szoftever követelmenyeit. A specifikáció a Demonstrátori Órarend elkészítésére hivatott, valamint a szoftverben történő különböző interakciók és műveletek lebonyolításának helyes elvégzését írja le. A szoftver követelményspecifikációja a következő helyen érhető el: Req.pdf Az IEEE 829-es szabvány: Introduction Célunk a Demonstrátori Órarend -et megvalósító szoftver tesztelése. A szoftverben regisztrációk rögzíthetők, módosíthatók, törölhetők. Ugyanakkor demonstrátorok jelentkezhetnek a különböző kurzusok megtartására, elfogadhatnak kurzusokat, de el is utasíthatják azokat. Csapatunk a főbb követelmények, funkciók tesztelését végzi, ami a lehető legszélesebb körben garantálja a szoftver kiváló minőségű működését. Ezen feladat elvégzéséhez szükség volt a már fent említett specifikáló dokumentum alapos áttekintésére és értelmezésére, majd ezt alapul véve a legjobb tesztelési terv összeállítására. Test items (functions) Ebben a fejezetben bemutatjuk az általunk használt tesztelések típusait, tulajdonságait és funkcióit. A tesztek rövid ismertetése után, látható, hogy a különböző moduloknál mi az amit felhasználtunk és mi az amit nem. Smoke teszt Egy gyors teszt, annak érdekében, hogy megbizonyosodjunk arról, hogy minden rendben van. Ezután következhetnek a funkcionális és rendszer integrációs tesztek. Prototípus vagy modul teszt A prototípustesztelés (vagy másik nevén modultesztelés) célja a rendszer már működő moduljainak önálló tesztelése, a modulon belüli hibák azonosításának és kiküszöbölésének érdekében. 3

4 Funkcionális teszt Célja a rendszer teljes funkcionalitásának vizsgálata Integrációs teszt Az integrációs teszt célja a rendszer más rendszerekhez történő illesztésének vizsgálata, a több rendszereken keresztül átívelő funkciók tesztelésének érdekében. Az adatmigrációs tesztelés az integrációs teszteléshez tartozik, ennek lényege, hogy a bevezetendő rendszerbe áttöltik azokat az adatokat, amelyekkel a rendszer dolgozni fog és letesztelik a betöltött adatok, illetve az adatokat kezelő funkciók helyességét. Terheléses teszt A terheléses teszt célja a tervezett kapacitások, valamint a rendelkezésre álló növekedési potenciál meghatározása. Biztonsági teszt Biztonsági tesztelésre akkor van szükség, ha a rendszer szenzitív (pl. személyes vagy pénzügyi) adatokat kezel, vagy szabadon elérhető az internetről. Most pedig következzenek az általunk használtak a következő modulokon: 1. Demonstrátorjelölt regisztrációja: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Rendszer intergrációs teszt 2. Oktatók regisztrációja: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Rendszer intergrációs teszt 3. Rendszeradminok regisztrációja: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Rendszer intergrációs teszt 4. Felhasználók belépése: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Terhelés teszt Performancia teszt 4

5 5. Felhasználó adatainak módosítása: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 6. Felhasználók törlése a rendszerből: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Performancia teszt 7. Kurzusok aktiválása: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 8. Kurzusok inaktiválása: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 9. Demonstrátorok kiválasztása: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 10. Demonstrátorok jelentkezése kurzusok megtartására: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 11. Demonstrátorok kijelölése kurzushoz: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 5

6 12. Kijelölés nyugtázása: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 13. Riportírás: Smoke teszt Biztonsági teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 14. Teljességigazolás: Smoke teszt Biztonság teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt 15. Órarend lekérdezése: Smoke teszt Modul teszt Funkcionális teszt Performancia teszt Rendszer intergrációs teszt A különböző modulok tesztelése után elfogadási teszt végzése (User Acceptance Test). Ezzel megbizonyosodhatunk arról, hogy minden a funcionalitásának megfelelően működik a felhasználók szemszögéből is. Software Risk Issues A következőkben a rendszer használata során előforduló kockázatokat, és azok kezelését ismertetjük. A tesztelt Demonstrátori Órarend nyilvántartó rendszer nagyban támaszkodik az egyetem ETR rendszerétől kapott adatokra, és nagy hangsúlyt fektet az ETR-rel való integrált működésre. Ezért magas kockázatot jelentenének az ETR rendszeren történő változtatások. Ez költséges módosításokhoz vezetne. Az ETR szolgáltatásainak esetleges teljes meghibásodása, vagy az ETR esetleges másik rendszerre történő cseréje pedig a teljes tesztelt rendszer működését is ellehetetlenítené. Ebben az esetben azonnali leállás történne a rendszer működésében, amely fennálna a hiba kijavításának, vagy az új nyilvántartó rendszerrel történő integráció befejezésének időpontjáig. Ez kivételesen költséges, és körülményes problémákat vetne fel. Ennek elkerülése érdekében az egyetemmel és az ETR karbantartóival folyamatos kapcsolatban állunk, és aktualizáljuk ismereinket az esetleges változtatásokról. 6

7 A biztonsági kockázatoknál figyelembe kell vennünk, hogy a teljes egyetem adatait nyilvántartó rendszerrel is együtt dolgozunk. Mivel az ETR-től kapjuk az adatokat, az ott nem nyilvános adatokat a Demonstrátori Órarend rendszernek is bizalmasan kell kezelnie. Mivel ETR azonosítóval tudnak a felhasználók bejelentkezni, ezért a rendszer potenciális bejáratot jelenthet az esetleges negatív szándékú behatolók számára. Az ebből eredő biztonsági kockázatok kritikusak. Ezért törekszünk a rendszer minden biztonsági igényének kielégítésére. Szoros együttműködést alakítunk ki az ETR rendszer karbantartóival annak érdekében, hogy a bizalmas kódokat és jelszavakat ugyanolyan biztonságos körülmények között tudjuk kezelni, mint ahogy azt az ETR is teszi. A megfelelő biztonság kialakítása érdekében külső segítséget is igénybe veszünk, melynek során biztonsági szakemberek próbálnak behatolni a rendszerbe. Ezzel feltárhatjuk az esetleges biztonsági réseket, hátsó ajtókat, és egyéb információszivárgást elősegítő körülményeket. Törekszünk ezek mielőbbi kijavítására, a vszélyeztetett modulok cseréjére, és a szakértők bevonásával a lehető legbiztonságosabb rendszer kialakítására. Az ETR rendszerrel való integráció során is felléphetnek problémák. Ezeket továbbra is az ETR karbantartóinak bevonásával igyekszünk megoldani. Az ETR rendszer igen komplex, ami megnehezíti a hozzá való alkalmazkodást. A használat során nem védhető ki minden egyes emberi tényező. Ha az oktató nem megfelelően jelöli ki a határidőt, vagy a demonstrátorjelölt nem megfelelő kurzust jelöl ki magának, illetve ha az oktató tévesen választ ki egy demonstrátorjelöltet, azért a Demonstrátori Órarend rendszer nem tud felelősséget vállalni. Az ilyen hibák súlyossága változó lehet. Ezen hibák elkerülése érdekében jól átlátható, és felhasználóbarát felületet biztosítunk, és közérthető leírásokkal látjuk el felületet, ezzel elősegítve az áttekinthetőbb és helyesebb munkát a rendszeren. Továbbá azt is biztosítjuk, hogy az egyes oktatók és demonstrátorjelöltek csak a nekik szóló beállításokhoz férjenek hozzá, ezzel megakadályozva, hogy az emberi tévedésből előforduló hibák átterjedjenek a Demonstrátori Órarend, vagy az ETR más részeire is. Ezen kívül a rendszer az ETR azonosító alapján folyamatos nyilvántartást vezet a felhasználók módosításairól, mely hiba során hasznos lehet a hiba javítása és a felelősségrevonás kérdésében is. A követelményspecifikációban történt esetleges félreértések, vagy hibák nem feltétlenül tesztelhetőek. Ezek elkerülése érdekében igyekszünk a felhasználók véleményezésére támaszkodva kialakítani a Demonstrátori Órarend végleges állapotát. Külön hangsúlyt fektetünk a szoftver korábban már problémás területeinek vizsgálatára, ugyanis a hibák általában csoportosan fordulnak elő, és a Unit tesztek során sok hibát eredményező területekről a legvalószínűbb a további hibák felmerülése, még akkor is, ha a terület már egyszer teljes hibamentesítésen esett át. Features to be Tested A következőkben a Demonstrátori Órarend csapatunk által tesztelt funkcióinak megadása következik, az adott funkciókhoz előzetesen értékelt kockázat mértékével együtt: DEMONSTRÁTORJELÖLT REGISZTRÁCIÓJA Kockázat: Közepes 7

8 A regisztráció sikerességének ellenőrzése, és különböző tesztesetek megadása ennek vizsgálatára. A regisztráció dokumentálásának és érvényességének, a tanszék általi elérhetőségének tesztelése. Az automatikus visszajelzés helyes működésének vizsgálata. Az automatikus visszajelzés és naplózás ellenőrzése. OKTATÓK REGISZTRÁCIÓJA Kockázat: Magas Az oktató ETR rendszerből kapott adatainak megfelelő betöltésének, és az oktató felhasználói fiókjának aktiválásával kapcsolatos funkciók ellenőrzése. Biztonsági kockázatok kezelése. A regisztráció dokumentálásának és érvényességének, a tanszék általi elérhetőségének tesztelése. Az automatikus visszajelzés helyes működésének vizsgálata. Az automatikus visszajelzés és naplózás ellenőrzése. RENDSZERADMINOK REGISZTRÁCIÓJA Kockázat: Magas A rendszeradminisztrátor regisztrációs folyamatának tesztelése, a rendszeradminisztrátor integritására vonatkozó kockázatok kezelése. Annak biztosítása, hogy illetéktelen személy ne regisztrálhasson a rendszerbe rendszeradminisztrátorként. A regisztráció dokumentálásának és érvényességének, a tanszék általi elérhetőségének tesztelése. Az automatikus visszajelzés helyes működésének vizsgálata. Az automatikus visszajelzés és naplózás ellenőrzése. FELHASZNÁLÓK BELÉPÉSE Kockázat: Magas A különböző felhasználók beléptetésére használatos modul tesztelése. Annak ellenőrzése, hogy a felhasználó valóban csak a neki előrelátott funkciókat érhsse el, és nem regisztrált felhasználó ne léphessen be a rendszerbe. Mivel ez a modul is bizalmas adatokkal dolgozik, a biztonsági kockázatok kezelése, a szoftver a bejelentkező felületen történő esetleges rosszindulatú támadások szimulálása. Az automatikus visszajelzés és naplózás ellenőrzése. REGISZTRÁCIÓ ADATAINAK MÓDOSÍTÁSA Kockázat: Alacsony A már regisztrációkor megadott adatok módosítását célzó modul vizsgálata. Annak biztosítása, hogy a felhasználó a saját fiókjával már belépve tudja csak elérni ezt a funkciót. A jelszó megváltoztatásához a jelszó újbóli bekérése. Annak ellenőrzése, hogy a módosítás megfelelően megtörtént-e, felhasználói hiba esetén pedig a felhasználó kapott-e megfelelő hibaüzenetet. Az automatikus visszajelzés és naplózás ellenőrzése. FELHASZNÁLÓK INAKTIVÁLÁSA Kockázat: Alacsony Annak biztosítása, hogy ezt a funkciót valóban csak rendszeradminisztrátor érje el. Az archiválás folyamatának ellenőrzése, az archivált fiókok visszaállíthatóságának tesztelése. Az archivált adatok biztonságos tárolása. Az archivált fiókkal rendelkező felhasználónévvel ne lehessen belépni a rendszerbe. Az automatikus visszajelzés és naplózás ellenőrzése. KURZUSOK AKTIVÁLÁSA Kockázat: Közepes Annak biztosítása, hogy ezt a funkciót valóban csak rendszeradminisztrátor érje el. A funkció az ETR rendszerből kapott adatokkal dolgozik. Annak ellenőrzése, hogy a kurzus adatai valóban megjelennek-e az illetékes felhasználók felületén, illetve csak a jogosult felhasználók által láthatóak. Az automatikus visszajelzés és naplózás ellenőrzése. 8

9 KURZUSOK INAKTIVÁLÁSA Kockázat: Alacsony Annak biztosítása, hogy ezt a funkciót valóban csak rendszeradminisztrátor és a jogosult oktató érje el. Annak ellenőrizze, hogy a kiválasztott felhasználók számára valóban elérhetetlenné, vált a kurzusra való jelentkezés. Ennek visszaállíthatóságának ellenőrzése. Már esetlegesen a kurzusra jelentkezett demonstrátorjelölt levétele a kurzusról, erről automatikus üzenet küldése az érintett felhasználónak. Az automatikus visszajelzés és naplózás ellenőrzése. DEMONSTRÁTOROK KIVÁLASZTÁSA (PÁLYÁZAT ELBÍRÁLÁSA) Kockázat: Alacsony Annak ellenőrzése, hogy a felületet csak az illetékes oktatók érik-e el, hogy a kijelölt demonstrátorjelöltek státusza valóban megváltozik-e, és csak a kijelölteké változik meg, valamint, hogy a megfelelő státusz jelenik meg a demonstrátor felületén. Az automatikus visszajelzés és naplózás ellenőrzése. DEMONSTRÁTOROK JELENTKEZÉSE KURZUSOK MEGTARTÁSÁRA Kockázat: Közepes Annak elősegítése, hogy a felület kitöltése a demonstrátorjelöltek számára legyen elérhető. A választás folyamatának ellenőrzése, a részleges és teljes óraszám választás működésének tesztelése, és a választások helyes elmentése, későbbi betölthetősége, és a tanszék, valamint az oktatók általi láthatóságának biztosítása. Az automatikus visszajelzés és naplózás ellenőrzése. DEMONSTRÁTOROK KIJELÖLÉSE KURZUSOK (TANÓRÁK) MEGTARTÁSÁRA Kockázat: Közepes Annak biztosítása, hogy ezt a funkciót valóban csak az adott kurzushoz kijelölt oktató érhesse el. A ténylegesen a kurzusra jelentkezett demonstrátorjelöltek listázásának, a közülük történő egy vagy több személy kiválasztásának, ennek mentésének tesztelése. A kijelölt személyek listájának későbbi elérhetősége, és módosíthatósága. Üzenet küldése a kijelölt demonstrtorjelölteknek. Az automatikus visszajelzés és naplózás ellenőrzése. KIJELÖLÉS NYUGTÁZÁSA Kockázat: Közepes Annak biztosítása, hogy ezt a funkciót valóban olyan demonstrátorjelölt tudja elérni, aki jelentkezett az adott kurzusra, és az oktató valóban kijelölte már korábban. A nyugtázás elmentésének tesztelése. Az automatikus visszajelzés és naplózás ellenőrzése. RIPORTÍRÁS Kockázat: Közepes A riportálás folyamatának ellenőrzése. Annak biztosítása, hogy ezt a funkciót a kurzusra már kijelölt demonstrátorok tudják elérni. A riport adatbázisba való mentésének, az automatikus teljesítésigazolás helyességének, és a kitöltött riport oktatóhoz való tényleges eljutásának tesztelése. Az automatikus visszajelzés és naplózás ellenőrzése. TELJESÍTÉSIGAZOLÁS Kockázat: Közepes Annak biztosítása, hogy ezt a funkciót valóban a megfelelő kurzushoz tartozó oktató érhesse el. A nem OK jelzésű riportok helyes betöltésének, és az oktató ezekkel kapcsolatos bírálata és esetleges megjegyzése elmentésének tesztelése. Az automatikus visszajelzés és naplózás ellenőrzése. 9

10 ÓRARENDET LEKÉRDEZ, LETÖLT Kockázat: Közepes Valóban azokat az adatokat érhesse el az adott felhasználó, amelyek rá vonatkoznak. A kapott adatok helyességének különböző körülmények közötti ellenőrzése. A megfelelő formátum ellenőrzése. Az automatikus visszajelzés és naplózás ellenőrzése. Features not to be Tested A Demonstrátori Órarend rendszer alapja az egyetem ETR nyilvántartó rendszere. Csapatunk az ETR rendszeren nem végez változtatásokat, az esetleges felmerülő ilyen igényeket továbbítjuk az ETR karbantartóinak. Ebből adódóan magát az ETR rendszert, annak biztonságos és helyes működését, valamint megbízhatóságát a projekt keretein belül csapatunk nem vizsgálja. Természetesen a munkánk során esetlegesen felmerülő problémákat, bugokat, melyek az ETR rendszer hibájából adódhatnak is dokumentáljuk, és továbbítjuk az ETR karbantartóinak. Célként azonban a projekt során nem ezeket az eseteket tartjuk szem előtt. Ezen kívül csapatunk a következő funkciókat nem teszteli a jelen verzióban: KURZUSOK FELVÉTELE A RENDSZERBE Kurzusok felvétele a jelenlegi modellben tiltott. Ez nem szerepel a szoftver jelenlegi verziójának követelményei között, és a jelen kiadásban nem lesz elérhető ilyen funkció. KURZUSOK TÖRLÉSE A RENDSZERBŐL Kurzusok törlése a jelenlegi modellben tiltott. Ez nem szerepel a szoftver jelenlegi verziójának követelményei között, és a jelen kiadásban nem lesz elérhető ilyen funkció. Approach (Strategy) A tesztelés során a V-modell szabályait követjük. Munkánk során mind a tesztautomatizálási, mind a manuális tesztelési módszereket felhasználjuk. Az automatizált teszt esetek végrehajtása gyors, és könnyen megismételhető, ám esetekben az automatizálás nem kivitelezhető, vagy a manuális megoldás sokkal egyszerűbb folyamatot vesz igénybe. A munkánk során felhasználandó metrikák: LLOC (Logical Lines of Code) Eljárások száma Kritikus és nagy hibalehetőségek mennyisége Code Coverage A Unit tesztek által adott eredmények MTBF (Mean Time Between Failures) A még nem tesztelt kockázatok %-a Felfedett kockázatok %-a kategória szerint rendezve Az összesített jelentett és összesített megoldott hibák aránya Az új hibákat okozó hibamegoldások száma Előforduló hibák prioritása és nagysága Hibák státuszai Konfiguráció lefedettség Munkánk során legalább 80%-os kódlefedettség elérésére törekszünk. 10

11 Munkánk a telephelyünkön történik. A projektre 10 munkatársat és PC-t fordítunk. A használt számítógépek konfigurációja: 40 darab HP Core i7-6700k 16 GB DDR4 RAM 1TB HDD NVIDIA GeForce GT 710 2GB DDR3 Gépenként 2 Samsung 21.5 full HD monitor Windows 10 operációs rendszer UPS és külső merevlemezek biztonsági másolatok készítésére A munka során virtuális gépekkel teszteljük a rendszer más konfiguráció alatt történő működtetését is. Különböző operációs rendszerekkel, és böngészőkkel is kipróbáljuk az egyes teszteseteket. A következő operációs rendszereken teszteljük a rendszert: Windows 10 Windows 8.1 Windows 7 SP1 Linux Ubuntu Linux Debian 8.4 OS X El Capitan A következő böngészőkön teszteljük a rendszert: Google Chrome Mozilla Firefox Internet Explorer 11 Opera 36 A munka során rendszeres review-kat tartunk az elkészült részekről. Ennek során kiderülhetnek egyes problémák, és munkánk dinamikusabbá válik. Mivel a V-modell alapvetően a folyamatos tesztelésre épít, kapcsolatot tartunk fenn a fejlesztőkkel, és rendszeres update-eket kérünk tőlük, mi pedig rendszeres verifikációval és validációval látjuk el őket munkájuk során. A Demonstrátori Órarend projekt megvalósítása során egyes modulok elkészüléséig mások tesztelésre alkalmatlanok lehetnek, ezért is fontos a fejlesztőkkel való együttműködésünk, és rendszeres kommunikációnk. Különös figyelmet fogunk fordítani a tesztelés során a kritikus és nagy hibalehetőségek kiküszöbölésére, és a biztonsági követelmények fenntartására. Mind az igények felmérésére, mind a használat közbeni hibák detektálására a tesztelői csapat tagjait célszerű elküldeni az egyetemre, hogy nyomon kövessék a rendszer működését (hogyan használják az adminisztrátorok, demonstrátorok és oktatók). Erre a látogatásra minimum egy hét szükséges összesen, hogy kellően kiismerjék a rendszert. Ezután egy sokkal letisztultabb képet kapnak a tesztelők, hogy hogyan is érdemes tesztelniük. Item Pass/Fail Criteria Projektünkben elengedhetetlen a tesztesetek kilépési feltételeit megadnunk, hisz tartanunk kell magunkat egy konstans értékhez, mely nagyban befolyásolja a munka menetét, a dolgozók elszántságát, és méginkább összetartó csapatot, csapatszellemet generálhat ezen kritériumok betartásaival. 11

12 Demonstrátori órarend kilépési feltételei a Unit test szinten a következők: Tesztesetek 50% lefutott. A megadott tesztesetek 20%-ban tartalmaznak bizonyos számú hibákat. Kódlefedettség legalább 80% legyen. Master teszt a következő kritériumoknak kell megfelelnie: Minden alsó szintű tervek befejeződtek. A megadott számú tervek hiba nélkül lefutottak és csak kisebb százalékban tartalmaznak hibákat. Suspension Criteria and Resumption Requirements Bizonyos esetekeben előfordulhat, hogy egyes teszt esetek hibásan futnak le, hisz megeshet, hogy maga az eset olyan vizsgálatot próbál készíteni az adott csomagon, mely nem is közelíti meg annak valódi, helyes működését. Ez sokszor előfordulhat, akár többször is egy teszt esetnél. Ebből kifolyólag úgymond meg kell szabadulni ettől az esettől, mely annyi hibát okozott a tesztelés során. Meg kell határoznunk egy pontot, mely után eldobjuk azt a bizonyos esetet. Ennek a bizonyos pontnak a meghatározására be kell vezetnünk egy küszöb értéket, azaz a hiba szám előfordulását. Ezt a mennyiséget 5 újbóli próbálkozásra becsüljük mely szerintünk elegendő ahhoz, hogy kiderítsük a hiba okát és javítsunk a teszt esetünkön. Ha ezt a számot túlhaladjuk akkor nincs értelme folytatni a vizsgálatot. Tulajdonképpen erre azért van szükség, hogy kiszűrjük a hibás eseteket és minél előbb leváltsuk egy jobb, eredményesebb vizsgálatra. Mind amellett hibás teszteket erőforrásparazlás tovább erőltetni. Test Deliverables Az IEEE 829-es szabvány szerint kötelességünk részletes tervet készítenünk a projektünkben. Ezek a következő terv részleteket kell, hogy tartalmazza: Teszt terv dokumentum Tesztesetek Teszt kialakítása Eszközök és kimenetek Szimulátorok Statikus és dinamukus generátorok Hiba és végrehajtási naplók Hibajelentéseket és korrekciós intézkedéseket. Teszt terv dokumentum Minden teszt terv tartalmaz egy dokumentumot melyben leírja a projekt tesztelési folyamatát, technikáit, módjait és minden olyan szükséges segéd anyagot, melyre a jelenben és a jövőben szükség van, ha egy munkát kell értékelni egy referenciához képest. Tesztesetek Teszt esetekből rengeteg adat gyűlik össze, melyet a lehető legjobban kell kezelni annak érdekében, hogy sikeres legyen a projekt. 12

13 Dokumentum tartalmazza a teszt esetek részletes vizsgálatát, hibák keletkezését az esetek futtatásakor és annak elkönyvelését, hibás esetek kezelését oly módon, hogy annak módosítását vagy esetleges újbóli írását. Teszt kialakítása Tesztek kialakítása fontos szerepet játszik abban, hogy a szoftver / rendszer megfelelően működjön, és ne alakuljanak ki olyan tesztek, melyek feleslegessé válnak. Persze ezt nagyon nehéz elérni, épp ezért csak minimalizálni tudjuk ezeket a problémákat. Eszközök és kimenetek Tesztelői eszközök elengedhetetlenek egy vizsgálat megvalósításához és annak kiemenetének tárolásához, későbbi feldologozásához. Ezen munkaeszközöket már megemlítettük az Approach (Strategy) alcím alatt. Szimulátorok Rendszerünkben valamelyest nehézségeket okozott szimulálni a szoftver valódi működését, ennek ellenére a rendelkezésünkre álló számítógépeken létrehoztunk egy úgymond, ETR hálózatot melyen végül is üzemeltettük a rendszer főbb funkcióit: Regisztráció és adatok módosítása Belépés a rendszerbe Kurzus felvétele, aktiválás és törlése Demonstrátor kiválasztás Órarend lekérés Ezek közül a kurzus funkciót volt a nehezebb megvalósítani, hiszem óriási mennyiségű kurzus létezik ETR-ben melyeket mind nem tudtunk megszerezni, így gyakorlatilag ezt lokálisan oldottuk meg. Persze ezek a szimulációk csak arra voltak elegendőek, hogy lássuk hogyan néz ki a rendszer. Hiba és végrehajtási naplók Teszt esetek alkalmával létrejött hibákat és futtatásokat naplózni kell, hogy nyomon kövessük egyes estek hatékonyságát és annak módját miként javíthatunk a rendszerünkön. Ezen információk az egész csapat számára hasznosak, hisz mindenki elérhetővé válik, illetve a hibákból következtetéseket vonhatunk le, összefüggéseket találhatunk egy másik hiba okozójával. Konkrétan a regisztráció, és annak aktiválásakor hibás hiperhivatkozás érkezett a felhasználónak, amely megegyezett a regisztráló olyan adataival amelyet sosem volna szabad GET metódusban közzétenni. Hibajelentések és korrekciós intézkedések A hibákat kötelezően jelenteni kell a tesztelők és a fejlesztők felé a hatékonyabb fejlődés érdekében. Minden hiba keletkezésekor napló szerüen dokumentáljuk a bugokat, majd a nap végére hibajelentést küldünk. Egy hét elteltével heti jelentések is készülhetnek a hibákról. Egy hiba jelentése egy dokumentum mely a következő adatokat kell, hogy tartalmazza: Hiba jelentő személy és annak posztja Dátum Szoftver neve Verzió szám Tesztelői környezet 13

14 Operációs rendszer Jelentés leírása Hiba gyakorisága Remaining Test Tasks A demonstrátori órarend rendszerének tesztelése során maradnak ki olyan területek, amelyek nincsennek benne a teszt tervben és így nem kerülnek tesztelésre. Ezek általában kisebb részek amelyeknél feltételezzük, hogy nincs bennük hiba, vagy olyan részei a rendszernek amelyek hibás működése nem jelent túl nagy kockázatot a teljes rendszer működésére. Erre azért van szükség, mert egy rendszert lehetetlen 100%-ban letesztelni, még akkor sem, ha rendkívül sok idő, nagy költségvetés, illetve elegendő tesztelő áll a rendelkezésünkre. Viszont célszerű ezeket test taskokat, amelyek nem lettek elvégezve lejegyezni egy esetleges jövőbeni javítás, vagy egyéb teendő elvégzésének érdekében. Use case-ek, amelyek működésének tesztelése nem került bele a test plan-be: Riportírás Kiosztás megtekintése és lekérdezése A nem funkcionális követelményeknél a biztonság és a megbízhatóság ennél a rendszernél rendkívül fontos, így mindezek tesztelése jelen van a test taskok között. Viszont itt is vannak olyan esetek is, amelyeket nem lehet letesztelni. Ilyen például az, hogy: Az adminisztrátornak két munkanapon belül reagálnia kell a hozzá intézett, rendszer működésével kapcsolatos levelekre. Ez élesben az a rendszert kezelő adminisztrátoroktól függ. A rendszernek rendelkezésre kell állnia folyamatosan, kivéve a karbantartások és hibajavítások idejére. Viszont tesztelés során nem mindig jönnek elő az olyan hibák, amelyek élesben is előjönnek, így ezt szintén nehéz tesztelni. Egy karbantartás nem tarthat tovább 24 óránál. Viszont előre nem tudhatjuk, hogy meddig tartanak majd a jövőbeni karbantartások. A teljesítmény csak másodlagos, illetve mivel nehéz megteremteni a valós környezetet, amely majd a demonstrátori órarend használatakor jön létre, ezért ez is csak kisebb mértékben kerül tesztelésre. Environmental Needs A test plan elvégzéséhez szükség van egyéb eszközökre is. Ehhez általában nagyobb költségvetésre is szükség van. A következőkre van szükség: Olyan személyre, aki képes a nyelvek használatának helyességének tesztelésére, mert a teljes demonstártori rendszer magyar és angol nyelven is kommunikál a felhasználókkal. Tehát olyan szakemberre, akire ennek a tesztelését bízni lehet. Itt a legfontosabb az, hogy minden kifejezésnek vagy mondatnak ugyan az legyen az értelme magyar és angol nyelven is, illetve hogy vizuálisan is helyesen jelenjenek meg. A teljes rendszer teszteléséhez szükségünk van valós adatokra a tantárgyakkal kapcsolatban, vagy ahhoz hasonlító adatokra. A tesztelők nem tudják előre, hogy milyen tantárgyakkal lesz majd feltöltve a rendszer. 14

15 Egy szerverre amelyen a rendszert futtatni lehet, illetve olyan személyre aki ezt karban tartja. Lehet ez ugyan az az eszköz amin a végleges rendszer is futni fog. Staffing and Training needs A tesztelő csapatnak szüksége van egyes dolgok elsajátítására a demonstrátori órarend szoftverének a teszteléséhez. A tesztelőknek is először tudniuk kell használni a verziókövető illetve az issue tracker eszközöket. Ha ez hiányos, akkor először is ezt kell elsajátítaniuk. Ez mind attól függ, hogy teljesen kezdő csapatról van-e szó, vagy már tapasztalattal rendelkezők csapatáról. Emellett nem árt, ha angol tudással is rendelkeznek a tesztelők, mert a szoftver tartalmaz angol nyelvű elemeket. A tesztelőknek attól függően, hogy milyen szinten tesztelik a szoftvert, ismerniük kell a demonstrátori órarend szoftvert. Azok a tesztelők, akik például a unit tesztel foglalkoznak, azoknak nem kell ismerniük a teljes rendszer működését. Viszont minél feljebb megyünk a V modellben, annál jobban ismerni kell a demonstrátori órarend működését. Leginkább ajánlott a követelmény dokumentum elolvasása, mert az nem csak a szoftver követelményeinek a leírását tartalmazza, de meg lehet belőle érteni az egész rendszer működését, még akkor is ha a tesztelőnek nincs benne tapasztalata, illetve a test plan is az alapján lett megtervezve. Külön trainingre nincs szükség a tesztelés lebonyolításához. Responsibilities A test plan minden részének elvégzéséért van egy felelős személy. A legnagyobb felelősség a test managerre hárül, de az adminisztrátor és a csappattagok is kiveszik ebből a részüket. Az adminisztrátor feladata a teszteléshez szükséges feltételek biztosítása. Jelen esetben az adminisztrátor nem összekeverendő a követelményben meghatározott stakeholder adminisztrátorral. A csapattagok feladata maguknak a teszteknek az elvégzése. Őnekik tényleg csak az a dolguk, hogy minden teszt esetet végrehajtsanak amelyet a teszt menedzserek rájuk szabtak, és összegyűjtsék a végeredményeket. A test plannél viszont a legnagyobb felelősség a teszt menedzseré. A test manager felelős a következőkért: A test plant ő tervezi meg a a test strategy és approach alapján Ő határozza meg, hogy mi legyen letesztvelve és mi ne legyen letesztelve Hogy mi az exit criteria, és hogy mikor van kész a tesztelés Kapcsolattartás a stakeholderekkel Ha valami olyan problémába ütközik a tesztelés, ahol dönteni kell, akkor ez is az ő feladata Schedule Projekt során egy nagyon szoros ütemtervet követtünk, mivel a rendszer nem egyszerű modulokból áll és azoknak a működése rendkívül biztonságosnak kell lennie a kártevők ellen. Mivel ez a rendszer az egyetemi demonstrátorok és professzorok fő szoftvere, szem előtt kell tartani azokat a biztonsági módszereket, amelyek alkalmaznak az egyetemi hálózaton. Ezért az is ilyesfajta védelem miatt kell, hogy ez a rendszer is legalább olyan szinten legyen, mint maga az ETR rendszer. Persze mivel ennek a szoftvernek a használata ETR-en belül folyik ezért már az elején segítséget nyújt annak megismerése. 15

16 Ütemterv terén a rendszer tesztelése során folyamatosan, hétről-hétre készültek a teszt esetek minden egyes modulhoz. Ezen esetek nagy részében sikerült legalább a 50% futtatni, így nem volt nagy a lemaradás a teljes teszt esetek futtattása szempontjából. Több modulnál is sikerült 80%-os tesztlefedettséget produkálni, mely bizonyította, hogy a csapat jól végezte a munkáját. Ennek ellenére megesett, hogy egyes modulok tesztelése / fejlesztése nem úgy indult, ahogy azt vártuk, ezért szembe kellett néznünk azzal a ténnyel, hogy csuszás(ok) merülhetnek fel projekt elkészülte során. Ezek közül kettőt érdemes kiemelni: 1. Kurzusok felvétele, aktiválása, törlése 2. Riportírás, teljesítésigazolás Kurzusok felvétele, aktiválása, törlése A kurzusok hiányában eleinte nem tudtuk min tesztelni az elkészült teszt eseteket mivel az egyetemen a kurzusok listája egy óriási adat mennyiség. Kénytelennek voltunk írni saját kezűleg egy olyan mennyiségű és struktúrájú táblázatot írni, ami az egyetemhez a legjobban hasonlított. Ebből több vita is keletkezett, hogy nekünk kell bázist írni és, hogy manuálisan kell a táblázatot feltölteni. Szerencsére a csapat végül is megértő volt, hiszen az a cél állt előttünk, hogy jól működő szoftvert teremtsünk a fejlesztőkkel. Noha a fejlesztők se voltak teljesen tisztában a bázis teljes struktúrájában, segítséget kaptunk tőlük, hogy is fogjunk hozzá. Végül a kezdeti nehézségek és az ezutáni apró nézeteltérések után megoldódott a probléma és 79% kódlefedettséggel fejeződött be a tesztelési folyamatunk. Riportírás, teljesítésigazolás Ezen a modulon felhasználó hiányban volt a lokális rendszer, ezért a tesztelők és fejlesztők mellett a Scrumban ismert csirkéket kértük meg, hogy regisztráljanak be és használják a rendszer mintha demonstrátorok lennének illetve tanárok. Sajnos az alacsony populáció miatt nem igazán jöttek a riportírások ezért megpróbáltuk mozgósítani az embereket. Harmadik hét után már sikerült enyhíteni a csuszáson, hiszen ezzel a felhasználó toborozással elég sok idő eltelt, és a tesztesetek kihasználhatatlanok voltak. Ahogy nőtt a felhasználók száma úgy javult a helyzet. Sikeres / sikertelen esetek száma is növekedett elejében a sikertelen esetek felé hajlott majd átcsúszott a mérleg a sikeres oldalra. Planning Risks and Contingencies Mint minden projektben, itt is előfordulhatnak tervezési kockázatok, melyek akár megkérdőjelezhetik a szoftver minőségét, megbízhatóságát. Az sincs kizárva, hogy útközben megváltozik a projekt követelménye. Ehhez hasonló kockázatok merültek fel a rendszerünk tesztelése során melyek a következők: Személyek hiánya tesztelés során Kurzusok adatbázisának elérhetőségi hiánya Változások az eredeti követelmények során Ezen kockázatokkal részleteivel már foglalkoztunk az előző alcímek alatt. 16