Minőségbiztosítás a fejlesztési folyamat során

1. Minőségbiztosítás a fejlesztési folyamat során Pusztai Lászlóvezető konzulens Gaál Lászlórendszermérnök Microsoft Magyarország

2. Tartalom • A minőségbiztosítás szükségessége • A minőségbiztosítás eszközei • Napi tevékenységek • A minőségbiztosítás elemei a napi fejlesztői munka során • A termék kiadása • Összefoglaló

3. 28% 46% Miért szükséges a minőségbiztosítás? • A projektek „nem kellően sikeres” ¾-e miatt • A „kommunikációs és működési gondok” miatt

4. Ha ez nincs…tipikus párbeszéd • „Kijavítottátok azt a hibát, amit a mezőbankosok jeleztek?” • „Miért, mi bajuk volt?” • „Igen, én megcsináltam” • „Akkor add ide a javítást, mert a Polgári Bankba is ki kéne vinni…” • „Ott nem az új verziót tetted fel tegnap?” • „De igen, csak azt otthon fordítottam, és a Btrieve-driver valamiért nem fordult le, úgyhogy abból a régit tettem fel nekik.” • „Várj, odaadom azt is” • „De megy ez az ő megjelenítőjükkel?” • „Nem tudom, nekem ment”

5. Minőségbiztosítás • Változáskezeléssel • Fix pont: a projekt aktuális állapota • ezt az állapotot tudjuk kontrolláltan változtatni • Projekt-állapot • Specifikáció • A kód állapota • Bejelentett hibák

6. A szükséges infrastruktúra • Nyilvántartás a specifikációk részére • követelménykezelés • Munkadarabok jegyzéke • felelős, készültségi fok • Belső szabályrendszer • projekt-kézikönyv • Forráskód-kezelő rendszer • a szoftver aktuális állapota • Hibajelentéseket kezelő rendszer • az aktuális állapotról szóló visszajelzések nyilvántartása

7. Napi munkafázisok – fejlesztésDevelop • Készül az új kód • A fejlesztő dolgozik a saját gépén Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

8. Napi munkafázisok – bejelentésCheck-in • Az elkészült munkadarab integrációja a szoftver aktuális állapotába • Változás! • tehát változáskezelést kell alkalmazni • forráskód-kezelő • szabályok aktuális állapot Check-in(beadás) Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

9. Napi munkafázisok – buildBuild • A szoftver aktuális állapotának leképezése telepíthető termékké • Ha a projekt elkészült, ennek az eredményét adjuk ki a megrendelőnek napi build aktuális állapot Build(elkészítés) Check-in(beadás) Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

10. Napi munkafázisok – tesztelésTest • A termék aktuális állapotának összevetése • a követelményekkel • általános elvárásokkal • A visszajelzéseket rögzítjük napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

11. Visszacsatolás • A fejlesztést természetesen befolyásolják a bejelentett hibák és egyéb észrevételek is napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

12. A napi ciklusA teljes kép • A csapat tagjai konkurrensen hajtják végre az egyes fázisokat • Ezeket az állomásokat tárgyaljuk most részletesen napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

13. A napi ciklus • 09:30 Napindító megbeszélés • 09:45 Fejlesztés, tesztelés • 17:00 Check-in ablak nyílik, peer code review-k • 18:00 Napi build

14. A fejlesztési szakaszDevelop • A tényleges fejlesztés folyamata • Erről ma nem beszélünk • megtanulható iskolában, tanfolyamon, könyvből, önképzéssel, munka közben, … napi build aktuális állapot aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

15. De akkor miről? • Arról, hogy... • Hogyan rendszerezzük a fejlesztendő munkadarabokat • Hogyan kövessük a kód változásait

16. A forrásfa • A forráskód a rendszer komponentizálásának megfelelő irányított gráf • A levélelemek tartalmazzák az egyes komponensek forráskódját

17. Hogyan építsük fel a forrásfát? • Legyen benne minden, ami a termék elkészítéséhez kell • Forráskód + eszközök = termék (ez a build környezet) • A dokumentumoknak is a forráskód követő rendszerben a helyük • Ne szennyezzük a fordítás során előálló fájlokkal • Minden egyes ágnak gazdája kell, hogy legyen • Az eszközöket célszerű külön, több projekt számára közös ágban elhelyezni

18. Példa forrásfa szerkezet d:\sources \foo \binary_release \x86 \specs \src \feature1 \feature2 \testsrc \bvt \feature1 \feature2 \tools

19. Külső függőségek • Amikor egy másik csapat vagy projekt eredményeit kell felhasználnunk • Microsoft komponensek (msvcrt, msvbvm, mdac) • ActiveX kontrollok • A forrásfa meghatározott részére kerül a másik projekt bináris-fájának egy része • Követelmények az átadott binárisokkal szemben: • Binárisok és teljes debug info (PDB) az összes támogatott platformra

