03. gyakorlat

Projektfeladatok meghatározása

A választható projektek a CooSpace (összevont gyakorlat fórumában) találhatók.

A kiválasztott projekthez pontosan meg kell határozni a kapcsolódó feladatokat és azt, hogy hogyan tervezi azokat megvalósítani a csapat. Az alábbi két feladattípuson belül kell egy-egy feladatot vállalni:

• Statikus tesztelés vagy lefedettségmérés
• Mi a cél, és mi lesz a várható eredmény?
• Funkcionális, terheléses vagy használhatósági (usability) tesztek végrehajtása
• Mi a cél, és mi lesz a várható eredmény?

A feladatok kijelölése során az alábbi kérdésekre is választ kell adni:

• Melyek lesznek a választott feladatok kilépési feltételei? Másképpen fogalmazva, mikor tekintjük a vállalt feladatot késznek?
• Mik lesznek az átadandók? Melyek azok termékek, kódok, dokumentumok, konfigurációs állományok, amelyeket a feladat végeztével bemutatunk és átadunk a gyakorlatvezetőnek?
• Milyen várható ráfordítást igényel a feladat megoldása?

Kilépési feltételek

Minden tesztelésnél meg kell határozni azt, hogy mikor tekintjük az adott teszttevékenységet lezártnak. Ennek meghatározása különösen fontos, mert nem lehetséges kimerítő tesztelést végezni, ugyanakkor az objektív értékeléshez szükséges tudni, hogy a vállalt tevékenységet milyen mértékben és milyen minőségben tudtuk elvégezni.

A magas színvonalon, extra tartalommal elkészített projektek az utolsó előadáson bemutatásra kerülhetnek, és megajánlott jegyet érhetnek.

A döntés az előadás oktatójának a hatásköre

A gyakorlatvezetők feladata kimerül abban, hogy a lehetséges projektmunkák alapján kijelöljék azokat a csapatokat, amelyeket érdemesnek tartanak jegymegajánlásra. A döntés az előadás oktatójának a hatásköre, és feltétele az is, hogy az érintett hallgatók rendszeresen látogassák az előadásokat.

Teszttervezés

Az előadás részletesen szól a teszttervek készítéséről, tartalmi és formai elemeiről, ugyanakkor a gyakorlati feladat megoldása megköveteli, hogy megelőzve az előadás tematikáját a legfontosabb tudnivalókat pragmatikus szempontból összefoglaljuk.

Az agilis fejlesztést támogató keretrendszerekben már nem jellemző a túlságosan részletes dokumentáció alkalmazása, inkább lényegre törő, gyakorlatias megoldásokat preferálják. Ennek figyelembevételével az alábbiakban megadjuk azokat a tartalmi elemeket (kiegészítve a fontosabb adminisztratív összetevőkkel), amelyek az agilis keretrendszerekben is tipikus elemeit alkotják az egyes tesztterveknek.

• Egyedi azonosító: Bármi, ami egyedileg azonosítja a dokumentumot. Jellemzően tartalmazza a projektnevet (a szponzort, ha van), az évet, esetleg egy sorszámot.

  Miért van szükségünk egyedi azonosítóra?

  Talán elgondolkodtál már azon, hogy miért kell minden dokumentumot (nemcsak azokat) egyedi azonosítóval ellátni. A rövid választ Atoine de Saint-Exupéry a Kis Herceg című művében már megadta: "...mert a fölnőttek szeretik a számokat...".

  A hosszabb válasz pedig az, hogy a tesztelés során különböző dokumentumok, tesztverek készülnek és valahogy tudni kell, hogy az egyes termékek mely más termékekkel kapcsolhatók össze. Ezek nélkül az azonosítók nélkül az őskáosz uralkodna mindenütt.

  

• Készítők: A készítők nevét és beosztását kell felsorolni.

• Verziókövetés: A tesztterv, akárcsak a legtöbb munkadokumentum több változáson is keresztülmegy az életciklusa során. Az egyes változatokat verziószámmal jelölik, amelyet minden módosítás esetén növelni kell. A verziókövetés lényegében egy olyan táblázat, amelyben az egyes verziószámok, az egyes kiadások dátuma és a kapcsolódó változások vannak feltüntetve a dokumentum elején.

