Master Test Plan Demonstrátori órarend Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán

Átírás

1 Master Test Plan Demonstrátori órarend Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán

2 Tartalomjegyzék Test plan identifier... 4 Introduction... 4 Background... 4 Objectives of the Test Plan... 4 Objectives of the User Acceptance Testing... 4 References... 4 Test Items... 5 Items to be tested... 5 Items not to be tested... 6 Features to be Tested... 6 Features not to be Tested... 8 Approach... 8 Plan Testing... 8 Develop Tests Prepare to Test Run Tests Review Test Results Change Management Item Pass/Fail Criteria Evaluating Team Evaluating Process Requirements Traceability Matrix Suspension criteria and resumption requirements Test Deliverables Testing tasks Environmental Needs Responsibilities Staffing And Training Needs Training Staffing needs... 18

3 Schedule Risks and contingencies Risks Contingencies Approval... 25

4 Test plan identifier #1 Introduction Background Ez a dokumentum a demonstrátori órarend nevű projekthez készült, egész pontosan annak magas szintű (ún. Master Test Plan) teszt terve. A dokumentumnak megelőző teszt terve nincsen, hiszen a legmagasabb szintről beszélünk. Az ún. Level Test Plan -ek követik, amely az itt meghatározott tesztelési szintek részletes, szint specifikus tervét tartalmazzák. Objectives of the Test Plan A tesztterv célja, hogy definiálja azokat a projekt specifikus tesztelési folyamatokat, eszközöket, és környezetet, valamint ütemezést, hogy a tesztelés után a projekt stakeholderei maximálisan elégedettek legyenek a termékkel. Objectives of the User Acceptance Testing Fontos, hogy minden funkcionalitás, ami a felhasználói scenariokhoz szükséges, működjön. Továbbá ezen funkcionalitások a specifikációba leírtaknak megfelelően működjenek. References Policy dokumentum Strategy dokumentum A projekt követelményspecifikációja (DemonstratoriOrarend-Req.pdf)

5 Test Items Items to be tested Tesztelendő (al)rendszerek Verzió Demonstrátorok regisztrációja v1.0 Bérelszámolási rendszer v1.0 Kurzusok műveletei v1.0 Login v1.0 Demonstrátorok jelentkezése/kiválasztása/beosztás v1.0 Teljesítésigazolás és nyugtázás v1.0 Teljesítmény v1.0 Megbízhatóság v1.0 Használhatóság v1.0 Biztonság v1.0 Ezzel definiáltuk a tesztelendő rendszereket magas szinten, amely azt jelenti, hogy ezen rendszerek további tesztelendő alrendszerekre bonthatók. Viszont e feladat meghatározása nem tartozik a Master Test Plan definíciójába. A funkciók tesztelését kritikus és szakmai szemmel kell végrehajtani. Hiba esetén a teszt menedzser mielőbb értesítendő, aki gondoskodik a hiba javításának beütemezéséről.

6 Items not to be tested Az alábbi funkcionális és nem funkcionális követelményeket nem teszteljük. Ennek oka, hogy hasonló funkciókat teszteltünk, vagy éppen az adott követelmény/funkció kevésbé fontos az ügyfél számára, ezért idő hiányában ezek tesztelése tulajdonképpen béta teszteléssel történik. Amikor a szoftver elkészül, az ügyfél használhatba veszi azt, ha viszont talál benne még meg nem talált hibákat, akkor jelzi cégünknek, s mi azokat legjobb tudásunk szerint és a lehető leggyorsabban kötelesek vagyunk kijavítani. Nem tesztelendő (al)rendszerek Riportírás Adminisztrátorok regisztrációja Features to be Tested Az alábbi felhasználói scenariokat teszteljük, teljesen user szintű tesztelési folyamattal, azaz a tesztelés a felhasználó szemszögéből történik. Az egyes alrendszerek tesztelésekor meghatározzuk, hogy azokból melyik felhasználói munkamenetek kerüljenek tesztelésre, és egyfajta prioritási szintet is adunk nekik (L - Low, M - Medium, H - High), főleg azok kerülnek előtérbe, ahol nagyobb a kockázat lehetősége (később bővebben tárgyaljuk a kockázatokat egy másik fejezetben). Tulajdonképpen szemléletmódban különbözik ez a pont a Test Items nevezetűtől, ahol inkább a technikai terminológiát, és szemszöget helyeztük előtérbe, itt viszont a felhasználó szemszöge az elsődleges.

7 Tesztelendő egységek Demonstrátorok regisztrációja Bérelszámolási rendszer Demonstrátorok jelentkezése/kiválasztása/beosztás Demonstrátorok jelentkezése/kiválasztása/beosztás Demonstrátorok jelentkezése/kiválasztása/beosztás Tesztelendő üzleti munkamenetek Konkrét demonstrátor beregisztrálása Konkrét demonstrátor havi bérének kiszámítása Konkrét demonstrátor pályázatának elbírálása Konkrét demonstrátorok kiválasztása Konkrét demonstrátori órarendjének (beosztásának) elkészítése Kockázati szint H H L M H Megbízhatóság Rendelkezésre állás tesztje M Teljesítmény Használhatóság Kurzusok műveletei Login Többszáz felhasználóval egyszerre használjuk a rendszert Magyar és angol nyelven való működés kipróbálása, súgó ikon működésének kipróbálása Konkrét kurzus(ok) aktiválása, inaktiválása, felvétele a rendszerbe Konkrét felhasználó névvel és jelszóval való bejelentkezés L H M H

