Minőségbiztosítási terv

1. Minőségbiztosítási terv Benedecsik Csaba

2. A cég rövid elemzése • Agilis fejlesztési módszer használata, Scrum • Sok apró projekt, átlag 5 emberhónap • Több egymástól független csoport • Olyan technológiák használata, mely nem elterjedt • Az agilitás fontos szempont a cégben • A létező szerepkörök: Fejlesztő, Minőség-ellenőr, Termék-tulajdonos, Scrum-vezető

3. Minöségbiztositási szempontok • Az ügyfél igényeinek való megfelelés • a kért funkcionalitás lefedése • a nem kivánt müködés(hiba)-arány csökkentése • ügyfél-elégedettség mérése • A cég költségeinek és kockázatainak csökkentése • karbantartási költség csökkentése • a tudásátadás költségének csökkentése • a tudáselvesztés kockázatának csökkentése • fejlesztési költségek és kockázatok csökkentése

4. Az ügyfél igényeinek követése • Két szintü „User story” vagy „Use case” adatbázis, minden egyes modulra • „features” – az igény magas szintü megfogalmazása • „use case” – az igény elemi lehetöleg egyforma komplexitásu lebontása, ezek a test-case k is • „Defect-rate” mérése, lehetöleg egyforma méretü modulokra vagy funkcionalitásra vetitve • Az ügyfél elégedettség mérése • konkrét kérdésekre való válaszokkal • User acceptance test teljesülésével

5. A cég szempontjai • A dokumentáció csökkenti a kockázatokat és a karbantartási-modositási költséget • belsö wiki-be való bejegyzés minden egyes feljesztett modulról, kód-commentelés • A „review” („checklist” segitségével ) kell fedje a következöket : • a kod átnézése programozási , funkcionalitási szempontból • a kod-comment átnézése érthetöség szempontjából

6. Motiváció • meggyözés egy training-rendszeren keresztül, mely ismerteti a QA modszert és fontosságát, értékét minden szerepkör számára • prémium-rendszer mely figyelembe veszi a • review-értékeléseket, a lefedett funkcionalitást, a kitöltött wiki tartalmakat • a fejlesztett rendszerek ujrahasználhatóságát • Rendszeres lehetöség és érdekeltség (kiértékelés) arra, hogy „review”-eljen másokat, hogy felkészüljön arra hogy munkájukat át kell vegye (cross-training)

7. Szükséges rendszerek • Kétszintü use-case (test case) adatbázis a product-ownerek által , amely User Acceptance Test-eket is tartalmazza, minden modulra és alkalmazásra • wiki a cégben alkalmazott tehnológiákra , futó projektekre, forumok bizonyos témakörök megvitatására • Review checklist kódra, dokumentációra, kod-komentre, wiki-re – és csoportok közti cross-review rendszer • cross-training rendszer – a cross review hoz kapcsolodik • Belsö periodikus (max 3 ho) értékelési rendszer amely figyelembe veszi a cross-training ben elért képesitést, review-t, wiki-tevékenységet, az irt kód defekt-rate-jét, lefedett komplexitást

8. Szükséges eszközök • Scrum Projekt Management tool managing time allocations , including reviews and other QA activity • Test-case management and execution tool • Manual and Automatic Code review tool • Ex. Hammurapi • Cross-training database • Internal Wiki, forums

9. Szükséges idő-eröforrások • minden fejlesztőnél 10-20% • tevékenységek : code review (incl comment review ), wiki cikk-irás, code comment, cross-trainingre, más review • vezetö fejlesztőnél 30% • tevékenységek: becslések, cross-training tartás, minöségbiztositáshoz kapcsolódo dokumentáció-információ karbantartása • termék-tulajdonosnál akár 50% • use case adatbázisok karbantartása, teszt-esetek létrehozása • minöségbiztositónál 100% • Teszt esetek végrehajtása, uj teszt esetek létrehozása, teszt-eset review, use-case review, code-comment review, wiki-review