• Tesztelés kontextusa : Ebben a fejezetben határozzuk meg a tesztelési feladat célját, ismertetjük a tesztelés hatókörét, bemutatjuk a tesztbázist, amelynek alapján a követelményeket meghatározzuk, illetőleg ismertetjük azt is, hogy mely tesztfeltételeket vonunk be a tesztelés alá és melyeket zárunk ki onnan.

  Mi a tesztbázis?

  Azon a dokumentumok halmaza, amelyekből a tesztelendő komponensekre vonatkozó követelmények származnak. Egyszeűen szólva ezeknek a dokumentumoknak alapján tudjuk azt, hogy mely szoftverkomponensen mit kell tesztelni, mik az elvárások, a követelmények és a megszorítások.

  Mit nevezünk tesztfeltételeknek?

  Tesztfeltételeknek nevezzük a komponens, a program vagy a szoftver bármely részét, tulajdonságát, elemét vagy eseményét, amelyek egy vagy több teszteset segítségével verifikálhatók.

  A teszteset és tesztfeltétel nem ugyanaz a fogalom!

  Ne tévesszük össze a tesztfeltételeket a tesztesetek fogalmával. A teszteseteket a tesztfeltételekből kiindulva definiáljuk, amelyek tartalmazzák az előfeltételeket, a végrehajtandó tevékenységeket, az elvárt eredményeket és az utófeltételeket is.

  Tesztelés alól kivont tesztfeltételek

  A tesztelfeltételeket két csoportra bontjuk, a tesztelendő és a tesztelés alól kivont tesztfeltételek halmazaira. Azokat a tesztfeltételeket, amelyek a tesztcsapat döntése alapján nem kerülnek tesztelésre, explicit módon ismertetni kell a teszttervben a döntés indoklásával együtt.

• Feltételezések és korlátozások: Vannak olyan külső tényezők, amelyek fennállása szükséges ahhoz, hogy az adott tevékenységet a csapat el tudja végezni, illetőleg fordítva, amelyek fennállása esetén bizonyos tevékenységek nem végezhetők el. A tervekben ezeket az eseteket azért szülkséges felsorolni, mert végső soron így tudja kizárni a csapat a felelősséget olyan esetekben, amelyek kívül esnek az általuk befolyásolható körülmények halmazán.

  Feltételezések és korlátozások

  A projekt során élhetünk azzal a feltételezéssel, hogy a tesztelendő szoftver fordítható, futtatható, az ehhez szükséges környezet beállításának nincsenek akadályai. Nyílt forráskódú projekteknél ez nincs mindig így. Amennyiben olyan kompatibilitási problémák merülnek fel, amelyek akadályozzák a feladat végrehajtását, a gyakorlat során lehet projektet cserélni, azonban a cserét alaposan meg kell indokolni.

  A korlátozások között szerepelhetnek jogi és technikai korlátok. Ilyenek például a bizalmas anyagok kezelése, vagy technikai korlátként említhetők azok az esetek, mikor egy-egy komponens tesztelését annak jellegzetessége miatt (dinamikus megoldások) nem lehet unit tesztek segítségével tesztelni, vagy csak jelentős ráfordítás mellett.

• Érdekelt felek (stakeholderek): Ebben a pontban soroljuk fel a tesztelési projektben érdekelt szerepköröket, személyeket, és a tesztelési folyamatban betöltött szerepüket, funkcióikat, felelősségüket. A stakeholderek nemcsak a tesztelők lehetnek, hanem az üzleti oldal képviselői is ide tartoznak, akik jellemzően a követelmények meghatározásában és az eredmények elfogadásában vesznek részt (product owner).