8 A fenti táblázat tehát mindössze egy magas szinten definiálja a tesztelendő alrendszerek felhasználói munkafolyamatait. A demonstrátori órarend projekt esetében (a projekt méretét tekintve) nincs szükség további teszt terv dokumentum (Level Test Plan-ek) írására, hiszen a fenti táblázat is jól és kimerítően definiálja a felhasználói szemszögből kielégítendő funkciókat. Features not to be Tested Az alábbi táblázat definiálja azokat a funkciókat, amelyek tesztelése (felhasználói szemszögből!) nem történik meg, különböző okok miatt: Nem tesztelendő egységek Teljesítésigazolás és nyugtázás Riportírás Adminisztrátorok regisztrációja Nem tesztelendő üzleti munkamenetek A jelentésírás elfogadása és visszajelzés Jelentés írása az oktatónak az óra megtartásáról Konkrét admin regisztrációja Approach Plan Testing A Plan Testing egyfajta előkészülete a következőkben tárgyalt négy lépésnek. A tesztelési folyamat mind addig folytatódjon, amíg létezik olyan felhasználói munkamenet (user scenario), amely nem működik tökéletesen. Ha már nem létezik ilyen, azaz nem találunk újabb hibát, ez esetben még egyszer egy ellenőrző tesztelést hajtsunk végre a projekt

9 fontosabbnak ítélt 50%-án. További feltétel, hogy a lehetséges konfigurációk 75%-a tesztelve legyen. A tesztelési folyamat elvégzésére - főleg a projekt méretére hivatkozva - mindössze 60 (azaz hatvan) munkanap áll a tesztelői csapat rendelkezésére. A kockázati prioritási szinteket tartsuk be a fentebb definiált alacsony (L), közepes (M), magas (H) prioritási szinteknek megfelelően. Előfordulhat esetlegesen fatális hiba, amely az egész rendszer meghibásodását eredményezheti, ekkor viszont ezen hiba javítását azonnali hatállyal helyezzük előtérbe. A tesztelési folyamathoz a tesztelői csapat többnyire szabad kezet kap a teszt eszközök használatában. Automatizáláshoz viszont a Selenium WebDriver eszközt (Eclipse fejlesztői környezeten keresztül) használjuk. A tesztelés belépési feltételei: Egy elfogadott, átfogó tesztterv (jelen projekt esetében ez a tesztterv) Pontos specifikáció az ügyféltől, és a specifikáció ellenőrzöttsége Minden szükséges erőforrás biztosítottsága Minden tesztelni kívánt funkcióra előírt teszt esetek megléte A kilépési feltételek definiáltak A tesztelés kilépési feltételei: Legalább 75%-os utasítás szintű lefedettség a kódban VAGY Nem találunk több hibát a felhasználói munkamenetekben (a fentebb említett fontosabb 50% ellenőrzése során sem) VAGY Az ügyfél kérvényezi a szoftver mielőbbi átadását, vállalva a kockázatokat, hogy a fentebb lévő kilépési feltételek egészét (vagy részét) cégünk még nem teljesítette. Ez esetben a tesztelés félbeszakítható.

