Kompetens Softver Tesztelés a Gyakorlatban (CoSTiP) - pilot. 5. Tesztmenedzsment

Átírás

1 Kompetens Softver Tesztelés a Gyakorlatban (CoSTiP) - pilot 5. Tesztmenedzsment

2 5. Tesztmenedzsment 5.1 Tesztelő szervezet 5.2 Teszttervezés és becslés 5.3 A teszt előrehaladásának felügyelete és irányítása 5.4 Konfiguráció menedzsment 5.5 Kockázat és tesztelés 5.6 Incidensmenedzsment

3 5.1 Tesztelő szervezet Tesztelő szervezet és a függetlenség A tesztvezető és a tesztelő feladatai

4 5.1.1 Tesztelő szervezet és a függetlenség (1) A függetlenség szintjei a tesztelő szervezetben elfoglalt helye szerint: a fejlesztő és a tesztelő ugyanaz a személy a tesztelő a fejlesztőtől eltérő személy a fejlesztői csoportból független tesztelői csapat a fejlesztőkkel azonos felső irányítással belső vagy külső felhasználói tesztelők szaktesztelők (általában külső) pl. biztonsági tesztelő, egyéni megbízással külső tesztelői szervezet

5 5.1.1 Tesztelő szervezet és a függetlenség (2) Mik a függetlenség előnyei? elfogulatlan más hibákat lát meg nincsenek (vagy mások) a témával kapcsolatos előfeltevései objektíven tudja mérlegelni az esetlegesen hibás vezetői döntéseket is

6 5.1.1 Tesztelő szervezet és a függetlenség (3) Mik a függetlenség hátrányai? elszigetelődés, kívülállókkal szembeni ellenszenv információ fő áramától való távolság (a nem dokumentált igények ismeretének hiánya) a fejlesztők kevésbé érzik a felelősnek magukat a minőségi programozás iránt (hisz a tesztelő majd átnézi)

7 5.1.1 Tesztelő szervezet és a függetlenség (4) Milyen tulajdonságú embereket válasszunk a tesztelői csapatba, ha erre lehetőségünk van? Ismerje (valaki) a szoftver felhasználói szakmai területét (domain knowledge), hogy meg lehessen érteni a valódi igényeket, és szakmai hangsúlyokat Ismerje (valaki) az alkalmazott technológiát, annak lehetőségeit és problémáit Ismerje (valaki) a tesztelési technikákat, eszközöket, szabványokat Legyen a csapatban csapat orientált, munka orientált, cél orientált személyiség is.

8 5.1.2 A tesztvezető és a tesztelő feladatai (Tesztvezető 1) Tipikus tesztvezetői feladatok: A tesztstratégia és terv koordinálása a projektmenedzserekkel és másokkal. A projektekhez tartozó tesztstratégia, illetve a szervezeti szintű tesztelési irányelvek elkészítése vagy felülvizsgálata. A teszt tervezése a tesztelési szempontok figyelembevételével és a tesztcélok, kockázatok ismeretében ide tartozik a tesztelési megközelítések kiválasztása, a tesztelés időtartamának, ráfordításainak és költségeinek becslése, erőforrások beszerzése, tesztszintek és ciklusok meghatározása, incidens menedzsment tervezése.

9 5.1.2 A tesztvezető és a tesztelő feladatai (Tesztvezető 2) Tesztelő munkájának előkészítése: A tesztek specifikációjának, előkészítésének, kivitelezésének és végrehajtásának kezdeményezése, a teszteredmények monitorozása és a kilépési feltételek ellenőrzése. Változások kezelése: A tervezés átalakítása a teszteredmények és a tesztelés előrehaladása alapján (amit gyakran állapotjelentésekben dokumentálnak), a problémák kiküszöböléséhez szükséges lépések megtétele. A tesztver megfelelő konfiguráció menedzsmentjének létrehozása a nyomonkövethetőség érdekében. Megfelelő mutatószámok bevezetése a teszt-előrehaladás mérésére, valamint a tesztelés és a termék minőségének értékelésére.

10 5.1.2 A tesztvezető és a tesztelő feladatai (Tesztvezető 3) Annak eldöntése, hogy mit, milyen mértékig és hogyan kell automatizálni. A teszttámogató eszközök kiválasztása és az eszközök használatával kapcsolatos képzés megszervezése a tesztelők részére. Döntéshozatal a tesztkörnyezet kialakításáról. Összefoglaló tesztjelentés készítése a teszt során gyűjtött információk alapján.