• Kommunikáció: Specifikálni kell, hogy a projekt során milyen csatornákon történik az információcsere, az egyes megkeresésekre kinek, milyen gyorsan kell válaszolni, valamint a problémák esetén kihez kell eszkalálni azokat az eseteket, amelyeket a csapat önállóan nem tud megoldani. Mindezek mellett a kommunikáció részét képezik azok az artifactok is, amelyeket a menedzsment szoftverek rendelkezésünkre bocsátanak. Ilyenek a KANBAN/Scrum táblák, burdown-chartok, CI/CD áttekintőtáblák. Ugyanakcsak nem szabad megfeledkezni az írásbeli kommunikációs csatornákról (e-mail, csevegőprogramok, hivatalos jelentések), ezeket is fel kell tüntetni ebben az alfejezetben.

• Kockázatmenedzsment: A kockázat valamely cselekvéssel járó veszély, veszteség lehetősége. Egy projektet számos ponton érhet veszteség, amelyet a tervezés során fel kell mérni és értékelni is kell azokat. A felmérés alatt a projekt során várható eseményeket vesszük számba azok előfordulási valószínűségével és az esemény bekövetkezése esetén okozott hatás figyelembevételével.

A kockázat tehát két tényezőből, skálából tevődik össze (a nemkívánatos esemény bekövetkezésének valószínűsége és annak bekövetkezése esetén eredő hátrányos hatás, vagyis a kár mértéke), amelyeket egy kockázati mátrixban kombinálhatunk össze. A két skálán történő együttes besorolás határozza meg az adott eseményre vonatkozó kockázat mértékét. A fenti mátrixon belül a zöld jelenti az alacsony, a sárga a közepes, míg a piros a magas kockázati szintet.

A kockázatértékelést megelőzően össze kell gyűjteni minden olyan eseményt, amelyek - ha kis valószínűséggel is -, de előfordulhatnak a projekt során. Az eseményeket két külön kategóriába kell osztani. Az egyik kategóriába a terméket érintő események tartoznak (például a szoftver működésképtelensége, a szükséges külső eszközök elérhetőségének problémája, kompatibilitási problémák, stb.), a másik kategóriába a projektet érintő hátrányos eseményeket soroljuk be (például a projekttagok megbetegedése, kilépése, határidő módosítások, stb.). Ezt a két kategóriát külön-külön kell értékelni és termékkockázatként, illetőleg projektkockázatként szerepeltetni a teszttervben.

A kockázatelemzés részét képezi a kockázat csökkentésére vonatkozó tervek specifikálása, valamint a már bekövetkezett események által okozott károk csökkentésére irányuló lépések meghatározása is.

• Tesztmegközelítés: Ebben a pontban ismertetjük a konkrét feladatot érintő terv összetevőit. A szakaszt célszerűen alpontokban érdemes kidolgozni.

  Tesztstratégia

  Egy szervezet tesztstratégiája a tesztfolyamatokban alkalmazandó teszttevékenységek, azok implementálásának módja és előfordulása. Egyszerűbben fogalmazva a tesztstratégia határozza meg, hogy egy adott szervezet mely teszttevékenységeket mikor, mely projekteken és milyen módon kíván elvégezni.

  Tesztelési megközelítés

  A tesztelési megközelítés a tesztstratégiának az aktuális projekthez történő illesztése. Azt mondja meg, hogy az adott projekt jellemzőit tekintve milyen teszttevékenységeket, mikor és milyen módon kíván a csapat elvégezni.

  Tesztstratégia vs. tesztelési megközelítés

  A tesztstratégia általános, többnyire szabályzatok részét képező iránymutatás, míg a tesztelési megközelítés a konkrét teszttervben specifikált szabály, az adott tesztelési projekt sajátosságaihoz igazítva.

• Tesztszintek: Ebben az alfejezetben a V-modellben meghatározott szintekre vonatkozó teszteket specifikáljuk, azaz választ adunk arra a kérdésre, hogy mely szinten teszteljük az adott szoftvert, illetőleg annak komponenseit. A V-modell alapján ezek a szintek a következők lehetnek: egységtesztek, integrációs vagy modultesztek, rendszerteszt, elfogadási teszt.

  

