Brachmann Ferenc PTE-TTK/KTK 2009 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

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

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

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

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

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

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

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...

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

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

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

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

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

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?

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...)

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

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

Capability Maturity Model A projektek tipikusan átlépik az idő- és költségkeretet 1 A projekt tervezés és vezetés megfelelő 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 Hatékony módszerek léte 2 A termékminőség lényeges javulása 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 leghatékonyabb módszerek dokumentáltak és minden projektben használtak 3 A termelékenység és a ciklusidő javulása Szoftver minőség menedzsment Mennyiségi folyamat menedzsment A hatékonyság, hatásosság, termelékenység és minőség mennyiségi biztosítása 4 Termelékenység és ciklus idő javítása Folyamat változás menedzsment Technológia változás menedzsment Hibamegelőzés Javításra felhasznált mennyiségi visszacsatolás 5

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ő

CMMI: Capability Maturity Model Integration A lépcsős megközelítés a folyamatokat 5 szervezeti érettségi szinthez (maturity levels) társítja, ezzel támogatva és vezérelve a folyamatjavítást. 1. Kezdeti (Initial) 2. Menedzselt (Managed) 3. Meghatározott (Defined) 4. Minőségileg menedzselt (Quantitatively Managed) 5. Optimalizáló (Optimizing) A folytonos megközelítés 6 képességi szintet határoz meg, bármely folyamatra 0. Hiányos (Incomplete) 1. Végrehajtott (Performed)

CMMI: Capability Maturity Model Integration CMMI lépcsős megközelítés elemek 2. Szint (projekt központú): Követelménykezelés, projekt tervezés és vezérlés, beszállítók kezelése, mérés és elemzés, termék és folyamat minőségbiztosítás, konfigurációkezelés 3. Szint (szervezet központú): Követelmények meghatározása, műszaki megoldások, termék integráció, termék ellenőrzés, termék igazoló ellenőrzése, szervezeti szintű folyamatok léte, szervezeti szintű folyamatok meghatározása, szerv szintű képzés, integrált termék menedzsment, kockázatkezelés, döntéselemzés és támogatás 4. Szint (mennyiségi kontroll): Szervezeti szintű folyamatok teljesítménye, mennyiségi projekt menedzsment 5. Szint (folytonos javítás): Szervezeti szintű innováció és bevezetés, eseti elemzés és döntéskezelés A folytonos megközelítés elemek Folyamat menedzsment Szervezeti szintű folyamatok léte , szervezeti szintű folyamatok meghatározása , szervezeti szintű képzés, szervezeti szintű folyamatok hatékonysága, szervezeti szintű innováció és bevezetés Projekt menedzsment: Projekt tervezés, projekt követés és vezérlés , beszállítók kezelése, integrált projekt menedzs-ment, kockázatkezelés, integrált csapat-építés, mennyiségi projekt menedzsment Fejlesztés: Követelmények meghatározása, követelmény-menedzsment, műszaki megoldások,termék integráció, ellenőrzés,igazoló ellenőrzés Support Konfigurációkezelés, folyamat és termék minőségbiztosítás, mérés és elemzés, integrá-cióra alkalmas szervezeti környezet , döntés elemzés és támogatás ,eseti elemzés és döntés

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

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!

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

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

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

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

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"

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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