10 Develop Tests A tesztek fejlesztése során számos tevékenységet végre kell hajtanunk. Mindenek előtt elemezzük a követelményeket, vitassuk meg azokat a részeket, amelyek esetlegesen kimaradtak a követelményekből, a csapat viszont úgy gondolja, hogy fontos a tesztelése, illetve fordítva, az olyan specifikált követelmények tesztelését, amelyre túl sok ráfordítással kellene számolnunk (legyen az human erőforrás, vagy idő, esetleg anyagi erőforrás). Tervezzünk meg konkrét munkameneteket (scenario-kat), más néven ezeket Use-Case -eknek, azaz használati esetnek is hívjuk. Az elfogadási feltételeink tulajdonképpen megfelelnek a használati esetek hibamentes működésének. Ezt követően állítsunk elő minden használati esethez legalább 5 (azaz öt) különböző teszt esetet (konkrét inputokkal, és elvárt outputokkal), ahhoz, hogy azt mondjuk, hogy az adott Use-Case letesztelt. Ezen kívül mérjük a rendszer stabilitását és használhatóságát metrikákkal, a metrikákat pedig teszt szkriptek írásával számolhatjuk ki. Természetesen ezen folyamatok mellett folyamatosan ellenőrízzük (review-eket hajtsunk végre) minden teszteléssel kapcsolatos dokumentumon az eredményesség és a minőségi munka érdekében. Prepare to Test A tesztelésre való felkészültség alapfeltétel ahhoz, hogy egyáltalán neki kezdhessünk a tesztek futtatásának. Ehhez azonban az úgy nevezett tesztelési környezetnek rendben kell lennie, ami alatt nem kizárólag a számítógépes tesztelési eszközöket értjük, hanem mind a tesztelői csapat embereit, a hardver-, és szoftverkövetelményeket, a tesztelési folyamatok meglétét (azért, hogy minden csapattag tudja hogy mikor mit

11 kell csinálnia, és mire mennyi ideje van), valamint a teszteléshez szükséges adatok rendelkezésre állását. Ezen kívül természetesen mielőtt elkezdjük a tesztelést, meg kell nézni, hogy az előkészületek után teljesüle a belépési feltételekben összefoglalt pontok mindegyike, valamint a tesztelők megkapták a tesztelési instrukciókat, hogy a rendszeren hogyan futtassák a teszteket és, hogy hogyan használják az egyes teszt szkripteket. Run Tests A megtervezett teszt eseteket futtassuk úgy, hogy a teszt esetek specifikációiban előírt inputokat adjuk meg, és vizsgáljuk meg, hogy az elvárt outputo(ka)t kapjuk-e ezen bemenetek esetén. Ezen kívül még naplózzuk (logoljuk) a teszt eseteket a későbbi statisztika készítés és következtetés levonás érdekében. Review Test Results Ellenőrízzük a futtatott teszteket, beleértve az adott teszt esetre vonatkozó teljes(!) felhasználói munkamenetet (scenario-t), a követelményeit, és természetesen a teszt esetek eredményeinek kihatását a teljes rendszerre. Change Management A tulajdonképpeni lezáró tevékenysége az előző négy lépésnek. (Azaz a Plan Testing és a Change Management egyfajta koordináló tevékenységei a köztük tárgyalt négy lépésnek.) Az előző lépésben meghatározott kihatásokat elemezzük, és ha megítélésünk szerint túl nagy hatással volt a rendszerre, akkor változtassunk a tesztelési folyamat valamely lépésén (legyen az akár a tesztek megtervezése, végrehajtása, stb.). A változtatások folyamatos optimalizálása fontos, hiszen nagyban befolyásolhatja a tesztelés hatékonyságát (mind időben, mind pedig erőforrásokban).

12 Item Pass/Fail Criteria Jelen pontban definiáljuk a Test Items pontban megadott funkciók (Itemek) tesztelési sikerességeinek (esetleges sikertelenségeinek) feltételeit. Részletes feltételeket viszont itt nem adunk, csupán egy áttekinthető, magas szintű feltételrendszert írunk elő. A feltételekkel és a kiértékelésekkel kapcsolatos tudnivalókat viszont az áttekinthetőség érdekében négy alpontban tárgyaljuk: Evaluating Team Deák Kristóf - Teszt Menedzser Lauly Viktória Kunigunda - Főszponzor képviselő Csiki Norbert - Fejlesztői csapat képviselő Szabó Zoltán - Teszt elemző (Test Analyst) A fent említett mindenkori négy személy együttesen döntenek a tesztelendő modulok tesztelésének sikerességéről illetve sikertelenségéről. Evaluating Process Legelőször összegyűjtjük az összes futtatott teszt esetet az adott modulra. Ez után összegezzük, elemezzük, hogy mennyi volt sikeres, illetve sikertelen, elemezzük az előforduló incidenseket, majd számolunk egy sikeres/sikertelen arányt az egyes modulokhoz. Ekkor egyfajta statisztikát kapunk, amely alapján a kiértékelő csapat döntést hoz arról, hogy a modul összességében átment, illetve megbukott a tesztelésen. Utóbbi esetben a modul további tesztelése (és adott esetben fejlesztése) szükséges. A kiértékelő csapat köteles objektívan, és a fentebb tárgyalt kilépési feltételeket szemmel tartva meghozni a döntését! Requirements Traceability Matrix A Login funkció tesztelésének előfeltétele a Demonstrátorok Regisztrációja funkció tesztelése. Ez pedig egy fajta tranzitív függési kapcsolatot jelent, hiszen a Login funkció sikeressége szükséges a kurzusműveletek teszteléséhez (felvétel,leadás,aktiválás,stb.), valamint a

13 demonstrátori pályázat beadásához. Ezért a tranzitivitás jelen van a Demonstrátorok Regisztrációja és a kurzusműveletek, illetve demonstrátor pályázat leadása funkciók között. Más előfeltételeket a projekt során nem szabunk meg. Suspension criteria and resumption requirements Bármely tesztelendő modulban, ha végzetes (Fatal) hiba tűnik fel, akkor fel kell függeszteni annak további tesztelését, hiszen a fatális hibából kifolyólag, ennek hatására újabb hibák keletkezhetnek (úgy nevezett szellem hibák, avagy ghost error-ok), amelyek a fatális hiba megléte nélkül lehet, hogy nem jelennének meg. Ezen kívül, ha egy modulban legalább öt darab kritikus (Critical) hiba fordul elő, szintén felfüggesztésre kerül, hiszen ezen hibák hatásköre szinte biztosan átfedi a teljes modul funkciókat, így a további tesztelés szintén erőforrás vesztegetés volna. Valamint az összincidens szám nem haladhatja meg a tesztesetek számának 40 (azaz negyven) százalékát. Az adott felfüggesztett modulok tesztelése akkor folytatódhat, ha nincs több fatális hiba jelen az aktuálisan folytatni kívánt modulban (tehát ezeket korábban már javítottuk), illetve, ha az öt kritikus hibából legalább hármat már kijavított. Természetesen az összincidens szám összes teszt esethez viszonyított arányának mindenképpen teljesülnie kell! Test Deliverables A tesztelés során csapatunk a következő dokumentumokat köteles szállítani az ügyfél számára: Test Plans: A tesztelés menetének leírása, pontosan leírja, hogy mit teszünk, milyen eredményt várunk el a végrehajtott lépésektől, milyen erőforrásokat, mennyi időt fog igénybe venni a test, valamint milyen kockázatokkal kell számolnunk a végrehajtás során.