• Teszttípusok csoportosítása teszttechnikák szerint: Többféleképpen csoportosíthatjuk a teszteket. Az egyik esetben a csoportosítás az alkalmazott teszttechnikák alapján történik, amely szerint megkülönböztetünk feketedoboz, fehérdoboz, tapasztalat alapú tesztelést, valamint együttműködés alapú technikákat.

  • A feketedoboz tesztelés specifikáció alapú, azaz a teszteseteket a tesztelés tárgyától különálló dokumentumból származtatjuk. Ha ilyen nem áll rendelkezésre, az egy jelentős kockázat és korlátozás is egyben a tesztelésre nézve. A cél a feketedoboz teszteknél jellemzően az, hogy ellenőrizzük, hogy a rendszer a leírtaknak megfelelően működik-e, vagy sem.
  • A fehérdoboz egy struktúraalapú tesztelés, ahol a teszteseteket a rendszer belső felépítése (struktúrája), illetőleg implementációja alapján származtatjuk. A cél ebben az esetben az, hogy a tesztesetekkel elfogadható szinten lefedjük a rendszer alapvető struktúráját.
  • A tapasztalat alapú tesztelés a tesztesetek tervezésében és meghatározásában a tesztelő tudására, tapasztalatára épít. Kiegészítő technikákat tartalmaz, képes olyan hibák felfedezésére, amelyeket sem a feketedoboz technikák, sem a fehérdoboz technikák nem fednek fel, ugyanakkor mindez a tesztelő képességeinek függvénye.

  • Az együttműködés alapú technikák elősegítik a hibák elkerülését a csapattagok kollaborációja és rendszeres kommunikációja útján.

    Miben rejlik a kollaboráció hatékonysága?

    A csapatmunka alapvetően azt jelenti, hogy az egyéni erőfeszítések összessége nagyobb hatékonyságot és jobb eredményeket hoz, mint amennyit az egyének külön-külön elérnének. A csapat tagjai közötti összhang és a közös cél iránti elköteleződés növeli a projektek sikerességének esélyét. A csapatmunka tehát nem csupán a munkaerő hatékonyabb felhasználása, hanem egy olyan kultúra születéséről is szól, amely elősegíti a tagok közötti összetartást és a szervezet teljesítményének javulását. Fontos, hogy a csapatmunkában a kommunikáció, az együttműködés és az egymás iránti tisztelet is kiemelt szerepet kapjon.

• Teszttípusok csoportosítása funkciójuk szerint: az itt következő csoportosítás a tesztelés funkciójára és céljára koncentrál, független a teszttechnikák alapján képzett csoportoktól.

  • A funkcionális tesztelés során azt vizsgáljuk, hogy a rendszer elvégzi-e azokat a funkciókat, amelyekre azt létrehozták. Cél a funkcionális teljesség, a funkcionális helyesség (vagyis helyesen hajtja-e végre az egyes feladatokat a rendszer) és a funkcionális megfelelőség (vagyis azt hajtja végre a rendszer, amire tervezték, vagy megrendelték) ellenőrzése.

  • A nemfunkcionális tesztelés a rendszer minőségi jellemzőit vizsgálja. Az ISO/IEC 25010:2023 szabvány áttekintő leírást nyújt a szoftver minőségi jellemzőiről, amelynek egy grafikus ábrázolását látjuk a következő ábrán.

    

• Statikus és dinamikus tesztelés: maga cím is meghatározza a két csoportot, amelyet az alábbiakban ismertetünk. Ez a csoportosítás független az előző két szemponttól.

  • Statikus tesztelés esetén a tesztelés alatt álló szoftver futtatása nem szükséges. Kódot, folyamatspecifikációt, rendszerfelépítés specifikációt vagy más munkatermékeket értékelünk manuális vizsgálatok során (például felülvizsgálatokkal), vagy eszköz segítségével (például statikus elemzés során). Tesztcél lehet a minőség javítása, a hibák felderítése, vagy például olyan jellemzők vizsgálata, mint az olvashatóság, a teljesség, a helyesség, a tesztelhetőség és a konzisztencia.
  • Dinamikus tesztelés: olyan tesztek tartoznak ide, amelyek esetében a kód futtatása, végrehajtása is szükséges.