11 5.1.2 A tesztvezető és a tesztelő feladatai (Tesztelő 1) Tipikus tesztelői feladatok lehetnek: Teszttervek felülvizsgálata és részvétel a kidolgozásukban. Felhasználói követelmények, specifikációk és tesztelhetőségi modellek elemzése és felülvizsgálata. Tesztspecifikációk készítése. Tesztkörnyezet kialakítása (gyakran együttműködésben a rendszer adminisztrációval és a hálózat menedzsmenttel). Tesztadatok előkészítése, felvétele. Tesztek kidolgozása minden tesztszinten, tesztek végrehajtása és naplózása, eredmények értékelése, az elvárt eredményektől való eltérések dokumentálása.

12 5.1.2 A tesztvezető és a tesztelő feladatai (Tesztelő 2) Szükség esetén tesztelési adminisztrációs vagy menedzsment eszközök, valamint tesztfelügyeleti eszközök használata. Tesztek automatizálása (ebben támogatást nyújthat egy fejlesztő vagy egy tesztautomatizálási szakértő). Komponensek és rendszerek teljesítményének mérése (ha lehetséges). Mások által kifejlesztett tesztek felülvizsgálata.

13 5.2 Teszttervezés és becslés Teszttervezés Teszttervezési tevékenységek Belépési feltételek Kilépési feltétel A tesztbecslés Tesztelési megközelítések, tesztstratégiák

14 5.2.1 Teszttervezés A tervezést dokumentálhatják fő teszttervben, vagy tesztelési szintekhez tartozó teszttervekben A tervezést befolyásolja: szervezet tesztstratégiája, a teszt tárgya, céljai, kockázatok, megkötések, kritikusság, tesztelhetőség, elérhető erőforrások A teszttevékenységekből kapott visszajelzések alapján felismerhető a kockázatok változása, és ennek megfelelően alakítható a tervezés.

15 5.2.2 Teszttervezési tevékenységek (1) A teszt tárgya, kockázatok és célok meghatározása. A tesztelés általános megközelítésének definiálása, ezzel együtt a tesztszintek, valamint a bemeneti és kilépési feltételek meghatározása. A teszttevékenységek beépítése a szoftver életciklusába. Beszerzés, beszállítás, fejlesztés, működtetés és karbantartás. Döntéshozatal arról, hogy mit tesztelünk, mely szerepkörbe tartozók hajtják végre a teszttevékenységeket, és ezen tevékenységeket hogyan kell végrehajtani, hogy fogják kiértékelni a teszteredményeket.

16 5.2.2 Teszttervezési tevékenységek (2) A tesztelemzési és a -tervezési tevékenységek ütemterve. A tesztmegvalósítás, -végrehajtás és -értékelés ütemterve. Erőforrások hozzárendelése a definiált tevékenységekhez. A tesztdokumentáció mennyiségének, részletességének, struktúrájának meghatározása, minták megadása. Mérőszámok kiválasztása a tesztelőkészítés és - végrehajtás felügyeletéhez és irányításához, a hibák és a kockázatok kezeléséhez. A teszteljárások részletességének meghatározása annak érdekében, hogy elegendő információ álljon rendelkezésre a tesztek ismételt előkészítéséhez és végrehajtásához

17 5.2.3 Belépési feltételek belépési feltétel: általános és speciális feltételek halmaza, amely engedélyezi egy adott feladat végrehajtását. Az a cél, hogy ne indítsunk olyan feladatokat, amelyek több elvesztegetett ráfordítást jelentenének, mint az elbukó belépési feltételek kijavítása [Gilb és Graham] entry criteria A tesztkörnyezet rendelkezésre állása. A teszteszközök rendelkezésre állása a tesztkörnyezetben. A tesztelhető kód rendelkezésre állása. A tesztadatok rendelkezésre állása.

18 5.2.4 Kilépési feltétel (1) kilépési feltétel: általános és speciális feltételek halmaza, amelyet minden érintettel egyeztetve egy folyamat hivatalos befejezési feltételének tekintünk. A célja, hogy megakadályozzuk az olyan feladatok befejezettnek tekintését, amelyeknek még vannak függőben levő, be nem fejezett részei. A kilépési feltételeket a tesztelés leállításának tervezéséhez és jelentéséhez használjuk. exit criteria

