MIÉRT KELL TESZTELNI?

Átírás

1 Unrestricted

2

3 MIÉRT KELL TESZTELNI?

4 MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak...

5 MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver

6 MIÉRT KELL TESZTELNI? Rövidebb termék életciklus

7 MIÉRT KELL TESZTELNI? A minőség mérhetővé tétele

8 MIÉRT KELL TESZTELNI? A bizalom erősítése

9 MIÉRT KELL TESZTELNI? Az ügyfél elvárásainak biztosítása

10 Validáció vs verifikáció Példa: kávéskanna tervezése Olyan kávéskannát szeretnék, amelynek segítségével kényelmesen tudok kávét tölteni a csészébe anélkül, hogy megégetném magam Author Date Page 10

11 WHY TO TEST? - Validáció vs verifikáció A kiöntő képes legyen 1 liter folyadék tárolására Legyen fedele, aminél fel lehet emelni és bele lehet tölteni a folyadékot Legyen füle, aminél fogva vinni lehet Legyen kiöntője, amin keresztül távozni tud belőle a folyadék Author Date Page 11

12 WHY TO TEST? - Validáció vs verifikáció A verifikáció sikeres, de a validálás nem! Author Date Page 12

13 WHY TO TEST? A standardoknak való megfelelés

14 MIT JELENT A MINŐSÉG?

15 MIT JELENT A MINŐSÉG? Transzcendens ( nagyon szeretem ezt a programot ) Felhasználó-alapú (megfelel a felhasználás céljának) Érték-alapú (idő-költség-scope háromszög) Gyártás-alapú (a specifikációknak való megfelelés) Termék-alapú (minőségi karakterisztikák)

16 MIT JELENT A MINŐSÉG? - TERMÉK-ALAPÚ MINŐSÉG

17 MILYEN A JÓ TESZT?

18 MILYEN A JÓ TESZT? Hatásos a gyakori use case-eket tesztel fontos/kritikus use case-eket/függvényeket tesztel a tesztkészlet a lehető legnagyobb tesztlefedettséget biztosítja Hibákat talál minél súlyosabbat minél többet minél korábban Hatékony a teszt(készlet) rövid idő alatt lefut a lehető legkevesebb erőforrást használja fel Stabil, robosztus az eredmény független a tesztkörnyezettől determinisztikus a teszt eredménye Beszédes név konvenciók, commentek visszaadja a lényegi információt az eredményről/hibáról A tesztelés minősége mérhető!

19 A TESZT HATÁSOSSÁGA - KOCKÁZAT ÉS TESZTELÉS Kockázat: potenciális probléma, ami előfordulhat Két tényezője van: bekövetkezésének esélye (valószínűség) hatása (mekkora kárt okoz) Két típusú kockázat van: Projektkockázat: projekt célok elérését veszélyeztetik Termékkockázat: termékhez közvetlenül kapcsolódó kockázat kezelése: kockázat-alapú teszteléssel milyen technikával mennyit milyen prioritások mentén és mit teszteljünk

20 TESZTELÉSI ALAPFOGALMAK

21 ALAPFOGALMAK: BLACK-BOX VS. WHITE-BOX TEST Black box white box Black box : nem ismerjük a kód szerkezetét (pl felhasználói, vagy UI teszt) White box : ismerjük a kód szerkezetét, célzottan tesztelünk

22 ALAPFOGALMAK: BLACK-BOX VS. WHITE-BOX TEST...de miért kell white box teszt? minden variációt nem lehet UI-on/interface-en keresztül tesztelni időben hamarabb tudunk kódközeli teszteket elvégezni könnyebb redesign-t igénylő hibákat találni egyszerűbb megtalálni a hiba okát lefedettségmérés egyszerűbb

23 ALAPFOGALMAK: STATIKUS VS DINAMIKUS TESZT Statikus dinamikus teszt Statikus teszt: a szoftver product futtatása nélküli teszt code review documentation review statikus kód analízis Dinamikus teszt: a szoftver product (egy részének) futtatása szükséges lehet kézi, vagy automatikus

24 ALAPFOGALMAK: STATIKUS VS DINAMIKUS TESZT

25 ALAPFOGALMAK: TESZTLEFEDETTSÉG Lefedettség vizsgálat (coverage) Teszt coverage: a tesztkészletünk végrehajtása által a tesztelendő szoftver hány százalékát teszteljük jellemzően line, illetve function coverage-et mérünk ökölszabály: 70% LC, 90% FC Requirement coverage: a tesztelendő követelmények hány százaléka van letesztelve V-modell alapján általában 100% az elvárás automatikus ellenőrzés (tracing)