20. Forrásfa házirend • Meghatározza, hogy milyen szabályok szerint lehet kódot elhelyezni a forrásfában • Milyen időközönként • Milyen jóváhagyást igényel • Milyen minőségi feltételeknek kell eleget tegyen • Beadási szabályok (Checkin policy) • Adminisztratív eszközökkel betartandó • A fejlesztők oktatandók • Ha nem lehet betartani, elágaztatásra van szükség

21. Mikor ágaztassunk el? • Ha szükség van rá, mert • Inkompatibilis házirend • Termék kiadása • Új funkciók fejlesztése • Ne másoljunk, ha elágaztatás a cél • Ha egy ág befagyasztására van szükség • Tesztelési okok • Termék kiadása

22. Elágaztatás - alapok • Promóciós modell • Hátrányai: • Az adott elágazáshoz tartozó szabályok változnak • A fejlesztőknek munkájukat folytonosan át kell helyezni más ágakba V2.0 Új technológia próbaág V1.0

23. Elágaztatás – alapok • Főág (mainline) modell • A fejlesztők a főágban vagy egy adott funkció fejlesztési ágában tevékenykednek • A kiadott termékverziók ágában csak kritikus hibajavítások történnek V1.0 főág Új technológia próbaág

24. Változások propagálása • A változtatásokat lehetőleg az elágaztatás óta legkevesebbet módosult ágban tegyük meg • Propagáljunk sűrűn és a lehető legkorábban • Az összefésülést mindig a megfelelő tudással bíró ember végezze (vezető vagy senior fejlesztő)

25. Elágaztatás és az ágak összefésülése

26. A jó forráskódkövető rendszer • Támogatja az elágaztatást (branching) • Támogatja a háromutas összefésülést (three way merge) • Integrálható a fejlesztők által használt környezetbe • Nincs „útban”

27. Ha nem így tesszük... • „Hol van a legfrissebb forrás?” • „Ki írta felül az új ablakkezelő függvényem?” • „Miért nem fordul le a főprogram?” • „Sajnos elhagytuk a DLL forrását, így nem tudjuk megcsinálni a javítást.”

28. Az elkészült kód beadásaCheck-in • Az elkészült munkadarabok kódjának elhelyezése a forráskód kezelő rendszerbe • Csak a forrásfa házirend feltételeinek megfelelő kód • A forráskód-kezelő nem biztonsági mentésre való! napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

29. A beadás lépései • Mások változásainak szinkronizálása • Build a fejlesztő gépén • Fejlesztői regresszióteszt • Kódellenőrzés (code review) • Beadás • Társ-build (buddy-build) • Hibanyilvántartás frissítése • Beadási levél

30. Ha nem így tesszük... • „Nálam pedig lefordul.” • „Ki tette be ezt az idétlen üzenetet a főképernyő közepére?” • „Kijavította már valaki ezt a hibát?” • „Milyen komponenseket kell átírni Józsi változtatásai miatt?”

31. A termék megépítéseBuild • A megépítés során a forráskód futtatható bináris állományokká alakul napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

32. Mi a build környezet? • Azok az eszközök, amelyek a forrásból előállítják a terméket • Forráskód + eszközök = termék • Szintén a forráskódkövető rendszerben vannak

33. Miért kell build környezet? • Konzisztens fordítási beállítások az egész forrásfára • Bármikor byte-helyesen reprodukálható eredmény • A forrásfa tetszőleges al-fájának megépítése • A fejlesztők saját gépén megépíthető legyen a termék • Teljesen automatizált (telepítőkészletet produkál) – utólagos telepítőkészlet

34. A build fő fázisai • Build • A forráskódból a bináris állományok elkészítése • Eredménye a bináris-fa • Utó-build (postbuild) • A bináris állományok utófeldolgozása a bináris-fából • Telepítőkészlet készítése • Build Verification Test (BVT) • Az elkészült termék alapfunkcióinak ellenőrzése

35. A build típusai • Minden egyes build több platformra készülhet • Pl. x86, ia64, amd64, arm • Az egyes platformokon belül kétfélét készítünk: • Checked (debug) : teljes debug-info • Free (release) : a debug info csak a globálisokat és a függvénydefiníciókat tartalmazza

36. A legfőbenjáróbb bűn • A build break • A fejlesztő nem ellenőrizte, hogy minden fájlt betett-e a forráskód-követő rendszerbe • Mások munkájával inkompatibilis változtatást hajtott végre • „Jutalma” a Buildmeister cím elnyerése • Az ő feladata a napi build-ek elkészítése, a build scriptek karbantartása • A build szabályainak betartatására • A fejlesztői kézikönyv • Illetve korbács használható

37. Utó-build • Parancsfájlok végrehajtásából áll • Batch, perl, stb. • Ezeket szintén a forráskód-követő rendszerben tároljuk • Minden egyes termékre egyedi • Eredménye mindaz, ami a termék telepítéséhez és használatához kell • Ideális esetben a telepítő CD • A postbuild lefutása után következik a termék kiadása

