Unrestricted
MIÉRT KELL TESZTELNI?
„MIÉRT KELL TESZTELNI?”
A termékminőség fejlesztése
...hogy megtaláljuk a hibákat, mert azok ott vannak...
„MIÉRT KELL TESZTELNI?”
Hogy felderítsük, mit tud a szoftver
„MIÉRT KELL TESZTELNI?”
Rövidebb termék életciklus
„MIÉRT KELL TESZTELNI?”
A minőség mérhetővé tétele
„MIÉRT KELL TESZTELNI?”
A bizalom erősítése
„MIÉRT KELL TESZTELNI?”
Az ügyfél elvárásainak biztosítása
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
„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
„WHY TO TEST?” - Validáció vs verifikáció
•
Author
A verifikáció sikeres, de a validálás nem!
Date
Page 12
„WHY TO TEST?”
A standardoknak való megfelelés
MIT JELENT A MINŐSÉG?
„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)
„MIT JELENT A MINŐSÉG?” - TERMÉK-ALAPÚ MINŐSÉG
MILYEN A JÓ TESZT?
„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ő!
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
TESZTELÉSI ALAPFOGALMAK
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
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
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
ALAPFOGALMAK: STATIKUS VS DINAMIKUS TESZT
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)
ALAPFOGALMAK: TESZTLEFEDETTSÉG
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
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
ALAPFOGALMAK: PARETO-ELV
Pareto-elv Pareto-elv:
a hibák 80%-át a modulok/függvények 20%-a okozza.
ALAPFOGALMAK: PARETO-ELV
PROJEKTMENEDZSMENT MODELLEK
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
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
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
MIK A NAPI TESZTELÉSI FELADATOK?
„MIK A NAPI TESZTELÉSI FELADATOK?” Free teszt Átvételi teszt Minőség mérése Dokumentáció
Test design Teszt stratégia készítése
Regressziós tesztelés UT/IT írás
Rizikóanalízis Code review Követelmény review
MI A TESZTELŐ SZEREPE A SZERVEZETBEN?
„MI A TESZTELŐ SZEREPE A SZERVEZETBEN”
„Tesztelni mindenki tud” Elvárt képességek: Domain tudás A termék ismerete Felhasználói ismeretek, karakterisztikák A konkurencia ismerete
Soft skill-ek Ügyfélkozpontú(bb) gondolkodás
„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
„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
„MI A TESZTELŐ SZEREPE A SZERVEZETBEN”
A tesztelő/tesztelés a csapaton belül
++ Tesztelői tudás (Agilis tesztelési technikák) Teszt menedzsment képességek
soft skillek Tesztelői szempontok a megbeszéléseken
IT tudás Requirement Engineering
„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