19 5.2.4 Kilépési feltétel (2) Alapossági mérés, mint kód-, funkcionalitásvagy kockázat-lefedettség. Hibasűrűség vagy megbízhatóság becslése. Költség. A fennmaradó kockázatok, mint például a javítatlan hibák, tesztlefedettség hiánya bizonyos területeken. Ütemtervek, melyek lehetnek például a piacra kerüléssel kapcsolatosak

20 5.2.5 A tesztbecslés (1) tesztbecslés: a tesztelés különböző vonatkozásaihoz tartozó értékek becslése (pl. ráfordított idő, befejezés dátuma, költségek, tesztesetek száma), amely akkor is használható, ha az adatok nem állnak teljes mértékben rendelkezésre, vagy bizonytalanok. test estimation A mérőszám alapú megközelítés: a tesztelési ráfordítás becslése régebbi, vagy hasonló projektek mérőszámai alapján, vagy tipikus értékek alapján. A szakértő alapú megközelítés: a feladatok becslése az azokat ismerő személy vagy szakértők becslése alapján történik (wbs).

21 5.2.5 A tesztbecslés (2) A ráfordítást befolyásoló termékjellemzők: a specifikáció és más, a tesztelési modelleknél felhasznált információk (pl.: tesztbázis) minősége, a termék mérete, a problémakör komplexitása, megbízhatósági és biztonsági követelmények, dokumentációra vonatkozó követelmények.

22 5.2.5 A tesztbecslés (3) A ráfordítást befolyásoló fejlesztési folyamatjellemzők: a szervezet stabilitása, az alkalmazott eszközök, a tesztfolyamat, a résztvevő személyek szaktudása és az időtényező. A ráfordítást befolyásoló, teszt eredménnyel kapcsolatos tényezők: a hibák száma és a szükséges átdolgozás mértéke

23 5.2.6 Tesztelési megközelítések, tesztstratégiák (1) tesztstratégia: magas szintű dokumentum, amely a végrehajtandó tesztszinteket írja le, valamint azok részleteit tartalmazza a szervezetre vagy a programra (egy vagy több projektre) vonatkozóan. test strategy tesztelési megközelítés: a tesztstratégia megvalósítása egy konkrét projektre. Jellemzően a projekt céljain és a kockázatelemzésen alapuló döntéseket, a tesztfolyamatok kiindulópontjait, az alkalmazandó műszaki teszttervezési technikákat, belépési és kilépési kritériumokat valamint a teszt fajtáit tartalmazza. test approach

24 5.2.6 Tesztelési megközelítések, tesztstratégiák (2) Analitikus megközelítések (risk or req. analysis) Modell alapú megközelítések (mathematical models) Módszeres megközelítések Folyamat- vagy szabvány szerinti megközelítések Dinamikus és heurisztikus megközelítések Tanácsadói megközelítések Regressziós elkerülő megközelítéseknél

25 Átvettük: Teszttervezés és becslés Teszttervezés Teszttervezési tevékenységek Belépési feltételek Kilépési feltétel A tesztbecslés Tesztelési megközelítések, tesztstratégiák

26 5.3 A teszt előrehaladásának felügyelete és irányítása A teszt előrehaladásának felügyelete Tesztjelentés Tesztirányítás

27 5.3.1 A teszt előrehaladásának felügyelete A teszt felügyeletének célja, hogy visszajelzéseket adjon a teszttevékenységekről. A felügyelet alá vont információ manuálisan vagy automatizáltan gyűjthető alkalmazható a kilépési feltételek, például a lefedettség mérésére. A tervezett ütemtervhez és költségvetéshez képest történt előrehaladás értékelésére metrikákat is alkalmazhatnak.

28 5.3.1 A teszt előrehaladásának felügyelete (tesztmetrikák) A tesztesetek előkészítésében végzett munka százalékosan (vagy hány százaléka készült el a tervezett teszteseteknek). A tesztkörnyezet előkészítésében végzett munka százalékosan. Teszteset végrehajtás (pl. futtatott/nem futtatott tesztesetek száma, sikeres/sikertelen tesztesetek). Információ a hibákról (pl. hibasűrűség, megtalált és javított hibák, meghibásodási ráta, újratesztelési eredmények). A követelmények, a kockázatok vagy a kód tesztlefedettsége. A tesztelők szubjektív véleménye a termékről. A tesztelés mérföldköveinek dátumai. A tesztelés költségei, ahol számítandó a következő hiba megtalálásának vagy a következő teszt futtatásából származó nyereség aránya a befektetett költséghez képest.