• Teszttechnikák: A teszttechnikák támogatják a tesztelőt a tesztelemzésben (mit kell tesztelni), illetve a műszaki teszttervezésben (hogyan kell tesztelni). A teszttechnikák segítenek a tesztesetek egy relatív kicsi, de elégséges halmazának szisztematikus kialakításában.

  Teszttechnika megnevezés	Típus
  Ekvivelenciapartícionálás	feketedoboz
  Határérték-elemzés (BVA)	feketedoboz
  Döntési tábla alapú tesztelés	feketedoboz
  Állapotátmenet tesztelés	feketedoboz
  Utasítástesztelés és lefedettség	fehérdoboz
  Elágazástesztelés és lefedettség	fehérdoboz
  Hibasejtés	tapasztalat alapú
  Felderítő tesztelés	tapasztalat alapú
  Ellenőrzőlista alapú tesztelés	tapasztalat alapú
  Felhasználói történet alapú tesztelés	együttműködés alapú
  Együttműködésen alapuló user-story írás	együttműködés alapú
  Elfogadásiteszt-vezérelt fejlesztés (ATDD)	együttműködés alapú

  Használati eset alapú tesztelés

  Ez a technika a használati esetek alapján tervezi meg az egyes teszteseteket. Az agilis módszertanokban jellemzően a felhasználói történetek, illetőleg az elfogadási kritériumok váltják fel a használati eset alapú teszteket, azaz a felhasználói történet alapú tesztelés.

• Teszttermékek: Azokat a leszállítandókat kell itt felsorolni, amelyek átadásra kerülnek a tesztelési projekt lezárultát követően. A leszállítandókat a teszttervben explicit módon fel kell sorolni.

  Mik azok a teszteverek?

  A tesztverek a teszttevékenységek kimeneti munkatermékei.

  Példák a lehetséges tesztverekre:

  • teszttervezés munkatermékei,
  • tesztfelügyelet és irányítás munkatermékei,
  • tesztelemzési munkatermékek,
  • műszaki teszttervezés munkatermékei,
  • tesztmegvalósítás munkatermékei,
  • tesztvégrehajtás munkatermékei,
  • tesztelezárás munkatermékei.

• Belépési és kilépési feltételek:

  • Belépési feltételek azok a feltételek, amelyek fennállása esetén elkezdhető a tesztelés. A tipikus belépési feltételek közé tartoznak az erőforrások rendelkezésre állása (pl. emberek, eszközök, környezetek, tesztadatok, költségvetés, idő), a tesztelhetőség megléte (pl. tesztbázis, tesztelhető követelmények, felhasználói történetek, tesztesetek), és a teszt tárgyának kezdeti minőségi szintje (pl. minden smoke teszt sikeres volt).
  • Kilépési feltételek azok a feltételek, amelyek azt határozzák meg, hogy mikor fejezi be a csapat a tesztelést. A tipikus kilépési feltételek közé tartozik az alaposság mérőszámai (pl. elérhető lefedettségi szint, megoldatlan hibák száma, hibasűrűség, bukott tesztesetek száma), és a teljesítési feltételek (pl. a tervezett teszteket végrehajtották, statikus tesztelést végeztek, minden talált hibát jelentettek, minden regressziós teszt automatizált). Az idő vagy a költségvetés elfogyása is érvényes kilépési feltételnek tekinthető. Még akkor is elfogadható a tesztelés teljesítése ilyen körülmények között, ha az érdekelt felek áttekintették és elfogadták annak kockázatát, hogy további tesztelés nélkül engedik ki a terméket.

  • Az agilis szoftverfejlesztésben a kilépési feltételeket gyakran Definition of Done-nak nevezik, amely meghatározza a csapat objektív metrikáit egy kiadható elemhez. A belépési feltételeket, amelyeket egy felhasználói történetnek teljesítenie kell ahhoz, hogy elkezdhesse a fejlesztési és/vagy tesztelési tevékenységeket, Definition of Ready-nek nevezik.

    Csak olyan kilépési feltételeket adjunk meg, amelyek kontrollja a tesztelők kezében marad!

    Ne adjunk meg kilépési feltételeket arra vonatkozólag, hogy a tesztnek mekkora részének kell sikeresen lefutnia! A tesztelő hibát keres, a talált hibák javítása - amennyiben a tesztelés különálló projekt - nem a tesztelő feladata.

    Mik azok a smoke tesztek?

    A smoke teszt egy olyan tesztelési folyamat, amely a szoftveralkalmazás alapvető funkcionalitásának ellenőrzésére szolgál. A teszt során a fejlesztők vagy tesztelők ellenőrzik, hogy az alkalmazás elindul-e, és nem okoz-e nyilvánvaló hibákat vagy rendszerösszeomlást. A “smoke” kifejezés eredetileg a hardvereszközök tesztelésére utal, amikor az eszköz bekapcsolása után ellenőrzik, hogy nem keletkezik-e füst vagy más probléma. A szoftverfejlesztésben a smoke teszt hasonlóan az alapvető működés ellenőrzését végzi el, például azt, hogy az alkalmazás betöltődik-e, a felhasználói felület megjelenik-e, és a legfontosabb funkciók működnek-e. Fontos megjegyezni, hogy a smoke teszt nem helyettesíti a részletes tesztelést, hanem csak az első lépés a hibakeresés és a minőségellenőrzés folyamatában.

