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

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ő

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

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

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

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)

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

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

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