29

30

31

32

33

34

35 5.3.2 Tesztjelentés (tartalma) Összefoglalja a teszttel kapcsolatos információkat: Mi történt a teszt adott szakaszában, mint például a kilépési feltétel teljesülésének időpontja. Feldolgozott információk és metrikák az elkövetkező lépésekkel kapcsolatos ajánlások és döntések elősegítésére, mint például elemzés a fennmaradó hibákról, a további teszt gazdasági előnyei, jelentősebb kockázatok, a tesztelt szoftver megbízhatósági szintje. Szoftverteszt Dokumentáció Szabvány (IEEE 829)

36 5.3.2 Tesztjelentés (Gyűjtendők) A metrikákat gyűjteni kell az adott tesztszint folyamán és végén, a következők elemzése érdekében: Megfelelőek-e az adott tesztszint célkitűzései. Megfelelőek-e az alkalmazott tesztelési megközelítések. A teszt hatékonysága a célkitűzésekre való tekintettel.

37 5.3.2 Tesztjelentés Időközi tesztelési állapotjelentés (Level Interim Test Status Report) : 1) Bevezetés (Introduction) 1.1) Dokumentum azonosító (Document identifier) 1.2) Hatáskör (Scope) 1.3) Hivatkozások (References) 2) Az állapotjelentés részletei (Details of the Level Interim Test Status Report) 2.1) A tesztelés állapotának összegzése (Test status summary) 2.2) A tervtől való eltérések (Changes from plans) 2.3) Tesztelési állapot mutatók (Test status metrics) 3) Általános (General) 3.1) Dokumentum története (Document change procedures and history)

38 5.3.2 Tesztjelentés (LTR) Tesztjelentés (Level Test Report) : 1) Bevezetés (Introduction) 1.1) Dokumentum azonosító (Document identifier) 1.2) Hatáskör (Scope) 1.3) Hivatkozások (References) 2) A tesztjelentés részletei (Details of the Level Test Report) 2.1) A teszteredmények áttekintése (Overview of test results) 2.2) Részletes teszteredmények (Detailed test results) 2.3) Döntések indoklása (Rationale for decisions) 2.4) Következtetések és ajánlások (Conclusions and recommendations) 3) Általános (General) 3.1) Szójegyzék (Glossary) 3.2) Dokumentum története (Document change procedures and history)

39 5.3.3 Tesztirányítás Döntéshozatal a tesztfelügyelet során nyert információk alapján. Tesztek prioritásának megváltoztatása, ha egy ismert kockázat bekövetkezik (pl. a szoftver késői kiszállítása). A teszt ütemezésének megváltoztatása a tesztkörnyezet felhasználhatóságának változása miatt.

40 Láttuk: A teszt előrehaladásának felügyelete és irányítása A teszt előrehaladásának felügyelete Tesztjelentés Tesztirányítás

41 5.4 Konfiguráció menedzsment (1) konfiguráció: a rendszer, illetve a szoftver összeállítása az alkotóelemeinek száma, jellege és kapcsolatai alapján configuration Mik lehetnek konfigurációs elemek? Milyen kapcsolatok lehetnek köztük? Hogyan tükröződik ez a tesztelési folyamatban? Miért van erre szükség?

42 5.4 Konfiguráció menedzsment (2) Mik lehetnek konfigurációs elemek? dokumentációk (követelmény, tervek, tesztelési, felhasználói) saját fejlesztésű szoftver komponensek külső fejlesztésű elemek pl. adatbázisok, web szerverek, kliens programok fejlesztő eszközök teszt adatok egyéb eszközök pl. verzió követő eszközök (GIT, SVN), tesztelő eszközök (JUnit, TestNG, SoapUI) dokumentációt segítő eszközök (TestLink, Savane)