14 Test Design Documents: A test során felhasználandó adatokat írja le, azokat a követelményeket, melyeknek a teszteléshez használt adatoknak, inputoknak meg kell felelniük. Test Cases: A pontos, design-nak megfelelő input adatok, az azoknak megfelelő elvárt output értékek, minden szükséges lépés, amit esetleg a test megkezdése előtt meg kell tennünk. Testing Process: A konkrét lépések sorozata, amelyeket a tesztelő végre fog hajtani, a hardveres és szoftveres követelmények a végrehajtáshoz. Test Logs: Lista, hogy melyik testek futottak le, milyen eredménnyel, milyen lépések hajtódtak végre, esetleg bekövetkezett-e váratlan esemény, ha igen, pontosan mi. Incident Reports: Az IEEE szabványnak megfelelő leírás minden esetleges anomáliáról, amelyek alapján később bugokat, hibákat találhatunk. Test Summary: A megrendelővel egyeztetett időközönként, illetve a testelés végén kimutatások a testelés állásáról, a sikeresen, hibásan futtatott tesztekről, az incidensek számának változásáról. Testing tasks (1) Tesztek tervezése, monitoring & control: A teszt esetek tervezése előtt a teljes csapatnak meg kell ismernie a demonstrátori órarend projekt részletes specifikációját. A tervezés mellett a folyamatos megfigyelésnek (monitoring) és kontrollálásnak mindig jelen kell lennie. Az eredményt azonnal továbbítani a megrendelők felé. Időtartam: Két hét. (2) A fejlesztői csapattól kapott információk alapján a teszt designok tervezése. Ehhez meg kell kapnunk a szükséges input adatokat, leírásokat, hozzáférést az ETR-hez és a bérelszámolási rendszerhez (vagy az azokat a tesztelési környezetben helyettesítő entitásokhoz). Elvégzése után az eredményeket ismét azonnal szállítani kell a megrendelőnek. Az (1) pont előfeltétele ennek a pontnak. Időtartam: Két hét.

15 (3) Teszt esetek fejlesztése (azaz implementálása), lekódolni a konkrét eseteket, amelyeket a tesztelés során követni fogunk, és az előző pontokban terveik már elkészültek. Az (1) és (2) taskok előfeltételek, a végeredmény ezúttal is átmegy a megrendelőnek. Időtartam: Egy hét. (4) Teszt környezet előkészítése, az (1) és (2) lépésekkel párhuzamosan kell futnia, hogy mire a teszt esetek készen állnak, rendelkezésünkre álljon a környezet is, a meghatározott összetételű gépekkel és szoftverekkel együtt, amelyeket az Environmental Needs következő pontban részletezünk. Időtartam: Egy hónap, valamint utána egy hét a környezet tesztelésére, kipróbálására. (5) Tesztelés végrehajtása (a) Belépés konkrét felhasználó névvel és jelszóval - az összes biztosított felhasználói profil használata (b) Rendelkezésre állás és terhelési tesztek a JMeter segítségével (a tesztelés időtartama alatt folyamatos időközönként) (c) ETR és elszámolási rendszer felé irányuló kapcsolatok tesztelése (le kell zajlania az elkövetkező test-típusok előtt) (d) Kurzusok lekérése, kiválasztása, aktiválása (e) Demonstrátor kiválasztás (elbírálás, regisztráció) ellenőrzése (f) Demonstrátori hatáskör, tevékenységek tesztje (g) Magyar és angol nyelvű rendelkezésre állás tesztje Időtartam: Egy hónap. (6) A tesztek során elkészült incidens riportok vizsgálata a megrendelőkkel, esetleg a fejlesztőcsapat tagjaival közösen. A nem egyértelmű esetekre további teszt eseteket gyártani, végrehajtani azokat. A riportokból pedig levonni a megfelelő következtetéseket. Időtartam: Egy hét. (7) Tesztelés befejezése, lezáró tevékenységek. (Pl.: End Meetingek lebonyolítása, statisztikák készítése az eredményekről,stb.) Időtartam: Két hét. Az (5) és (6) lépések ismétlése az összes teszt sikeres végrehajtásáig (vagy ha az a felmerülő problémák, incidensek mennyisége alapján esetleg tarthatatlan,

16 akkor a meghatározott idő lejártáig), közben a megbeszélteknek megfelelő kimutatások szállítása. Ezek után pedig a (7) lépéssel lezárjuk a tesztelést. Environmental Needs A teszteléshez szükségünk lesz megfelelő hardware-kre, a teszt adatokra, továbbá megfelelő tesztelési eszközökre. A számunkra meghatározott minimális hardware követelmények (gépenként): Intel Core i7-4790k 4.4 GHz Processor (4-core) 250 GB SSD 500 GB HDD 8 GB RAM Razer egér Cooler Master, legalább 600 W teljesítményű tápegység Dual monitor Teszt adatokat egyértelműen az ETR rendszerből kell kérni (akár régebbi, elavult adatokat, vagy névtelen listát), amennyiben lehetőséget kapunk rá. Ha ez nem megoldható, akkor általunk írt/generált adatokkal kell dolgoznunk. Fontos, hogy az adatmennyiség elegendő legyen az átfogó teszteléshez (minimum felhasználó, tantárgy). A tesztelési hibák kezeléséhez, rögzítéséhez a Redmine-t használjuk. Ez az eszköz tökéletesen segíti az incidensek kezelését, nyomon követését és még sok egyéb más információt is magában hordoz. Azért van rá szükségünk, hogy a felmerülő incidenseket megefelelően tudjuk kezelni, így nem merülhetnek feledésbe Automata teszteléshez a A JMeter-t fogjuk használni. A Jmeter egy széles körben használható teszt alkalmazás, ami könnyen kezelhető és hatékony. Segítségével grafikus felületen megtekinhetjük az eredményeket. A webalkalmazás tesztelése nem csak a helyesség ellenőrzésében merül ki, hanem életszerű stressz tesztet, teljesítmény tesztet is kell futtatni. A projekt tesztelésekor elengedhetetlen, hogy stressz tesztnek is alávessük a programot, hiszen egyszerre több felhasználóra számíthatunk majd.

