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.

A bug riportok életciklusát és tartalmát tekintve a tesztmenedzsment előadás fóliái további részletes információval szolgálnak.

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 terveknek tartalmazni kell a csapattagok személyre szabott részfeladatait.
Az egyes részfeladatokban minden csapattag vegyen részt, de az elsődleges felelőst meg kell jelölni.
A tervekben tüntessük fel az eredménytermékeket is, ezek legyenek egyértelműek.
A terveket a GitLab wiki oldalára kell feltölteni.
A feladatokat majd a GitLab-on kell issue formájában nyilvántartani.
A feladatok kijelölésében a címkéket alkalmas módon használni kell.
Ügyeljünk arra, hogy a munkamegosztás a csapattagok között egyenletes legyen és ez az egyes issuek esetében követhető legyen.
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.
Az értékelés a teszt terv alapján történik, a teljesítéseknek a tervvel összhangban kell lenniük.
A hibajelentések tartalmát és életciklusát illetően lásd a tesztmenedzsment előadás fóliáit.

Utolsó frissítés: 2023-08-28 11:13:48