38. A termék kiadása (release) • Egy olyan megosztásra kerül át a teljes termék, ahonnan azt a tesztelők és a többi felhasználója elérheti • Visszamenőleg sokáig megmarad • Fontosabb mérföldköveknél a régieket archiválni kell • A release megosztás struktúrája: Foo\ main\ 1018\ x86fre\ x86chk\ featuredev\ 1019\

39. A kiadások verziói • A termék verziószáma mindig tartalmazza a build-számot: • Major.minor.build.serial • Pl. 2.5.1018.1 • A build-szám minden nap más • A serial az egy napon belüli build-eket különbözteti meg • A napi build ideális szinkronizálási pont a másnapi munka elkezdéséhez • Ne feledjük: ha egyszer kiadtunk valamit, az örökké él

40. Ha nem így tesszük... • „Nem működik a programom, ami a Józsi új DLL-jét használja.” • „Szükség van a modulok közötti integrációs tesztre.” • „Holnap elkészülünk, de még két hét kell a telepítő megírására.” • „Látta már valaki egyben az egészet?” • „Melyik DLL fut kint az ügyfélnél?”

41. Tesztelés • Minőséget nem lehet „beletesztelni” a szoftverbe • A teszt célja: ellenőriz és visszajelez, hogy a szoftver megfelel-e a kitűzött követelményeknek • specifikált működés • elvárt teljesítmény • üzembiztonság • egyéb „általános elvárások” napi build aktuális állapot Build(elkészítés) Test(tesztelés) Check-in(beadás) hibák, vissza- jelzések Develop(fejlesztés) módosított és új kód Specify(specifikálás) módosított és új követelmények

42. Tesztek a napi ciklusbanKiadható-e tesztelésre? • Fejlesztői regresszióteszt • a fejlesztő végzi, még beadás előtt • kibírja-e a termék a változást? • white box, automatizált • Telepítési teszt • telepíthető-e? • Build Verification Test • megvannak-e az alapvető működések • ki lehet-e adni a build-et további tesztelésre? • automatizált • kieshet belőle a DRT (ha nem túl hosszú)

43. Tesztek a napi ciklusbanRészletes • Unit Test • az egyes modulok, funkciócsoportok részletes tesztje • Regression Test • visszajöttek-e egyszer már kijavított hibák? • “bugs tend to cluster” – a baj nem jár egyedül • változások átvezetése a forrásfa egyes ágai között

44. Tesztek a napi ciklusbana funkcionális követelményeken túlmutató • Stress test • Megpróbáljuk szétverni a szoftvert • Érvénytelen input, óriási adatkészlet, erőforrások mesterséges korlátozása • Általában éjszaka fut, reggel debugoljuk a döglött példányokat. • Komoly tervezést és infrastruktúrát igényel! • Terhelési teszt • ha van teljesítmény-kritérium • gondos tervezést igényel

45. Tesztek a napi ciklusban„hagyományos” • Ad-hoc teszt • játszunk a szoftverrel, és figyeljük, mit csinál (szimuláljuk az egyszerű felhasználót) • nem determinisztikus • nagyon kell figyelni, hogy reprodukálható legyen • legtöbbször kiinduló pont az automatizált tesztekhez

46. A megtalált hibák kezelése • Minden hiba, ami valamilyen szempontból nem felel meg • a követelményeknek • az elvárásoknak • Jelentjük. Az összeset. • Adatbázisban rögzítjük • statisztikák • hibák életciklusának követése

47. Egy hiba adatai • Rögzítendő • azonosító (automatikusan generált egyedi kulcs) • tárgy (rövid leírás) • szoftver verziószáma • konfiguráció • oprendszer, hardver, egyéb szoftverkörnyezet • a hiba részletes leírása • reprodukciós lépések • a szükséges csatolt állományok • fontossági / súlyossági besorolás (severity/priority) • terület / alterület

48. Fontosság • Fontosság (priority): milyen fontos megjavítani • Pri 4: majd… • Pri 3: amikor időnk engedi • még a termék kiadása előtt • Pri 2: még ebben a szakaszban • Pri 1: most • Pri 0: azonnal • Pri 0 HOT: már kész kéne, hogy legyen • áll a vezér gépe

49. Súlyosság • Mekkora galibát okoz? • Sev 4: nem szép • Sev 3: kicsit zavar a működésben, elkerülhető • Sev 2: komolyabb hiba, hiányosság • Sev 1: adatvesztés, összeomlás, súlyos hiba • valamilyen szempontból használhatatlanná teszi a terméket

50. Kategóriák • Súlyosság ⇒ fontosság • de nem automatikusan • Pri 1, Sev 4: • „Micorosoft Office XP” • Pri 4, Sev 1: • a teszter otthoni XT-jén letörli a FAT-táblát, ha a program indításával egyidejűen dugja be a mentéshez használt VHS-videomagnót.