17 Harmadik eszköznek egy open-source GUI testing tool-t használunk, a Sikuli-t. A Sikuli automatizál bármit, amit a képernyőn látunk. Képfelismeréssel segíti a GUI elemek irányítását. Az 1.5-ös verziót fogjuk használni. Ezzel könnyedén tudjuk majd letesztelni különböző platformokon a megjelenő programunkat, hogy minden nézet esetén elérhető e minden funkció, kattintható-e, vagyis nem takarja-e ki más felület és megfelelően működik-e. Továbbá szükségünk van egy riportot készítő eszközre is. Itt a választás a Zephyr-re esett. Igaz, hogy fizetős eszköz, de annál jobb felületet biztosít a célnak. A program összegyűjti a korábban elvégzett tesztek eredményét, akár többféle más eszközök által készítetteket is, amik JUnit formátumban kell, hogy legyenek. Az eszköz segítségével más-más hardvereken és platformokon futtatott teszteket képes összegezni. Ez igen hasznos számunkra, tekintve, hogy két-három féle tesztelési eszköz kimenetét kell egységesen ábrtázolnunk, elemeznünk. Responsibilities A mindenkori teszt menedzser felelősségei: Ezen tesztterv betartása, betartatása és követése a teljes tesztelési folyamat során A tesztelés során felmerülő kockázatok kezelése A tesztelendő, illetve nem tesztelendő funkciók meghatározása (rendkívüli esetben rendelkezhet úgy, hogy egy korábban tesztelni kívánt funkció mégsem kerül tesztelésre, illetve fordítva, hogy egy tesztelni nem kívánt modult mégis letesztelünk) Új eszközök esetében a csapat számára trainingek szervezése Heti jelentést tenni a tesztelés állapotáról a mindenkori projekt menedzsernek Az egyes tesztelendő alrendszerek ütemezésének beosztása A technikai adminisztrátorok felelősségei: Biztosítani az Environmental Needs pontban megfogalmazásra kerülő környezetet a teszteléshez, mind hardveresen, mind pedig szoftveresen A környezet karbantartása, és folyamatos naprakészségének biztosítása A tesztelők felelősségei: A megtervezett teszt esetek végrehajtása (& implementálása)

18 Három naponta jelentést tenni a teszt menedzsernek a futtatott teszt esetek eredményeiről Incidens észrevétele esetén szólni az illetékeseknek Az üzleti elemző felelősségei: Statisztikák, szemléltető ábrák készítése a teszt esetek eredményeiről, s azok mihamarabbi eljuttatása a teszt menedzserhez Ha a teszt menedzser kéri, akkor segítség nyújtása az ütemezés optimalizálásában A teszt menedzser távollétében a meetingek, fórumok menetének levezetése, adott esetben az emberek közötti konfliktusok feloldása A fejlesztők felelősségei: A kódjukban a jelentett incidenseknek való utána járás, hiba esetében pedig annak javítása Unit tesztek írása, ezek eredményeinek feljegyzése, s a tesztelői csapat tájékoztatása azokról Staffing And Training Needs Training A csapatunk nem kezdő a tesztelésekben, így nem kötelezően, de javaslott trainingeket szervezünk a tesztelés megkezdése elött. Mindezt azért, hogy minden tagunk megfelelő tapasztalattal bírjon, és aki úgy érzi, hogy szüksége van előképzésre, legyen rá lehetősége. A részvétel opcionális. A következő trainingek kerülnek megszervezésre, elegendő jelentkező esetén: 1. Rendszer / applikáció megismertetése 2. Tesztelési technikák User acceptance testing (UAT) keretében 3. Teszt végrehajtás és Reporting toolok hasznáalta Staffing needs A teszteléshez a következő szakembereket vesszük igénybe, akik az (1-5 skálán) az alábbi képességekkel rendelkeznek:

