Brachmann Ferenc PTE-TTK/KTK 2009

1. A szoftverfejlesztési folyamatok, konfigurációkezelés, tesztelés és követelménykezelés minőségbiztosítása Brachmann Ferenc PTE-TTK/KTK 2009

2. Szoftverfejlesztési folya-matok minőségbiztosítása • A szoftverminőség összetevői • A szoftverminőség „piaci” megfogalmazása • Minőségi profil kialakítása • Szoftverminőségi modellek • A szoftverfejlesztés folyamatának minősége • Szoftverfolyamat-fejlesztési modellek

3. Szoftverfejlesztési folya-matok minőségbiztosítása • A tapasztalat azt mutatja, hogy a szoftverben hibák lehetnek. • Miért vannak hibák a szoftverben? • Komplex feladatok elvégzésénél az emberek követnek el hibákat • Tapasztalt programozók átlagban minden 10 forrássorban vétenek 1 hibát • Ezen hibák felét a fordításkor kijavítják • A tesztelés során további hibák is kijavulnak, de a hibák 15%-a bent marad az ügyfélnek való átadáskor

4. Szoftverfejlesztési folya-matok minőségbiztosítása • A szoftverminőség összetevői • Termék • Folyamatok • Erőforrások • Definíció • Minőségi attribútum • Mérőszám

5. Szoftverfejlesztési folya-matok minőségbiztosítása • Mitől függ a szoftverminőség definíciója? • A minőséget értékelő személyétől / nézőpontjától / értékrendjétől • Felhasználó …érdekli: a szoftver használata, a szoftver teljesítménye, a használatának következményei (pl. funkcionalitás, megbízhatóság, hatékonyság, használhatóság, hordozhatóság) ...nem érdekli a szoftver belső szerkezete sem az, hogy hogyan fejlesztették

6. Szoftverfejlesztési folya-matok minőségbiztosítása • Mitől függ a szoftverminőség definíciója? • A minőséget értékelő személyétől / nézőpontjától / értékrendjétől • Fejlesztő …a köztes termék-minőség, és a végtermék minősége (karbantarthatóság, tesztelhetőség...) • Menedzser …érdekli a minőség, átfogóan , a menedzsment szempontjából történő minőségjavítás (csúszások, költségtúllépések kiküszöbölése). … nem érdeklik specifikus minőségi attribútumok

7. Szoftverfejlesztési folya-matok minőségbiztosítása • Mitől függ a szoftverminőség definíciója? • A szoftvergyártás típusától • Rendszer típusától / szoftver alkalmazási területétől • Üzletpolitikától

8. Szoftverfejlesztési folya-matok minőségbiztosítása • A szoftverminőség „piaci” megfogalmazása • „Jó” a szoftver, ha: • tetszik a felhasználónak, kielégíti az igényeit, • azt csinálja, amit a felhasználó szeretne... • időben, olcsón elkészül • az átadáskor stabilan működik • kevés hibát tartalmaz...

9. Üzleti folyamat Vevő / felhasználó Szoftver termék Minőségi profil kialakítása Minőségi jellemzők / attribútumok Lefordítási folyamat Minőségi profil

10. Minőségi profil kialakítása • A fejlesztőnek és felhasználónak közösen kell kialakítania • A minőségi profil tartalmaz • folyamatra • termékre • erőforrásra vonatkozó minőségi attribútumokat

11. Minőségi profil kialakítása • Például: • A szoftver készüljön el időre, ne lépje túl a szerződésben szereplő árat, használjon a felhasználónál meglévő technológiát • Ha a szoftvertől emberi életek függhetnek: fontos az integritás, megbízhatóság, helyesség, ellenőrizhetőség • Tartós „fogyasztási cikk”esetében fontos, hogy karbantartható, bővíthető , könnyen kezelhető, tanulható, jól dokumentált, „szép” felhasználói felületű legyen

12. GQM ISO 9126 (Boehm, McCall)... Jellemzők Mérőszám ISO 9001:2000 CMM SPICE CMMI ISO 15504 TSP, PSP Minőségi attribútum Definíció Objektumok Folyamat Termék Erőforrás PM módszertanok People CMM Weinberg... Szoftverminőségi modellek

13. accuracy suitability functionality interoperability compliance security maturity fault tolerance reliability recoverability availability understandability usability learnability quality in use operability time behaviour efficiency resource utilisation analysability effectiveness changeability maintainability productivity stability safety testability satisfaction adaptability installability portability co-existence conformance replaceability Szoftverminőségi modellek • Szoftvertermék alapú megközelítés: • Az ISO 9126 szabvány