• Metrikák: Olyan mérőszámok, amelyek segítik a menedzsmentet abban, hogy folyamatosan követni tudják a tesztelés folyamatát, haladását az ütemtervhez és a költségvetéshez képest. Ugyanakkor olyan metrikák is használatosak, amelyek a tesztelés hatékonyságát mérik. Ezeket a teszttervekben ismertetni kell.

  Milyen metrikákat tudunk meghatározni a tervezés során?

  Az alábbi metrikák a leggyakrabban használtak:

  • Projekthaladási metrikák (feladatlezárás, erőforrásfelhasználás,tesztráfordítás)
  • Tesztelőrehaladási metrikák (teszteset megvalósítás, tesztkörnyezet előkészítés, futtatott/nem futtatott tesztesetek, sikeres/bukott tesztek száma, tesztvégrehajtási idő)
  • Termékminőségi metrikák (rendelkezésre állás, válaszidő, átlagos idő a meghibásodásig)
  • Hibametrikák (talált/javított hibák száma, hibasűrűség, hibamegtalálási arány)
  • Kockázati metrikák
  • Lefedettségek
  • Költség metrikák

  A hiba javítása nem a tesztelő feladata, vagy mégis?

  A klasszikus tesztelési projektekben a tesztelés különálló tevékenység, kivéve a fejlesztői teszteket. Az agilis modellekben a tesztelők részei a csapatnak, így egy ilyen környezetben van értelme annak, hogy mérjük a hibák javításának arányát is. A kurzus során nem ezt a modellt követjük, ugyanis - bár működésben az agilitásra törekszünk - a tesztelendő szoftverek függetlenek maradnak továbbra is a tesztelő csapattól. Ilyen esetekben a javításokra vonatkozó adatok gyűjtésének nincs értelme.

• Tesztadatra vonatkozó követelmények: Egy szoftver teszteléséhez különböző tesztesetek meghatározására is szükség van, amelyeket a tesztfeltételekből vezetünk le. A tesztesetek megadása során figyelni kell arra, hogy a szoftverek bemenete általában jól definiált, különösen abban az esetben, ha valamely API modul tesztelését, vagy éppen integrációs teszteket végzünk. Ez annyit jelent, hogy a tesztesetek meghatározása során a szoftver által elvárt formákat biztosítani kell, ellenkező esetben a tesztelést nem tudjuk végrehajtani. Az elvárt adatformátum, amelynek megfelelő részletességűnek kell lennie (adatformátum, séma, típusok megadása) a teszttervben specifikálandó. Ehhez ismerni kell az adott szoftverre vonatkozó követelményeket, azaz a tesztterv hatékony elkészítéséhez a tesztelendő alkalmazás előzetes tanulmányozása is szükséges.