43 5.4 Konfiguráció menedzsment (3) Milyen kapcsolat lehet ezen alkotóelemek között? együttműködés pl.: a saját fejlesztésű komponensek az adott web szerver alatt futnak, miközben egymást hívogatják és kezelik az adatbázist azonos dolognak különböző nézetei, illetve a közös tárgy pl.: egyazon komponens követelményei, tervei, megvalósított kódjai, felhasználói kézikönyve, a teszteléséhez szükséges tesztesetek, tesztadatok azonos alkotóelemnek a különböző fejlesztési állapota pl.: a különböző szoftver vagy dokumentum verziók azonos funkciójú elemek különböző igényekhez igazított változatai pl.: Windowsos-Linuxos, egyéni-üzleti, iphone- Android-Windows Phone 8

44 5.4 Konfiguráció menedzsment (4) Hogyan tükröződik ez a tesztelési folyamatban? A tesztver (tesztfolyamat során keletkezett különböző termékek) minden eleme pontosan meghatározott, verziókövetés alá vont, a benne történt változások nyomonkövethetők, az elemek úgy kapcsolódnak egymáshoz és a fejlesztési elemekhez (teszt tárgyaihoz), hogy a nyomonkövethetőség fenntartható legyen a teszt folyamán. A tesztdokumentációban egyértelmű hivatkozás található minden létező dokumentumra és szoftverelemre. (azaz nem csak a nevét, hanem minden olyan adatát is meg kell adni, ami az egyértelmű azonosításhoz szükséges pl.: a verzióját, kibocsátás dátumát, )

45 5.4 Konfiguráció menedzsment (5) Miért van erre szükség? A használt követelmény specifikáció pontos meghatározása segíti annak eldöntését, hogy elévült-e az összeállított teszteset halmaz, ill. segít a frissítésben, hisz a hangsúlyt a követelmények változására lehet helyezni. A tesztelt kód és környezet pontos meghatározása segít a jelenség reprodukálásában, ill. szemléltetésében. Kiválaszthatók az összetartozó elemek. pl. op. rendszerhez illeszkedő scriptek

46 5.5 Kockázat és tesztelés Projektkockázatok Termékkockázatok Üzleti kockázat kockázat: az a tényező, amely a jövőben negatív következményeket okozhat. Általában, mint hatás (következmény) és valószínűség jelenik meg. Risk

47 5.5 Kockázat és tesztelés (kezelése) Kockázat azonosítás: Egy listát kell írni a lehetséges kockázatokról Kockázat elemzés: Meg kell állapítani a kockázat valószínűségét és esetleges hatásának súlyosságát. Kockázat kezelése: Megfelelő akcióterv kidolgozása és szükség esetén a végrehajtása a kockázat valószínűségének, ill. lehetséges káros hatásának csökkentésére, valamint bekövetkezte esetén a kárenyhítésre. Kockázat figyelése: A kockázati tényezők folyamatos figyelése a szükséges reakciók időben történő végrehajtása miatt. (kockázat csökkentő akció beindítása vagy a terv módosítása az új feltételekhez)

48 5.5.1 Projektkockázatok (1) Szervezeti tényezők: szaktudás és munkaerő hiánya; (pl.: betegség, baleset) személyi kérdések; (pl.: szerelem) szervezeti működés problémái, mint pl. a tesztelők nem jól kommunikálják az igényeiket és a teszteredményeket; nem alkalmazzák a teszt és a felülvizsgálat alkalmával szerzett információkat (pl. nem javítják a fejlesztési és teszteljárás-folyamatokat). nem megfelelő hozzáállás vagy rossz elvárások a teszteléssel kapcsolatban (pl. nem értékelik a teszteléssel talált hibák jelentőségét).

49 5.5.1 Projektkockázatok (2) Technikai problémák (a tesztelési folyamatban): a megfelelő követelmények meghatározásával kapcsolatos problémák; a követelmények teljesíthetőségének mértéke a már létező megkötések figyelembevételével; a terv, a kód és a tesztek minősége. Beszállítói problémák: a harmadik fél nem teljesít; szerződésbeli problémák

50 5.5.2 Termékkockázatok (1) termékkockázat: a teszt tárgyához (magához a termékhez) közvetlenül kapcsolódó kockázat. product risk Ezen kockázatok enyhítése a tesztelés egyik alap feladata. Mi a teendő a termékkockázatok feltárása során? Mivel a kockázat mértéke a súlyosságától és a gyakoriságától függ, ezért a funkcionális és nem funkcionális követelményeket értékelni kell abból a szempontból, hogy a megvalósításuk hiányosságai milyen kárt okozhatnak. Illetve meg kell becsülni az egyes funkciók használatának gyakoriságát. Ezek alapján rendezni kell őket.