26 ALAPFOGALMAK: TESZTLEFEDETTSÉG

27 ALAPFOGALMAK: REGRESSZIÓS TESZT Regressziós teszt: egy korábban már tesztelt program módosítást követő tesztelése annak biztosítása érdekében, hogy a módosítás nem okozott hibát a szoftver nem módosított részeiben

28 ALAPFOGALMAK: DDP Defect Detection Percentage (DDP): a hibák hány százalékát találták meg egy adott teszszinten / egy adott szervezetben

29 ALAPFOGALMAK: PARETO-ELV Pareto-elv Pareto-elv: a hibák 80%-át a modulok/függvények 20%-a okozza.

30 ALAPFOGALMAK: PARETO-ELV

31 PROJEKTMENEDZSMENT MODELLEK

32 PROJEKTMENEDZSMENT MODELLEK Előnyök: Stabil követelményeknél, kevésbé komplex projekteknél Feszes ellenőrzést könnyen érthető mérföldkövek Hátrányok: Nehézkes reagálás a változásokra, problémákra -> magas költség- és időigény Az ügyfél csak a folyamat végén látja rendszert Big bang integráció a folyamat végén Minden egyes fázis az előző fázis teljes befejezésére épít, ami tovább növeli a kockázatokat A tesztelés a projekt kései szakaszában kezdődik el, így a hibák sokáig rejtve maradhatnak Túlzott túlzott dokumentálási követelmények Nincs lehetőség a rendszer kisebb részekre osztására

33 PROJEKTMENEDZSMENT MODELLEK Előnyök: Egyszerű a használata A tesztelés már a kódolás előtt elkezdődik ->korai és költséghatékony hibajavítás A felmerült hibát javítják az adott fázisban, nem gyűrűzik tovább Kis projektek számára praktikus, ahol a követelmények jól ismertek Hátrányok Túlságosan merev, nem rugalmas modell A kódolás az implementációs fázisban történik (a folyamat vége felé), ezért nem készül korai prototípus Ha menet közben bármilyen változás történik, minden dokumentációt frissíteni kell

34 PROJEKTMENEDZSMENT MODELLEK Iteratív fejlesztési modell: A teljes projektet időben feldaraboljuk iterációkra Minden iteráció egy kis projekt Iterációk végén van kiszállítható termék Inkrementális fejlesztési modell: Minden iterációban egy kis részt hozzáadunk a korábbi verzióhoz Minden iteráció egy kis projekt Prioritás dönti el, mit adunk hozzá A regressziós teszt ellenőrzi, hogy az új fejlesztések rontják-e el a régieket

35 MIK A NAPI TESZTELÉSI FELADATOK?

36 MIK A NAPI TESZTELÉSI FELADATOK? Free teszt Átvételi teszt Minőség mérése Test design Dokumentáció Teszt stratégia készítése Rizikóanalízis Követelmény review Regressziós tesztelés UT/IT írás Code review

37 MI A TESZTELŐ SZEREPE A SZERVEZETBEN?

38 MI A TESZTELŐ SZEREPE A SZERVEZETBEN Tesztelni mindenki tud Elvárt képességek: Domain tudás Soft skill-ek A termék ismerete Felhasználói ismeretek, karakterisztikák A konkurencia ismerete Ügyfélkozpontú(bb) gondolkodás

39 MI A TESZTELŐ SZEREPE A SZERVEZETBEN Független tesztelés (QA = Quality Assurance, vagy Qualified Annoyer?) ++ Tesztelői tudás Teszt technikák ismerete Teszt tool-ok ismerete Soft skill-ek Kommunikáció Szenvedély Monotonitás tűrés Szakmailag destruktív, emberileg konstruktív Prezentáció, reportálás

40 MI A TESZTELŐ SZEREPE A SZERVEZETBEN A teszt (automatizáló) mérnök IT tudás ++ Szoftverfejlesztés Tervezési, ütemezési képességek

41 MI A TESZTELŐ SZEREPE A SZERVEZETBEN A tesztelő/tesztelés a csapaton belül ++ Tesztelői tudás soft skillek (Agilis tesztelési technikák) Teszt menedzsment képességek Tesztelői szempontok a megbeszéléseken IT tudás Requirement Engineering

42 MI A TESZTELŐ SZEREPE A SZERVEZETBEN A tesztelő a minőségügyi evangelista Soft skillek ++ Leadership Governance->Guidance-> Coaching Stratégiai gondolkodás Preventív gondolkodás

43

44