Kihagyás

04. gyakorlat

Egy menedzsment eszköz: GitLab

A GitLab egy, a fejlesztést gyakorlati, praktikus szemszögből megközelítő eszköz, mely a teljes fejlesztési folyamat (és annak teszteléssel kapcsolatos) feladatainak dokumentálására alkalmas. Vannak más, a folyamatra jobban koncentráló eszközök is (pl. Redmine).

A belső hálózaton elérhető GitLab-ra történő első belépés után az oktatók hozzá tudják rendelni az azonosítókat a megfelelő (egy gyakorlati és egy projektmunkás) projektekhez. Ezen a kurzuson a GitLab 3 főbb funkcióját kell majd használni.

Repository

A GitLab alapja a git, egy elosztott verziókezelő/követő rendszer. A projekcsapatok számára biztosított GitLab projekt git repository-jába fel kell tölteni a kiválasztott projekt forrását. A "hogyan"-t (fork pl. GitHub-ról, új repo-ba klónozás, kód átmásolása és újként feltöltése, ...) a csapatokra bízzuk. Azt mindenképpen jelezni kell, hogy a projektnek melyik verzió az alapja.

Wiki

A GitLab felületén lehetőség van Wiki oldalak készítésére, és ezen keresztüli dokumentációra. Ide lehet például a tesztterveket, teszteseteket, futási jegyzőkönyveket, riportokat feltölteni. Ha ezt használjátok, fontos, hogy átlátható struktúrát alakítsatok ki. Nem baj, ha vannak "sandbox" szerű oldalak, de a leadandók egyértelműek, könnyen elérhetőek legyenek.

Issues

Az issue-k a projekttel kapcsolatos bug-ok és feladatok nyilvántartására szolgálnak. Mivel ez nem egy kifejezetten bug reporting rendszer, a bug-ok bejelentése esetén a megfelelő szerkezetről és tartalomról nektek kell gondoskodnotok (érdemes valahol egy sablont definiálni). Nyilván nem árt, ha esetleg a feladatokra is vannak ilyen sablonjaitok. Az issue-khoz kapcsolódóan van egy alapszintű életciklus-menedzsment (státusz: open/closed; felelős; mérföldkő; határidő; és cimkék), ezt (ennek az elemeit) majd használni kell.

Mérföldkövek

Valamilyen állapot, cél megfogalmazása. Lehet hozzá határidőt rendelni, de maga a mérföldkő nem a határidő, hanem a teljesítendő feltételek összessége. Vagyis a mérföldkő akkor teljesül, ha az összes hozzá rendelt issue le lett zárva.

Példa mérföldkő: M0 - Előkészítés

Ez a mérföldkő akkor teljesül, ha a minden megvan, hogy a projekt elindulhasson, vagyis

  • a kódbázis bekerült a csapat GilLab projektjébe,
  • minden csapattag hozzá lett rendelve a projekthez,
  • meg lettek határozva a cimkék,
  • meg lettek határozva a mérföldkövek, és
  • elkészült a tesztterv.

A határidő Október 3.

Cimkék

A cimkék az egyes issue-k megkülönböztetését, csoportosítását, állapotának jelzését teszik lehetővé. Mit lehet cimkékkel jelezni/jelölni?

  • Az issue típusát: pl. type:bug vagy type:task.
  • Az issue részletesebb státuszát, így a cimkék és az Issues::Board menüpont segítségével jobban nyomonkövethető, egy-egy feladattal hogyan állunk. Például:
    • status:new: új, nem ellenőrzött, nem jóváhagyott
    • status:confirmed: ellenőrzött, jóváhagyott
    • status:in_progress: fejlesztés/javítás alatt
    • status:testing: tesztelés alatt
    • status:done: sikeresen tesztelve, kész
  • Severity, egyfajta technikai súlyosság, nehézség hozzárendelése, pl. sev:cosmetic, sev:minor, sev:normal, sev:major, sev:critical.
  • Prioritás, vagyis (üzleti) fontosság hozzárendelése, pl. pri:deferred, pri:low, pri:medium, pri:high, pri:critical.
  • Modul, amelyikkel az issue kapcsolatban van, pl. mod:backend, mod:frontend, mod:API, mod:database
  • és még sokminden mást is...

Bug riport