19 Szakember A B C D E F G H I Deák Kristóf Lauly Viktória Kunigunda Csiki Norbert Szabó Zoltán A legalapvetőbb képességbeli elvárások a tesztelőkkel szemben: *A. Out of the Box thinkers - Egy jó szakember képes többféle mi lenne ha scenariót kitalálni. Tovább képes felhasználói szemszögből tekinteni a szoftvert. *B. Excellent Communication Skills - Azaz szükséges a megfelelő kommunikációs képesség, mind írásbeli, mind pedig szóbeli szinten. *C. Quick Learner - Gyors alkalmazkodó és tanuló képesség. A következő pontok már nem alapvető elvárásaink, viszont fontos figyelembe venni őket: *D. Passion for Testing - Igazi elhivatottság érzése a tesztelés iránt. Ha valaki jó teszter akar lenni, elengedhetetlen az elkötelezettség a munkája iránt. *E. Good thinking and analyzing skills - Az A pont jelentős hatással van erre a pontra. Viszont vannak akik még többet tudnak kihozni magukból a gyors gondolkodásmódjukkal és analizáló készségeikkel.

20 *F. Think from customer s perspective - Teljesen képes a megrendelő szemszögéből vizsgálni a programot, belehelyezni magát a nem mindennapi PC felhasználók látásmódjába. *G. Domain Expert - Aki átlátja, és megérti egy szoftver vagy applikáció alapműködését. Ezáltal megfelelő tudást biztosít ahhoz, hogy lényegre törően tudja letesztelni az adott programot. * H. A test to break attitude - Egyik fő szempontja a minőség. Ez a törekvése kiváló tesztelési képességekhez segíti őt. *I. Business Savvy - Kicsit jobban eltávolodva átlátja a cég business megközelítéseit és módszereit. Schedule A teljes projekt tesztelési folyamatának végrehajtására három hónap (azaz 90 munkanap) áll a tesztelői csapat rendelkezésére! Ahogyan a Testing Tasks pontban már említettük, a tesztelési környezet kialakítása, beüzemelése időben mindenképpen párhuzamosan történjen a tervezési fázis lépéseivel. Ezt a továbbiakban nem tárgyaljuk, hiszen ez a technikai adminisztrátorok feladata, nem kimondottan teszteléshez kapcsolódó tevékenység. Természetesen a harmadik és negyedik pontnak előfeltétele. Fontos említeni, hogy amennyiben valamely lépés késik, az esetleges következményeket mindig az adott lépés felelőse(i) vállalja. A következmények nem előre definiáltak, a szankciókról cégünk vezetősége (kikérve a teszt menedzser véleményét, hiszen ő ismeri a tesztelői csapatot, ezért, ha egy ember például rendszeresen késik a munkájával, akkor elbocsátási javaslatot is tehet a cég vezetőinek)

21 Az tesztek tervezése, monitorozása és kontrollálása esetében fontos, hogy (a rá eső két hétből) az első hét elteltével a csapat minden tagja áttanulmányozza, figyelmesen többször is végigolvassa, értelmezze a projekt teljes specifikációját. A második héten pedig statikus tesztelési módszert alkalmazva, magára a specifikációra is hajtsanak végre felülvizsgálatokat (review-eket), ezek számát a teszt menedzser határozza meg. Adott esetben, ha valaki úgy gondolja, hogy már a specifikáción is változtatás szükséges (mert nem egyértelmű, hiányos, stb.), akkor erről megbeszélést kell tartani, és megegyezni az esetleges változtatások végrehajtásáról, illetve végre nem hajtásáról. A teszt designok tervezésekor a rájuk szánt két hetes időintervallum természetesen onnantól kezdődik, amikor a fejlesztőktől megkaptuk az egyes modulok elvárt működéseinek leírásait, hozzáféréseket, és az előző lépés, mint előfeltétel már teljesített. Az előfeltételek késése miatt az ezért a pontért felelősek semmilyen szempontból nem vonhatók felelősségre, és ugyan ez igaz a többi előfeltételes pontra is! A tényleges teszt esetek megtervezésére, pontos specifikálására összesen két hét áll rendelkezésre, ebből az első hét végére egy úgy nevezett béta verzió készül, amelyet a második héten szintén ellenőríznek, felülvizsgálnak, hogy a megtervezett teszt esetek tényleg azokról a szempontokról nyújtsanak majd információt, amelyeket tesztelni szeretnénk. A teszt eseteket úgy kell megtervezni, hogy azok későbbi regressziós tesztelési célokra is felhasználhatók legyenek. A második hét utolsó munkanapján a teszt esetek terveit továbbítani kell a teszt menedzsernek is. A teszt esetek implementálására rendelkezésre álló idő egy hét. Ehhez persze az előző két pont előfeltétel, így hasonlóan itt is akkortól számítjuk az egy hetet, ha azok már teljesültek. Eben az egy hétben a tényleges kódolás, implementálás zajlik. Ezt tovább már nem bontjuk, hiszen nincsenek altaszkjai ennek a folyamatnak. A hét ötödik munkanapjának végére a teszt eseteknek implementálva kell lenniük. Maga a tesztelés végrehajtásának optimális ütemezése a legfontosabb a projekt időbeosztásának szempontjából. Az ott megfogalmazott pontok közül az (a) és (b) pontokra együttesen egy hét áll a csapat rendelkezésére, ebből is az idő nagy része a rendelkezésre állás illetve a terhelési tesztek végrehajtásával teljen. Az eredményeket fel kell jegyezni minden egyes teszt eset végrehajtásakor! A ( c) pontra egy külön, teljes hetet kell szánni, hiszen a