14. Szoftverminőségi modellek • Erőforrás alapú megközelítés • PM módszertanokban hangsúlyos • P-CMM, szervezeti modellek, team-szerepek, vezetési stílusok, ösztönzési elméletek... • Erőforrások minősége • szám szerint mennyi és milyen típusú erőforrást használtunk fel. • az emberi erőforrás szakmai tapasztalata és termelékenysége • programozó teljesítménye: megírt LOC / ember-hónap – releváns?

15. Szoftverminőségi modellek • Folyamat alapú megközelítés • PM módszertanok (pl. PRINCE, PROPS, Ideal, BPMM...) • Tervezési, fejlesztési módszertanok (pl. RUP, SSADM...)

16. Szoftverminőségi modellek • Folyamat alapú megközelítés • Folyamatok minősége • tervezett és tényleges befejezés, ráfordítás, költség, projekt egészére és feladatokra • tesztelési folyamat időtartama • a tesztelés során megtalált hibák száma és súlyossága • hibasűrűség egy modulban: hibák száma / modul mérete • hibamegtalálási hatékonyság: megtalált hibák száma / összes hibák száma • követelmények stabilitása: kezdeti követelmények száma / összes követelmény száma

17. Szoftverminőségi modellek • ISO 9001:2000 • CMM : Capability Maturity Model • SPICE / ISO 15504 (Software Process Improvement and Capability dEtermination) • CMMI: Capability Maturity Model Integration

18. 5 Javításra felhasznált mennyiségi visszacsatolás Folyamat változás menedzsment Technológia változás menedzsment Hibamegelőzés Termelékenység és ciklus idő javítása 4 A hatékonyság, hatásosság, termelékenység és minőség mennyiségi biztosítása Szoftver minőség menedzsment Mennyiségi folyamat menedzsment A termelékenység és a ciklusidő javulása 3 A leghatékonyabb módszerek dokumentáltak és minden projektben használtak Kölcsönös szemlék Csoportok közötti koordináció Szoftver termék fejlesztés Integrált szoftver menedzsment Képzési terv Szervezeti szintű folyamatok meghatározása Odafigyelés a folyamatokra A termékminőség lényeges javulása 2 Hatékony módszerek léte Szoftver konfigurációkezelés Szoftver minőségbiztosítás Szoftver alvállalkozók kezelése Szoftver projekt követés & felügyelet Szoftver projekt tervezés Követelmények menedzsmentje A projekt tervezés és vezetés megfelelő 1 A projektek tipikusan átlépik az idő- és költségkeretet Capability Maturity Model

19. A SPICE modell Folyamat érettségi szintek Folyamatok 5. Optimalizált 4. Jósolható • Vevővel-értékesítővel kapcs. • Fejlesztési • Támogató • Menedzsment • Szervezeti 3. Meghatározott 2. Menedzselt 1. Végrehajtott 0. Nem létező

20. CMMI: CapabilityMaturityModelIntegration

21. CMMI: CapabilityMaturityModelIntegration

22. Választás a modellek között • ISO 9001:2000 – piaci alapkövetelmény, szükségszerűség • (+ szakirányú szabvány, pl. orvosi, autóipari...) • Erre épülhet rá pl. a CMM vagy CMMI • CMM – 2005 decemberig auditálták • CMMI – folyamatosan auditálják

23. Választás a modellek között • Választás a CCMI elemei között • Függ a vállalat céljaitól, korábbi tapasztalatától • Lépcsős vagy folytonos? • Folytonos modell • könnyen tanítható, nehezebben használható • Lépcsős modell • nehezen tanítható, könnyebben használható • Mindenképpen a nekünk megfelelőt kell választani!

24. A szoftver tesztelése során vallott misszió #1 • Gyorsan felfedezzük a fontos programhibákat • Általános kulcsunk legyen a termék minőségének megállapításához • Igazoljuk, hogy a termék megfelel bizonyos standardoknak • A felhasználók is hozzájáruljanak a termék minőségének és tesztelhetőségének javításához

25. A szoftver tesztelése során vallott misszió #2 • A tesztelési folyamat feleljen meg bizonyos "számonkérhetőségi" standardoknak • Fejlessze a felhasználókat is a tesztelésben és a tesztelőkkel való együttműködésben • Bizonyos előre meghatározott módszerek és szabályok érvényesüljenek a tesztelés során • Elősegítse a terméktámogatás költségének megállapítását és ellenőrzését

26. A szoftver tesztelése során vallott misszió #3 • Segítse a felhasználókat munkafolyamataik javításában • A munka a lehető legkisebb indokolt költséggel, a lehető legrövidebb idő alatt, • "mellékhatások" nélkül készüljön el • Együttműködés alakuljon ki a programozókkal • Szinte mindent megkérdőjelezzenek, de ne kürtöljenek ki mindent azonnal a külvilágba • A sikertelen dolgokra koncentráljanak annak érdekében, hogy a felhasználó a sikert érzékelje • Mindent megtegyenek annak érdekében, hogy felhasználók elégedettek legyenek