Egy bug riport elsődleges célja, hogy értesítsük a fejlesztőket arról, hogy milyen hibát találtunk, hogy ezt a hibát azután ki tudják javítani. A hibajavítás úgy lehetséges, ha a fejlesztők meg tudják vizsgálni a hibajelenséget, és meg tudják határozni a kiváltó okát. A bug riportnak tehát olyannak kell lennie, hogy a hibajelenséget reprodukálni lehessen, ehhez minden szükséges információt tartalmaznia kell. Ezen felül persze adminisztratív jellegű elemeket is elő lehet írni, illetve elvárás, hogy a hibajavítás folyamata és aktuális állapota is leolvasható legyen.

1. Feladat

Jelents be hibákat a HR portál kalkulátoraival kapcsolatban! Egy incidens riport tartalmi elemei:

  • Dátum, szerző, jóváhagyó
  • Hatályosság, súlyosság, prioritás
  • Referenciák (pl. teszteset)
  • Elvárt és kapott eredmények
  • Eltérés leírása
  • Az esemény időpontja
  • A szoftver/rendszer/konfiguráció beazonosítása
  • Szoftver életciklus mely lépésében észleltük?
  • Esemény gazdasági hatása
  • Javítás sürgőssége/prioritása
  • Esemény állapota
  • Konklúzió
  • Globális hatások (pl. kapcsolódó szoftverekre)
  • Változások naplózása (change history)

Teszttervezés

A tesztelés nem csak annyiból áll, hogy elkezdjük futtatgatni a programot és nézzük, hogy olyan eredményt ad-e amire számítunk. Ez előtt és után is vannak tevékenységek, például a tesztek meghatározása, tesztkörnyezet felállítása, vagy a teszteredmények összegzése, és persze az egész folyamatnak a megtervezése.

Egy példa szituáció

Adott egy fejlesztési projekt, amely a következő összetevőkből áll össze:

  • Java statikus elemző mint "3rd party tool"
    • java programokat elemez és adatokat állít elő
    • linux/windows 32/64 bites verziók
  • Vezérlő felület (web)
    • be lehet állítani, hogy mikor, milyen elemzések fussanak (milyen git repókat elemezzen)
    • egy központi gépen adott ütemezéssel futtatja a méréseket
    • az előállt adatokat feltölti az adatbázisba (egy web API-n keresztül), vagy jelzi az elemzés sikertelenségét
    • linux/windows 32/64 bites verziók
  • Web szolgáltatás
    • adattárolásért felelős réteg, az adatbázis megvalósítást elrejti (web API-t ad)
    • lefelé standard sql; postgres, mysql, oracle -lel kompatibilis
  • Webes felület az eredmények nézegetésére böngészőn keresztül
    • azonosított felhasználók, egyszerre többen
    • saját és publikus projektek
    • normális válaszidő
    • több projekt
    • táblázatok
    • grafikonok
    • timelineok
    • riportok

Rendelkezésre álló információk:

  • Vázlatos specifikáció
  • Felhasználói kézikönyv
  • Példa rendszerek elemzéshez (inputok)
  • Futtatható program, telepítő
  • Forráskód (kivéve az elemzőt)
2. Feladat

Írjunk egy Master Test Plan-t (benne csapatösszeállítással) az IEEE-829 alapján.

3. Feladat

Készítsünk teszt terveket az egyes szintekhez és típusokhoz (nem biztos, hogy mindre szükség lesz):

  • egység tesztelés
  • integrációs tesztelés
  • rendszer tesztelés
  • átvételi tesztelés
  • funkcionális tesztek (black box)
  • nem funkcionális tesztelés
  • struktúra tesztek (white box)
  • ellenőrző és regressziós tesztek
  • karbantartási tesztek

Projekt GitLab és teszttervezés

Néhány szempont a projekthez:

  • A teszt terveket a GitLab-ra kell felvinni.
  • Lehet több tervet (egy átfogó, magas szintű, és több alacsonyabb szintű rész-tervet) is készíteni.
  • A munka legalább 40%-át be kell ütemezni az első mérföldkő elé.
  • Az ütemezés legalább heti részletességű legyen.
  • A tervet a tartalma és formája alapján vizsgáljuk, az IEEE-829 jó kiindulópont, de nem az egyetlen jó megoldás.
  • A GitLab wiki használata opcionális (de ajánlott).
  • A feladatokat majd a GitLab-on kell issue formájában nyilvántartani.
  • Mindenféle kapcsolódó tevékenységnek legyen nyoma, mert ez alapján lesz ellenőrizve az elvégzett munka.
  • Az elkészült munkatermékeknek (teszttervek, tesztesetek, konfigurációk, teszt szkriptek, tesztjegyzőkönyvek, riportok, ...) -- típusuktól függően -- a GitLab Wiki-ben vagy a repóban meg kell jelenniük.

Utolsó frissítés: 2021-09-23 13:22:06