22 rendszer magjának teszteléséről beszélünk. A maradék két hétben pedig a (d), (e), (f), (g) pontokat teszteljük, a négy pont közül a prioritási sorrendet az imént felsorolt sorrend adja. A második hét utolsó munkanapján pedig végezzünk újratesztelést (re-testinget), ellenőrzésképpen és biztonsági szempontok miatt. A (g) ponthoz pedig ha szükségesnek érzi a teszt menedzser, hívhat nyelvészt, hogy az esetleges idegen nyelvi nyelvtani hibákat ellenőrízze. Az incidens riportokat átvizsgálatának egy munkahét alatt meg kell történnie. További lebontás ezen a ponton nem szükséges. Ezen a héten mindennapos fórumokon, meetingeken, beszélgetéseken keresztül elemezni kell az elkészült riportokat, majd eszmecserék után pedig döntést kell hozni arról, hogy mely incidensekre (vagy modulokra,stb.) szükséges további tesztelés a meggyőződés szempontjából, és melyekre nem. A tesztelést lezáró tevékenységek lebonyolítására két hét áll összesen rendelkezésre. Az első héten vizsgáljuk meg újra a teljes végbement tesztelési folyamatot, hogy minden a tervek szerint haladt-e, és elértük-e azt a célt, amit az elején kitűztünk. Ezzel párhuzamosan, szintén az első héten az üzleti elemzők a riportok alapján készítsenek különböző statisztikákat, ezek által szemléltethető a tényleges előrehaladás (illetve esetleges lemaradás). A második héten pedig dokumentáljuk a tesztelési folyamatot, hiszen a dokumentáció hasznos lehet a későbbiekben, ha hasonló projekttel lesz dolgunk, akkor lesz egy támpont, hogy mit hogyan kezeljünk benne. Risks and contingencies A projekt tesztelésének szempontjából számos kockázat bekövetkezésével számolnunk kell: Risks Csapattagok megbetegedése, munkaképtelensége: Valószínűsége igen csekély, de mindenképpen számolnunk kell vele. Azzal az esettel is, ha egyszerre több csapattag lenne munkaképtelen. Kezelése új

23 munkatársak felvételével, vagy a fejlesztők tesztelői tevékenységekbe való bevonásával történik. Anyagi okok miatt nem biztosított a megfelelő környezet: Előfordulhat, hogy váratlan, előre nem látott kiadások (contingencies) miatt cégünk nem tudja biztosítani az Environmental Needs pontban megfogalmazott hardver- és/vagy szoftver követelményeket, vagy legalábbis a megfelelő időn belül nem. Kezelése az ügyféllel való konzultációval, és a határidő módosításával (eltolásával) történik, vagy pedig ha lehetőségünk van rá, csökkentsük a környezeti feltételeket annyira, amelyet a megfelelő időn belül tud finanszírozni cégünk. E kockázat valószínűsége már nem annyira elenyésző, mint az előzőé, ezért készítsünk egy olyan ütemtervet tartalékként, amelyben kevesebb költségű követelményeket határozunk meg, viszont (természetesen az ügyféllel megbeszélve) a tempó nem annyira feszített, mint a jobb környezet esetében. Ez esetben az ügyfélnek megértőnek és türelmesnek kell lennie, hiszen ezekkel a kockázatokkal eredetileg nem számolhatunk, váratlanul következhetnek be. Trainingek késése, nem megfelelő eredménye: Számolnunk kell azzal is, hogy a trainingek valami oknál fogva nem tudnak elkezdődni időben, vagy éppen fordítva, hogy elhúzódnak. Ez esetben a munkatársaknak a le nem adott anyagrészeket önmaguknak kell feldolgozniuk, munkaidőn kívül, behozva ezzel az időbeli lemaradást. Ugyan ez a teendő a nem megfelelő eredmény esetében is, annyi kiegészítéssel, hogy ez esetben konzultáljanak azokkal a kollegákkal, akiknek sikerült elsajátítani a kérdéses anyagrészt, és beszéljék meg azt. Előfordulási arányának valószínűsége közepes, főleg azért, mert a trainingek nem mindig hozzák meg a várt eredményt, gyakran további, otthoni gyakorlás és önképzés szükséges az új eszközök használhatának elsajátításához. Menet közbeni változás a specifikációban, illetve teszttervben: Kimagaslóan a legmagasabb valószínűséggel előforduló kockázatok. Gyakori, hogy az ügyfél idő közben gondolja meg, hogy egy bizonyos (vagy akár több) modult, komponenst mégsem úgy szeretne megvalósíttatni, ahogy azt előzetesen leírta a specifikációban. Ahhoz, hogy ezeket a változásokat mielőbb

