Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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.

Hasonló előadás


Az előadások a következő témára: "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."— Előadás másolata:

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 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 28% 46%

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és Develop  Készül az új kód  A fejlesztő dolgozik a saját gépén Develop (fejlesztés) Specify (specifikálás) módosított és új kód módosított és új követelmények

8 Napi munkafázisok – bejelentés Check-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 Develop (fejlesztés) Check-in (beadás) Specify (specifikálás) aktuálisállapot módosított és új kód módosított és új követelmények

9 Napi munkafázisok – build Build  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 Build (elkészítés) Develop (fejlesztés) Check-in (beadás) Specify (specifikálás) aktuális állapot napibuild módosított és új kód módosított és új követelmények

10 Napi munkafázisok – tesztelés Test  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 Build (elkészítés) Develop (fejlesztés) Check-in (beadás) Test (tesztelés) Specify (specifikálás) aktuális állapot napi build hibák,vissza-jelzések módosított és új kód 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 Build (elkészítés) Develop (fejlesztés) Check-in (beadás) Test (tesztelés) Specify (specifikálás) aktuális állapot napi build hibák, vissza- jelzések módosított és új kód módosított és új követelmények

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

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

14 A fejlesztési szakasz Develop  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, … Build (elkészítés) Develop (fejlesztés) Test (tesztelés) Specify (specifikálás) aktuális állapot napi build hibák, vissza- jelzések módosított és új követelmények aktuális állapot módosított és új kód Check-in (beadás)

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 Dev 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 Dev 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 Dev Példa forrásfa szerkezet d:\sources\foo\binary_release\x86\specs\src\feature1\feature2\testsrc\bvt\feature1\feature2\tools

19 Dev 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 Dev 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 Dev 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 Dev 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 V1.0 Új technológia próbaág

23 Dev 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 főág V1.0 Új technológia próbaág

24 Dev 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 Dev 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 Dev 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ása Check-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ó! Build (elkészítés) Develop (fejlesztés) Check-in (beadás) Test (tesztelés) Specify (specifikálás) aktuális állapot napi build hibák, vissza- jelzések módosított és új kód módosított és új követelmények

29 Check in 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 Check in 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ése Build  A megépítés során a forráskód futtatható bináris állományokká alakul Build (elkészítés) aktuális állapot hibák, vissza- jelzések módosított és új kód módosított és új követelmények Develop (fejlesztés) Test (tesztelés) Specify (specifikálás) napi build Check-in (beadás)

32 Build 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 Build 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 Build 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 Build 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 Build 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 BuildUtó-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 Build 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 Build A kiadások verziói  A termék verziószáma mindig tartalmazza a build-számot:  Major.minor.build.serial  Pl  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 Build 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” Build (elkészítés) aktuális állapot hibák, vissza- jelzések módosított és új kód módosított és új követelmények Develop (fejlesztés) Test (tesztelés) Specify (specifikálás) napi build Check-in (beadás)

42 Test Tesztek a napi ciklusban Kiadható-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 Test Tesztek a napi ciklusban Ré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 Test Tesztek a napi ciklusban a 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 Test 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 Test 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 Test 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 Test 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 Test 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 Test 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.

51 Test A hiba életciklusa Aktív  A hiba gazdája  aki az adott hibával foglalkozik  az életciklus minden stádiumában létezik  egyéni vagy csoport

52 Test A hiba életciklusa  A megoldás visszaküldi a hibát ahhoz, aki megnyitotta  Feladat: ellenőrizni a megoldást Aktív Megoldott megoldás

53 Megoldási módok Megoldás Ki teheti További teendő JavítvaFejlesztőellenőrizni Elhalasztva (kockázatkezelés) Program-menedzser Triage dokumentálni későbbi követelmény Nem javítjuk (alapvető probléma, erőforráshiány) Program-menedzser Triage dokumentálni Így terveztük “It’s not a bug, it’s a feature” Program-menedzser Triage végfelhasználói dokumentáció, ha szükséges Már létező hiba (duplikált) Fejlesztő Tesztelő megadni az eredeti hiba azonosítóját Nem reprodukálható ált. fejlesztő

54 Test A hiba életciklusa Aktív Megoldott Lezárt lezárás  Lezárás  ha a hiba gazdája elégedett a javítással

55 Test A hiba életciklusa  Lezárás  ha a hiba gazdája elégedett a javítással  Reaktiválás  ha elégedetlen Aktív Megoldott Lezárt reaktiválás

56 Test A hiba életciklusa Aktív Megoldott Lezárt reaktiválás  Lezárás  ha a hiba gazdája elégedett a javítással  Reaktiválás  ha elégedetlen  Lezárt hiba is reaktiválható  regressziós teszt  további ellenőrzés során

57 Test Mire használjuk az adatbázist?  Aktív hibák: megoldjuk  Megoldott hibák: megnyitóik ellenőrzik  Lezárt hibák:  elhalasztott, nem javítandó: dokumentáljuk  javított: bevesszük a tesztekbe –regressziós teszt –unit teszt  Összességében: statisztikák

58 Test Statisztikák  Új hibák beérkezési sebessége  Hibamegoldási sebesség  javítási sebesség: tervezhető, kb. 2/fejlesztő/nap  Konvergencia  amikor többet oldunk meg, mint ahányat találunk  a stabilizáció kezdete

59 Statisztikák Jóslás  Mikor lesz „kész” a szoftver?  aktív hibák számának csökkenő trendje adja meg  Kiadási stádiumok  konvergencia  Nulla aktív hiba –ZBB: zero bug bounce  RC  Gold Kiadás

60 Példa: egy MCS projekt konvergencia ZBB

61 Átadáshoz közeledve  Elágazás a forrásfában  ha megy tovább a fejlesztés  Szigorodik a változáskezelés  Fokozott figyelem a változás kockázataira  minden javítás egy újabb hiba esélyét is hordozza  War Team  minden lényeges szereplő képviseletével  “triage”

62 Kiadás  A csapatmodell minden szereplőjének egyetértésével  “Gold master” – a végleges termékállapot hitelesítése  pl. aláírt CD-példány  ez a további sokszorosítás alapja  A teljes projekt-állapot archiválása  Ship party  Ship party

63 Test Átadás-átvételi teszt Pozitív működést bemutató teszt  Megfelel-e a specifikációnak?  Felhasználó részvételével zajlik  Vagy dobozos termék esetén: képviselője, a PM

64 Összefoglaló  Állapotkezelés  Változáskezelés  Már a projekt kezdetétől  Így lesz kézbentartható  Felismert és kezelhető kockázatok Build (elkészítés) Develop (fejlesztés) Check-in (beadás) Test (tesztelés) Specify (specifikálás) aktuális állapot napi build hibák, vissza- jelzések módosított és új kód módosított és új követelmények

65 További információ  Microsoft Solutions Framework Microsoft Solutions Framework Microsoft Solutions Framework  bestpractices/ bestpractices/ bestpractices/  Karl E. Wiegers: Software Requirements  Steve McConnell: Rapid Development  Steve McConnell: Software Project Survival Guide  Ed Sullivan: Under Pressure and On Time  Steve Maguire: Debugging the Development Process  Michael Howard, David LeBlanc: Writing Secure Code  Steve McConnell: Code Complete  Steve Maguire: Writing Solid Code  Frederick P. Brooks: The Mythical Man-month  Addison-Wesley


Letölteni ppt "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."

Hasonló előadás


Google Hirdetések