27. A teszteléssel nem biztosítjuk a minőséget • Viszonylag könnyű arra gondolni, hogy a tesztelők a minőség őrei • Azonban a minőség a termék készítőitől származik • Missziónk nagy része arra irányul, hogy a készítők foglalkozzanak a minőséggel és hatékonyabban, mint egyébként tennék • Amennyiben mi végezzük a tesztelést, csoportunk "minőségbiztosítási" csoportnak is nevezhető • Teszt eredményeink és hibalistáink valóban elősegítik a termék minőségének javítását, azonban ez a javulás nem csak a tesztelők érdeme, hanem az egész munkacsoport munkájának az eredménye

28. A "nem a mi problémánk" kérdése a tesztelés során • A tesztelés komplex folyamat és tevékenység, amely szorosan kapcsolódik más tevékenységekhez. Ennek ellenére egyesek szívesen leszűkítenék a tesztelés folyamatát a terméknek a tervtől való eltéréseire • Érdemes ennél sokkal szélesebb értelemben felfogni a tesztelést • A tesztelés valójában foglalkozik a következőkkel • Használhatóság • mi szükséges a programhoz, futtatásához • adatok minősége • program támogathatósága • melyek mind ugyancsak a "mi problémánk"

29. Jelentésre és kijavításra érdemes programhibák #1 • A programhibák megzavarják a felhasználókat és csökkentik a szoftver iránti bizalmukat • A gyakori programhibák a következők: • Helyesírási hibák • Képernyő formázási hibák • Egérnyom (kis foltok, nyomok jelennek meg az egér mögött mozgatása során) • Számítási hibák • Az ábrák, grafikonok nem megfelelő méretűek

30. Jelentésre és kijavításra érdemes programhibák #2 • Hibák a képernyőre hívható segítségben • Menüpontok, amelyek nem szürkülnek el, amikor kellene, illetve elszürkülnek, amikor nem kellene • Nem működő billentyűkombinációk • Helytelen hibaüzenetek • Szélső értékek (túl nagy vagy túl kicsi számok) helytelen kezelése • Időbeállítások, időkorlátozások helytelen működése • Egyéb hibák

31. Gondolkodjunk tesztelőként • A jó tesztelők technikai szempontból, kreatívan, kritikusan és gyakorlatiasan gondolkodnak • Valamennyi gondolkodási típusnak jelentősége van a tesztelés során. Ezek: • Technikai gondolkodás • Kreatív gondolkodás • Kritikai gondolkodás • Gyakorlatias gondolkodás

32. Implicit és explicit specifikációk #1 • Specifikáció alatt a program működésének és peremfeltételeinek meghatározását értjük • Az explicit, kimondott, leírt specifikáció igen hasznos, mert a készítők vagy a felhasználók által elfogadott követelményeket, kritériumokat önt formába egyértelműen

33. Implicit és explicit specifikációk #2 • Az implicit specifikáció viszont nincs egyértelműen elfogadva vagy leírva a készítők vagy a felhasználók által • Az implicit specifikáció gyakran nem annak alapján keletkezik, hogy a program legjobb legyen a felhasználók szempontjából, hanem sokszor a meggyőző ereje vagy a hihetősége határozza meg.

34. Implicit és explicit specifikációk #3 • Nemegyszer az implicit specifikációknak alig van közük a kifejlesztendő termékhez. Az implicit specifikációknak számos formája létezik: • Hasonlítás versengő termékekhez • Hasonlítás kapcsolódó termékekhez • Hasonlítás ugyanazon termék korábbi verzióihoz • A fejlesztés során váltott e-mailek tartalma • A fogyasztók által tett észrevételek, megjegyzések •  Saját jól megalapozott tapasztalataink

35. Heurisztikák alkalmazása a tesztelés során #1 • A heurisztika lényegében ökölszabály, hüvelykujjszabály • Célja, hogy képzett emberek által jóváhagyott módon cselekedjünk új helyzetben • Jóllehet a heurisztika nem biztosítja a helyes cselekvést kritikus helyzetekben, mindazonáltal • időnként jó szolgálatot tehet

36. Heurisztikák alkalmazása a tesztelés során #2 • Példák heurisztikák alkalmazására • Szélső értékek tesztelése • Valamennyi hibajelzés tesztelése • Beállítások tesztelése • Futtatási teszt

37. A tesztelés tárgyára irányuló technikák #1 • A tesztelés tárgyára irányuló technikák a termékre koncentrálnak • Számos technika áll rendelkezése, amelyek különbözőképpen csoportosíthatók attól függően, hogy mire kívánjuk használni ezeket