24 kezelhessük, nagyon fontos a folyamatos elemzés (monitoring) és a folyamatos felülvizsgálatok (review-ek), különösképpen igaz ez a specifikációra, hiszen az mindennek az alapja. Kezelése nagy változtatások esetében a csapat bővítésével (és ebből kifolyólag a munkatempó növelésével), illetve kisebb változások esetében a csapat újrafelosztásával történik. A teszttervben történő változások kezelése pedig a teszt menedzser feladata, legyen az újraütemezési, újratervezési, vagy egyéb más feladat. Contingencies A kontingenciák (azaz előre nem látható kiadások) valószínűségének becslése jóval nehezebb feladat, mint a kockázatoké. Általában az mondható el róluk, hogy csekély valószínűséggel előforduló olyan események, amelyek nem feltétlenül szakmai jellegűek, azonban mégis hátráltatják, vagy akár időszakosan megállíthatják a tesztelési folyamatot. Azonban a teszt menedzsernek ilyen esetekkel is számolnia kell, és felkészültnek kell rájuk lenni (persze amennyire lehet, hiszen ebből számtalan fajta létezik, és tervezéskor, felkészüléskor nem mindegyik jut eszébe). Kezelésük is sokrétű lehet. Itt csak a hatáskörük szempontjából, csoportosítva beszélünk róluk. Minden technikai eszközt érintő kontingencia: Előfordulhat például, hogy bizonyos időre teljes áramszünetet kapunk. Ekkor a teljes munkafolyamat megbénul. Valószínűsége igen kicsi, azonban ha a cég anyagi lehetőségei lehetővé teszik, könnyen kezelhető, vezeték nélkül (pl: laptopok) számítógépek biztosításával, illetve az adatok bizonyos (rövid) időközönként való mentésével, így a munka biztosítottan onnan folytatódhat, ahol abbahagyták (leszámítva esetleg pár perces rollbacket). Továbbá előfordulhat, hogy külső hacker támadások érik a cég központi rendszerét. Ennek kezelése a karbantartók (adminisztrátorok) felelőssége, hogy biztosítsák a rendszerbiztonságot és a rendelkezésre állást. Nem minden technikai eszközt érintő kontingencia: Egy-egy eszköz meghibásodása, önmagától, vagy valamilyen munkahelyi baleset következtében (Például takarítás közben folyadék kerül a gépházba). Kezelésük, ha kevesebb, mint tíz számítógépről van szó, új eszközök

25 vásárlásával történik. Több gép esetén mérlegelni kell anyagi szempontból, hogy új eszközöket vásároljon a cég, illetve megkérjen egy külső, outsourcing céget a tesztelési feladatok elvégzésére. Utóbbinál azonban további kockázatokra is kell számítani, hogy esetlegesen a külsős cég félreértelmezi a specifikációt, újratervezi a teszt eseteket, és ezzel elcsúszik az ütemezés, stb. Ez esetben fontos, hogy a külső cég, akihez fordulunk, bizalmas partnercégünk legyen a projekt tesztelési folyamata során. Approval A folyamatban az alábbi stakeholderek jóváhagyása szükséges a fontosabb mérföldkövek lezárásához, az eredmények, átadott anyagok elfogadásához: - A fejlesztőcsapat - A Szegedi Tudományegyetem kijelölt képviselői - A projekt fejlesztésében részt vevő oktatók - A rendszer leendő adminisztrátorai - Az ETR üzemeltetésének képviselője - A bérelszámolási részleg képviselője A folyamatban eleinte csak a fejlesztőcsapat, az adminisztrátorok és a projektben résztvevő oktatók jelenléte szükséges, egészen a tervezés lezárulásáig, ők együttesen rendelkeznek azokkal az információkkal, amely a megfelelő tervezéshez, design-hoz és esetspecifikációhoz kell. Miután megkezdődik a tesztelés, a konzultációk célja pedig a tesztelési eredmények értékelése lesz, a felsorolt stakeholderek mindegyikére szükség van ahhoz, hogy a fennhatóságuk alá tartozó rész tesztelésének helyességét, a tesztelési eredményeket véleményezhessék, elfogadhassák, esetleg javaslatokat tegyenek a tesztelés további menetére - az ETR és bérelszámolási részleg képviselőinek jóvá kell hagyniuk a rendszereikhez tartozó integrációs tesztek eredményét és minőségét, az egyetem képviselőjének a minőségi metrikákat, a rendszerben és a tesztelés során az egyetem szabályzatának megfelelő jogkezelést, az adminisztrátoroknak, a fejlesztőcsapatnak és az oktatóknak pedig értelemszerűen az incidens reportokat, felfedezett hibákat,

26 hiányosságokat, a a javaslatokat arra, hogy egyes részeket már ne teszteljünk tovább. A tesztelés csak akkor tekinthető lezártnak, ha a tesztek sikerességét minden fent említett stakeholder elfogadta, és jóvá hagyták a lezáró folyamatok indítását!