• Tesztkörnyezetre vonatkozó követelmények: A tesztkörnyezet az a hardver és szoftverkörnyezet, amely minden olyan komponenst tartalmaz, amelynek rendelkezésre állása szükséges a teszt végrehajtásához. A tesztkörnyezetben tehát meg kell adni a tesztelés sikeres végrehajtásához szükséges minimális hardverkövetelményeket, az operációs rendszerre és a futtatókörnyezetre vonatkozó specifikációkat, valamint az alkalmazott automatizálási és menedzsment eszközök specifikációit, és az azokra vonatkozó követelményeket.

• Eltérések az irányelvektől: Abban az esetben, ha az adott szervezet rendelkezik tesztstratégiával és/vagy irányelvekkel, akkor a teszttervet ezek mentén hozzuk létre. Ugyanakkor előfordulhat az is, hogy a sikeres teszt érdekében az előre lefektetett irányelvektől el kell térni. Ezeket az eseteket és azok indokait soroljuk fel ebben az alfejezetben.

• Költségvetés és ütemterv: A gyakorlaton értelemszerűen költségvetést nem adunk meg, azonban a valós projektek esetében ez egy kötelező és alapvető eleme minden tervnek, így a tesztterveknek is. A költségvetés mellett a projekt ütemezését is specifikálni kell, amelyre a gyakorlat is lehetőséget ad, tehát a beadandó tesztterveknek az ütemezésre vonatkozó szakaszokat tartalmazniuk kell. Az ütemezést célszerű átlátható formában, például Gantt-diagram segítségével illusztrálni. A Gantt diagram használata azért is célszerű, mert az egyes fázisok időbeli kapcsolatát szembetűnő módon ábrázolja, amely segíti a projekt haladásának értékelését, és támogatja az erőforrások hatékony allokációját. Az ütemezés meghatározásánál alapszabály, hogy figyelemmel kell lenni az egymásra épülő feladatokra, azaz egy olyan feladatot, amely egy másik feladat eredményétől függ, csak az előző feladat végrehajtását követően szabad beütemezni. Egyébként az erőforrásoktól függően a feladatok párhuzamosíthatóak is. Ezeket a viszonyokat is jól tükrözi a Gantt diagram.

  

• Felelősségek kiosztása: A tesztelési feladatot a teszt team között szét lehet osztani. Az agilis környezetekben ez jellemzően a ticketek kiosztásával együtt történik, nem szokás előre definiálni, azonban ez is megtehető, amennyiben a csapat működése, vagy a csapatban lévő szakmai kompetenciák ezt indokolják. Ha a csapat a felelősség kiosztása mellett dönt, akkor egy táblázatot érdemes készíteni, amely tartalmazza a tesztelésben résztvevő összes munkatárs felelősségi körét. Figyelni kell azonban arra is, hogy a felelősség csapatszintű, így az egyes tevékenységek, felelősségek mögé egy reviewer is legyen jelen, aki átnézi a teljesítést és segíti az érintett munkatársát a feladat megoldásában, annak minőségének biztosításában.

• Jóváhagyó: A gyakorlaton végzett projekt esetében a gyakorlatvezető lesz a jóváhagyó.

A tesztterv készítéséhez egy kidolgozott példát ezen a linken találhatunk.

A tesztterv elkészítése egy konkrét feladat

A tesztterv készítéséhez nyissunk issuet a GitLab rendszerben és adjuk meg a szükséges adatokat, illetőleg jelöljük ki a hozzátartozó mérföldkövet. Ez utóbbi a legelső mérföldkő, amely a projekt előkészítését, tervezését foglalja magában. Mivel a kurzus célja az is, hogy a hallgatók tapasztalatot szerezzenek az agilis projektekről (hacsak részleges módon is), a feladat ráfordítását is becsülni kell és annak eredményét meg kell jeleníteni egy alkalmas címke segítségével a feladathoz tartozó GitLab issuen.

---

Utolsó frissítés: 2024-09-01 15:37:43