38. A tesztelés tárgyára irányuló technikák #2 • Például a az egyes program tulajdonságok integráltságának tesztelése termék orientált, amennyiben azt vizsgáljuk, hogy minden funkció megfelelően működik-e a többi funkcióval együtt (kombinációban) • Ugyanez probléma orientált, amennyiben van valamilyen elképzelésünk arról, hogy miért van valamilyen hiba, és ennek keletkezését nyomon szeretnénk követni. Lehet például, hogy az egyik függvénynek vagy szubrutinnak nem vagy nem jól adjuk át az értékeket

39. A tesztelés tárgyára irányuló technikák #2 • Működés tesztelése • Minden egyes működési elem, függvény, szubrutin tesztelése egyenként • Az elemek, függvények, szubrutinok lehetőleg teljes körű tesztelése annak megállapítása érdekében, hogy azok valóban jól működnek • Fehér doboz függvény tesztelés • Ezt rendszerint egység tesztelésnek is nevezik, és rendszerint az egyes, forráskódban megjelenő önálló függvények vagy szubrutinok tesztelését jelenti

40. A tesztelés tárgyára irányuló technikák #3 • Fekete doboz függvény tesztelés • Ennek során a parancsokra és olyan dolgokra, tulajdonságokra figyelünk elsősorban, amelyeket a felhasználó ki tud választani, vagy amellyel elő tud idézni valamilyen működést • Ajánlott a függvény tesztelés elvégzése mielőtt bonyolultabb tesztek során több függvény együttes tesztelését végeznénk el • Összetett tesztelés során az első hibás függvény leállítja a program futását, és esetleg nem állapítható meg egykönnyen, hogy melyik függvény volt a hibás

41. A tesztelés tárgyára irányuló technikák #4 • Tulajdonságok és függvények integráltságának tesztelése •  Ennek során elemezzük, hogy a tulajdonságok, függvények megfelelően kapcsolódnak-e egymáshoz, integrált-e a rendszer • Menü vizsgálat • Végig kell menni valamennyi menüponton a grafikus felhasználói felületen és minden választási lehetőséget kipróbálni

42. A tesztelés tárgyára irányuló technikák #5 • Domain tesztelés • A domain olyan (matematikai) halmaz, amely magában foglalja egy változó, illetve függvény valamennyi lehetséges értékét • A domain tesztelés során azonosítjuk a változókat és függvényeket • A változók bemeneti és kimeneti változók egyaránt lehetnek • Minden egyes változóhoz a lehetséges változókat ekvivalencia osztályokba soroljuk és kiválasztjuk belőlük kis részhalmazukat, rendszerint a szélső értékek környékén a teszteléshez

43. A tesztelés tárgyára irányuló technikák #6 • Ekvivalencia osztály tesztelés • Az ekvivalencia osztály a változó azon értékei, amelyeket ekvivalensnek tekintünk • A teszt-esetek ekvivalensek, ha úgy gondoljuk, hogy • Valamennyien ugyanazt tesztelik • Ha az egyikkel kapcsolatban programhiba van, akkor valószínűleg a másikkal kapcsolatban is • Ha az egyikkel kapcsolatban nincs programhiba, akkor valószínűleg a másikkal kapcsolatban sincs

44. A tesztelés tárgyára irányuló technikák #7 • Határoló érték tesztelés • Az ekvivalencia osztály értékek halmazából áll • Ha le tudjuk képezni ezeket az értékeket a számegyenesre, akkor a határoló értékek az osztály legkisebb és legnagyobb értékei • A határoló érték tesztelésnél ezeket az értékeket teszteljük, továbbá a közelükben fekvő további értékeket is

45. A tesztelés tárgyára irányuló technikák #8 • Állapot tesztelés • A program működése közben egyik állapotából másik állapotába mehet át • Adott állapotban bizonyos bemenő értékek elfogadhatóak, míg másik állapotban nem. Például bizonyos mezők akár el is szürkülhetnek, vagy nem lehet oda adatot bevinni, míg máskor igen • A helyes érték bevitelekor a program tesz valamit, és nem tesz olyat, amit nem tehet meg • Az állapot tesztelés során a tesztelő végigmegy a programon és az ilyen típusú működéseket teszteli körültekintően

46. A tesztelés tárgyára irányuló technikák #9 • Specifikáció alapú tesztelés • Ebben az esetben a tesztelés azoknak a kívánalmaknak a tesztelésére vonatkozik, amelyeket a programmal szemben támasztottak • Ezeknek a kívánalmaknak a tesztelése általában igen/nem típusú válasszal fejeződik be • Ezek a kívánalmak rendszerint megjelennek a program dokumentációban, kézikönyvben, a piacra kerülést kísérő egyéb dokumentumokban, hirdetésekben, valamint a technikai támogatásra vonatkozó leírásokban, amelyeket a felhasználókhoz eljuttatnak • Követelmény alapú tesztelés • A követelmény alapú tesztelés során kitérnek mindazon szempontok ellenőrzésére, amelyek szerepelnek a dokumentumokban