51 Kockázat elemzés, minta táblázat

52 5.5.3 Üzleti kockázatok Az üzleti környezet káros eseményei. Pl.: A vevő csődje (erre a tesztelésnek nincs befolyása) Új technológia megjelenése, mely elavulttá teszi a fejlesztett rendszert (Új technológiák figyelése, szükséges ismeretek megszerzése azért, hogy ha szükséges, az átállás minél gördülékenyebben menjen. Ez értelem szerűen nem csak fejlesztői, hanem tesztelői feladat is) Új versenytárs megjelenése (Ez jelenthet magasabb minőségi követelményeket vagy alacsonyabb költségvetést, ill. szűkebb határidőket)

53 5.6 Incidensmenedzsment (1) incidens menedzsment: az incidensek felismerésének, vizsgálatának, a különböző intézkedések és rendelkezések szervezésének folyamata. Magába foglalja az incidens loggolását, osztályozását és kihatásának vizsgálatát Az incidensjelentések céljai a következők: Visszajelzést nyújtani a problémáról a fejlesztők és egyéb érintettek részére, hogy el lehessen végezni a szükség szerinti azonosítást, izolálást, javítást. Biztosítani, hogy a tesztvezetők nyomon követhessék a tesztelt rendszer minőségét és a teszt előrehaladását a teszt folyamán. A tesztfolyamat javítására vonatkozó elképzeléseket kidolgozni

54 5.6 Incidensmenedzsment (2) Az incidensjelentés a következőket tartalmazhatja: Keltezés, készítő szervezet, szerző. Elvárt és valós eredmények. A tesztelem (konfigurációs elem) és a környezet azonosítása. A szoftver- vagy rendszer életciklus folyamata, amiben az incidens fellépett. Az incidens leírása, hogy lehetséges legyen a megismétlése és a megoldása, felhasználva a naplókat, adatbázis mentéseket, screenshot-okat. Hatás az érintett felek érdekeire.

55 5.6 Incidensmenedzsment (3) A rendszerre való hatás mértéke. Javítás sürgőssége/prioritása. Az incidens állapota (pl. nyitott, elhalasztott, duplikált, javításra váró, javított és újratesztelésre váró, lezárt). Következtetések, javaslatok és jóváhagyások. Globális problémák, mint például további területek, melyekre az incidens okozta változások hatással lehetnek. A változtatások története: a projektcsapat tagjainak tevékenységei az incidens izolálására, javítására, javításának ellenőrzésére. Referenciák, melyekbe beletartozik a problémát felfedő teszteset-specifikáció azonosításai

56 Költségek

57 5.6 Incidensmenedzsment (4) Severity Leírás 1 - Wish a hiba nincs hatással az üzleti folyamatokra, vagy az általa okozott működésbeli változás nem releváns 3 - Minor a hiba javításra szorul, de vagy nem érinti az üzleti folyamatokat, vagy egy nagyon kis ügyfélkört érint 5 - Normal minden olyan hiba, melynek élesbe állása az ügyfél üzletmenetét károsan befolyásolja, nagyobb ügyfélkört érint, de az ügyfél által is elfogadott workaround által az üzleti folyamatok nem sérülnek 7 - Important minden olyan hiba, melynek élesbe állása az ügyfél üzletmenetét károsan befolyásolja, nagyobb üzleti területet érint, workaround nem lehetséges 8 - Blocker minden olyan hiba, ami akadályozza a tesztelést, vagy kijavítása nélkül nem kerülhet a release élesre 9 - Security minden olyan hiba, ami az ügyféladatok szempontjából, vagy az ügyfél hálózatra nézve biztonsági kockázatot jelent

58 Mi történik a hibajeggyel?

59 Összefoglalva:Tesztmenedzsment 5.1 Tesztelő szervezet 5.2 Teszttervezés és becslés 5.3 A teszt előrehaladásának felügyelete és irányítása 5.4 Konfiguráció menedzsment 5.5 Kockázat és tesztelés 5.6 Incidensmenedzsment