Bónusz pontok áttekintése
A bónuszpontok olyan extra pontok, amelyek a csapatodhoz tartoznak. A csapatod szerezhet, veszíthet, elkölthet és átadhat ilyen pontokat a félév során. Céljuk az aktív részvétel jutalmazása és a csapatok közötti szakmai együttműködés ösztönzése.
A félév végén a csapatod legfeljebb 40 fennmaradó bónuszpontot oszthat szét a tagjai között. Az elosztásnak nem kell egyenlőnek lennie, de meg kell állapodnia benne a csapatnak. Ezek a pontok ezután hozzáadhatók a tagok érdemjegypontjaihoz.
A bónuszpontok adóssággá is válhatnak
A csapatod bónuszpont-egyenlege lehet negatív, de nem süllyedhet -30 pont alá. A negatív egyenleget a félév végén el kell osztani a csapat tagjai között, és le kell vonni az érdemjegypontjaikból. A csapat nem dönthet úgy, hogy figyelmen kívül hagyja ezt az adósságot.
Bónuszpontok szerzése¶
Aktív részvétel az órákon¶
A csapatod bónuszpontokat szerezhet az órai aktív részvétellel. Az aktív részvétel magában foglalja a következőket:
- kérdések megválaszolása;
- hasznos ötletek és tapasztalatok megosztása a megbeszélések során;
- releváns kérdések feltevése, amelyek előreviszik az órát;
- aktív részvétel az órai tevékenységekben.
A részvételhez nem kell tökéletes választ adni. Egy jól megmagyarázott kísérlet, egy hasznos kérdés vagy egy eltérő nézőpont ugyancsak segítheti az órát, és bónuszpontokat érhet. A pontokat a csapat kapja meg, még akkor is, ha azokat egyetlen csapattag érdemelte ki a részvételével.
Mennyi pontot szerezhet a csapatod?
Minden órán általában 0–10 bónuszpont szerzésére nyílik lehetőség az aktív részvételen keresztül. A rendszeresen részt vevő csapatok óránként körülbelül 3–5 pontra számíthatnak. Ezek a számok tervezési iránymutatások, nem pedig garantált jutalmak: a tényleges összeg a rendelkezésre álló feladatoktól és a csapat részvételének minőségétől függ.
Heti elvárt eredmények¶
A legtöbb héten a csapatod kap egy listát az A hét előtt elvárt eredményekről. Ezek házi feladatként működnek: leírják, mit kell a csapatodnak a következő óra előtt teljesítenie ahhoz, hogy részt vehessen a következő tevékenységekben. Csak a csapat hivatalos GitLab-projektjében rögzített munka számít.
Az elvárt eredmények elfogadható szintű teljesítése nem jár automatikusan bónuszponttal – ez azt jelenti, hogy a csapatod felkészülten érkezett. A magas színvonalú vagy különösen alapos munka azonban bónuszpontokat érhet. A hiányzó, nem teljes vagy nem megfelelő munka pontlevonást vonhat maga után.
Az óra elején egyes csapatok kiválaszthatók eredményeik bemutatására. Ezért minden csapatnak készen kell állnia a munkája rövid bemutatására és magyarázatára.
Csapatok közötti szerződések¶
A csapatok szerződéseket köthetnek egymással, és bónuszpontokat használhatnak fizetőeszközként. Például az egyik csapat szolgáltatást nyújthat egy másiknak, például strukturált visszajelzést adhat, tesztelhet egy terméket, vagy megoszthatja releváns műszaki ismereteit. A csapatok szponzorálhatják is egy másik csapat munkáját, ha azt hasznosnak vagy értékesnek találják.
Ezek a szerződések nemcsak a pontok cseréjéről szólnak. Lehetőséget biztosítanak a szakmai kommunikáció és együttműködés gyakorlására: a szükségletek világos leírására, a felelősségek és eredmények egyeztetésére, a megállapodás dokumentálására és az ígéretek teljesítésére.
Részletes szerződési szabályok
Az elérhető szerződéstípusok, valamint a szerződések létrehozásának, dokumentálásának, teljesítésének és kifizetésének szabályai ezen az oldalon később lesznek leírva.
Hogyan használhatja fel a csapatod a bónuszpontokat?¶
Pontok felhasználása a végső értékelés során¶
A félév végén a csapatod legfeljebb 40 fennmaradó bónuszpontot válthat át rendszeres érdemjegypontokra. Ez a korlát az egész csapatra vonatkozik, nem pedig az egyes csapattagokra. A csapat dönti el, hogyan osztja el ezeket a pontokat a tagjai között, és az elosztásnak nem kell egyenlőnek lennie.
A csapatodnak nem kell felhasználnia a fennmaradó pozitív pontjait. A negatív egyenleg azonban adósság, amelyet szét kell osztani a csapat tagjai között, és le kell vonni az érdemjegypontjaikból. A csapat nem dönthet úgy, hogy figyelmen kívül hagyja. A csapat egyenlege nem eshet -30 bónuszpont alá, így ez az egész csapat lehetséges maximális adóssága.
Csapatok közötti szerződések¶
A csapatod bónuszpontokat költhet el vagy ruházhat át más hallgatói csapatokkal kötött szerződéseken keresztül. A pontokat felhasználhatja egyeztetett szolgáltatás – például strukturált visszajelzés, terméktesztelés vagy technikai segítség – megvásárlására. A csapatod anélkül is szponzorálhatja egy másik csapat munkáját, hogy cserébe közvetlen szolgáltatást kapna – például azért, mert a tervezett eredmény a saját projektje számára is hasznos lenne.
A bónuszpontok az egyik csapat egyenlegéről a másik csapat egyenlegére kerülnek át a szerződésnek megfelelően. Mielőtt bármilyen munka megkezdődne, mindkét csapatnak világosan meg kell állapodnia abban, hogy mit fognak nyújtani, és mennyi pont kerül átutalásra.
Részletes szerződési szabályok
A szerződésekre, kifizetésekre és szponzorációkra vonatkozó részletes szabályok később kerülnek fel erre az oldalra.
Csapatok közötti szerződések¶
A szoftvermérnökök ritkán dolgoznak kizárólag a saját csapatukon belül. A valós projektek gyakran függenek más fejlesztőktől, tesztelőktől, szakértőktől, ügyfelektől és külső szolgáltatóktól. A csapatok közötti szerződések biztonságos lehetőséget biztosítanak ezen együttműködési forma gyakorlására a kurzus során. A csapatod kérhet olyan tudást, visszajelzést, tesztelést vagy plusz kapacitást, amelyet önállóan nem tud hatékonyan biztosítani, miközben saját készségeit, eszközeit, tapasztalatait vagy hasznos erőforrásait ajánlhatja fel másoknak. Ehhez világosan el kell magyaráznod, mire van szükséged, meg kell állapodnod a várt eredményről, kommunikálnod kell a munka során, és bizalmat kell építened a felelősségek, határidők és a fizetés dokumentálásával. A bónuszpontok korlátozott költségvetésként szolgálnak, ezért a csapatodnak el kell döntenie, hogy mikor éri meg a külső segítség a költségét, és mikor éri meg a szolgáltatás nyújtása a ráfordítást. Olyan munkát is szponzorálhatsz, amely a projektednek, több csapatnak vagy a szélesebb kurzusközösségnek kedvez anélkül, hogy cserébe közvetlen szolgáltatást kapnál. Ezek fontos szoftvermérnöki készségek, mivel egy jó technikai megoldás megalkotása nem elég: koordinálnod kell másokkal, kezelned kell az erőforrásokat, betartanod a megállapodásokat, és segítened kell a különböző embereket a közös cél elérésében.
Általános szabályok¶
A csapatok közötti szerződések hivatalos megállapodásoknak minősülnek. Mindkét csapatnak meg kell értenie és el kell fogadnia a feltételeket az aláírás előtt.
- A szerződések kizárólag a kontakt órákon (személyesen) köthetők meg és kezelhetők.
- Szerződések a 4. héttől a 11. hétig bármelyik óra alkalmával köthetők, vagy az utolsó előtti óráig, ha az korábban van. A csapatok határozzák meg a teljesítési határidőt, és az oktató a teljesítés megfelelő igazolásának hetében "átutalja" a megegyezett bónuszpontokat.
- A megállapodást kézzel kell rögzíteni a hivatalos formanyomtatványon.
- A szerződés csak azután lép hatályba, hogy az oktató áttekintette, jóváhagyta és aláírta.
- A szerződés csak olyan kódra vagy dokumentációra vonatkozhat, amely már létezik. Az oktató ezt a jóváhagyás előtt ellenőrzi.
- Negatív bónuszpont-egyenleggel rendelkező csapat nem köthet új szerződést. A meglévő, érvényes szerződések érvényben maradnak.
A csapatok többségének jelen kell lennie: legalább 3 tagnak egy 4 vagy 5 fős csapatból, vagy 4 tagnak egy 6 fős csapatból. Minden résztvevő hallgatónak igazolnia kell a személyazonosságát.
Készítsétek elő a szerződést óra előtt
A szerződések kezelése sokkal gyorsabb, ha az egyeztetést lefolytatjátok és a formanyomtatványt kitöltitek óra előtt. Az aláírásokat hagyjátok üresen, amíg a szerződést az órán nem kezelik. Egy világosan és helyesen előkészített szerződés bónuszpontokat is érhet.
Etikus és professzionális magatartás
Mindkét csapatnak etikusan és professzionálisan kell viselnie magát az együttműködés során, és be kell tartania a kurzus szabványait a teljes szerződéses folyamat alatt. Ha ezeket az elvárásokat nem teljesítik, az oktató saját belátása szerint levonhatja a szerződésben szereplő bónuszpontok akár dupláját bármelyik vagy mindkét csapattól.
Szerződésteljesítés¶
Minden szerződés ugyanazt a teljesítési folyamatot követi. A csapatoknak fel kell tüntetniük a teljesítési határidőt a szerződésen annak jóváhagyása előtt. Ez a határidő később nem módosítható, ezért mindkét csapatnak gondosan kell terveznie, figyelembe kell vennie a lehetséges kockázatokat, és elegendő időt kell hagynia a munka elvégzésére.
A határidőt követő első jelenléti órán:
- Mindkét csapatnak jelen kell lennie a jelenléti szabályok szerint.
- Magukkal kell hozniuk a kitöltött szerződésteljesítési formanyomtatványt.
- A szolgáltatást fogadó csapatnak a formanyomtatványon meg kell erősítenie, hogy a megegyezett munka elkészült-e.
- Az oktató rögzíti az eredményt, és "átutalja" a megegyezett bónuszpontokat. Az oktató nem értékeli a szolgáltatást ügyfélként; kizárólag etikai moderátorként jár el.
Ha a csapatok nem mutatják be a teljesítési formanyomtatványt ezen az órán, mindkét csapat elveszíti a szerződésben feltüntetett bónuszpontokat. A levonás rögzítésre kerül, és legkésőbb az egyes csapatok pontjainak végső értékelés előtti elosztásakor érvényesül.
Szerződésszegés
Ha az egyik csapat megszegi a szerződést, a szerződésszegő csapatnak ki kell fizetnie a másik csapatnak a megegyezett bónuszpontok felét kártérítésként. Ez kárpótolja a másik csapatot az elvesztegetett időért, a felkészülésért, a tervezésért, a fenntartott kapacitásért vagy a megállapodás alapján elvégzett munkáért.
Oktatói közbelépés
Az oktató bármikor felbonthat egy szerződést, ha szakmai megítélése szerint visszaélést, etikátlan magatartást vagy nem megfelelő szakmai hozzáállást észlel. A kapcsolódó pontátutalásokat vagy büntetéseket a körülmények és a kurzusszabályok szerint határozzák meg.
Szerződéstípusok¶
A csapatok négyféle szerződést használhatnak attól függően, hogy milyen együttműködésre van szükségük. Minden esetben a szerződésnek egy meglévő és világosan azonosított GitLab-artifact-ból kell kiindulnia, le kell írnia az ígért munkát, és meg kell határoznia egy olyan kézzelfogható eredményt, amely a teljesítéskor ellenőrizhető.
| Szerződéstípus | Mire való? | Kiindulópont | Várható eredmény |
|---|---|---|---|
| Funkciószponzorálás (Feature Sponsoring) | Egy hasznos funkció támogatása egy másik csapat projektjében | Létező funkció issue és pontos kódverzió | A szponzorált csapat megvalósítja a funkciót a saját projektjében |
| Megvalósítás (Implementation) | Megkérni egy másik csapatot, hogy valósítson meg egy hibajavítást vagy funkciót a te projektedben | Létező issue és pontos kódverzió | Egy merge request a megvalósítással és a megegyezett kísérőanyagokkal |
| Felülvizsgálat (Review) | Megkérni egy másik csapatot, hogy vizsgálja meg a munkádat, és adjon szakmai visszajelzést | A felülvizsgálandó artifact-ok pontos verziója | Írásos felülvizsgálat megmagyarázott észrevételekkel és hasznos javaslatokkal |
| Tesztelés (Testing) | Megkérni egy másik csapatot, hogy próbálja ki a szoftvered megegyezett helyzetekben | Pontos futtatható verzió és útmutatások | Tesztjelentés, amely leírja, mit teszteltek és mi történt |
Artifact szó jelentése
Az artifact minden olyan dokumentum, modell, fájl vagy egyéb melléktermék, amely a szoftver tervezése, fejlesztése vagy üzemeltetése során jön létre. Nem magát a végterméket jelenti, hanem azokat az elemeket, amelyek segítik a fejlesztési folyamatot, dokumentálják a rendszert, vagy a végtermék építőkövei.
Funkciószponzorálás (Feature Sponsoring)¶
A Funkciószponzorálás lehetővé teszi, hogy a csapatod támogassa egy funkció fejlesztését egy másik csapat projektjében. A csapatod nem kapja meg a funkciót a saját kódbázisában. Ehelyett bónuszpontokat ígér, mert a funkciót hasznosnak, érdekesnek vagy értékesnek találja. A szponzorált csapat úgy érdemli ki a megegyezett pontokat, hogy megvalósítja a funkciót a saját projektjében, és biztosítja a megállapodott bizonyítékokat.
Ez a Kickstarterhez, a közösségi finanszírozáshoz vagy a belső vállalati finanszírozáshoz hasonló. Egy csapat bemutat egy ötletet, és elmagyarázza, miért érdemes támogatni. Más csapatok eldöntik, hogy bíznak-e annyira a javaslatban, hogy lekösse korlátozott bónuszpont-keretük egy részét. A szponzorált csapatnak ezután teljesítenie kell az ígéretét.
A funkciószponzorálási szerződésnek tartalmaznia kell:
- Kiindulópont: egy meglévő GitLab-issue és a fejlesztés megkezdése előtti pontos kódverzióra mutató hivatkozás (commit vagy tag).
- Ígért funkció: a hozzáadandó viselkedés vagy eredmény világos leírása. A hivatkozott issue-nak már tartalmaznia kell ezt az információt.
- Hatókör (Scope): mi tartozik bele a funkcióba, és mi nem.
- Elfogadási feltételek: konkrét és megfigyelhető feltételek, amelyek alapján eldönthető, hogy a funkció sikeresen elkészült-e.
- Szükséges bizonyítékok: általában releváns commitok, tesztek, dokumentáció, képernyőképek vagy egy működő bemutató.
- Megegyezett pontok és határidő: hány bónuszpontot utal át a szponzoráló csapat, és mikorra kell a funkciónak elkészülnie.
A szponzoráló csapat a megegyezett elfogadási feltételek ellenőrzésével erősíti meg a teljesítést. Az elkészült munkát az írásos szerződés alapján kell megítélnie – nem pedig a munka megkezdése után bevezetett új elvárások alapján. Az oktató etikai moderátorként jár el, és ellenőrzi, hogy a folyamat tisztességes és professzionális-e.
Példa
A Pine csapat 6 bónuszponttal szponzorálja a Fox csapatot, hogy adjon hozzá CSV-exportálást a Fox csapat alkalmazásához. A szerződés hivatkozik a meglévő funkciós issue-ra és az aktuális commitra. Kinyilvánítja, hogy a felhasználóknak képesnek kell lenniük a megjelenített rekordok érvényes CSV-fájlként való exportálására a megállapodott oszlopokkal. A teljesítést egy automatizált teszt, frissített felhasználói dokumentáció és egy rövid bemutató igazolja.
A funkciószponzorálás további motivációt ad a szponzorált csapatnak, és mutatja, hogy mások értéket ismernek fel az ötletében. A szponzoráló csapat megtanulja felmérni a javaslatokat, összehasonlítani a várt értéket a költséggel, és kezelni a korlátozott költségvetést. Mindkét csapat gyakorolja az ötletek bemutatását, a hatókör meghatározását, a mérhető eredményekben való megegyezést, a szállítás értékelését és a szakmai kötelezettségek vállalását.
Megvalósítás (Implementation)¶
A Megvalósítási szerződés lehetővé teszi, hogy a csapatod kérjen meg egy másik csapatot egy hibajavítás vagy új funkció megvalósítására a te projektedben. A szolgáltatást nyújtó csapat a meglévő kódoddal dolgozik, és az eredményt visszaszállítja a repozitóriumodba. Ellentétben a Funkciószponzorálással ez egy közvetlen szolgáltatás: a bónuszpontokat fizető csapat kapja meg a megvalósítást.
Ez hasonló a vállalkozó fogadásához, a külső fejlesztőcsapattal való munkához, vagy ahhoz, hogy megkérjünk egy másik csapatot egy vállalaton belül, hogy járuljon hozzá a termékünkhöz. A fogadó csapatnak világosan el kell magyaráznia, mire van szüksége, és mindent biztosítania kell a munka megkezdéséhez. A megvalósító csapatnak meg kell értenie az ismeretlen kódbázist, követnie kell annak konvencióit, és olyan munkát kell szállítania, amely ellenőrizhető és integrálható.
A megvalósítási szerződésnek tartalmaznia kell:
- Kiindulópont: egy meglévő GitLab-issue és a kódverzió pontos helye, amelyre a munkát alapozni kell.
- Szükséges bemenet: repozitória-hozzáférés, összeállítási (build) és futtatási utasítások, releváns dokumentáció, tesztadatok, konfiguráció és minden egyéb információ, amely a munka elvégzéséhez szükséges.
- Ígért megvalósítás: az a hibajavítás vagy funkció, amelyet a szolgáltató csapat szállítani fog.
- Hatókör: a rendszer mely részei módosíthatók, és mi esik a szerződésen kívülre.
- Elfogadási feltételek: konkrét és megfigyelhető feltételek annak eldöntésére, hogy a megvalósítás helyesen működik-e.
- Minőségi elvárások: megegyezett követelmények a tesztekre, dokumentációra, kódstílusra, kompatibilitásra vagy egyéb releváns minőségi mutatókra vonatkozóan.
- Szükséges bizonyítékok: egy merge request, amely tartalmazza a kódot, a releváns teszteket és dokumentációt, valamint az eredmény ellenőrzésére vonatkozó utasításokat.
- Megegyezett pontok és határidő: hány bónuszpont kerül átutalásra, és mikorra kell elvégezni a munkát.
A megvalósító csapatnak merge request formájában kell szállítania a munkáját, és azt nem olvaszthatja (merge) be a célágba. A fogadó csapat felülvizsgálja az eredményt, és eldönti, hogy az megfelel-e az írásos elfogadási feltételeknek. A szerződés eredményének elfogadása nem jelenti azt, hogy a fogadó csapatnak azonnal be kell olvasztania azt, de a döntést a megállapodott követelmények alapján kell meghozni, nem pedig a munka megkezdése után bevezetett preferenciák alapján.
Példa
A Pine csapat 8 bónuszpontot fizet a Fox csapatnak egy olyan hiba kijavításáért a Pine csapat alkalmazásában, amely miatt a szóközt tartalmazó feltöltött fájlneveket nem lehet megnyitni. A Pine csapat biztosítja az issue-t, a kiinduló commitot, a repozitória-hozzáférést és az alkalmazás futtatására vonatkozó utasításokat. A szerződés kimondja, hogy a nevekben szóközt tartalmazó fájloknak sikeresen fel kell töltődniük és meg kell nyílniuk anélkül, hogy elrontanák a meglévő feltöltési viselkedést. A Fox csapat szállít egy merge requestet, amely tartalmazza a javítást, egy automatizált regressziós tesztet és a változtatás rövid magyarázatát.
Ez a szerződés segít a fogadó csapatnak hasznos fejlesztési munkához jutni, miközben megtanulja pontosan leírni a technikai igényeket. A megvalósító csapat tapasztalatot szerez az ismeretlen kóddal, a meglévő konvenciókkal, a külső elvárásokkal és a professzionális szállítással kapcsolatban. Mindkét csapat gyakorolja a követelmények tisztázását, a ráfordítás és a kockázat becslését, a repozitóriumi együttműködést, a kód-felülvizsgálatot, a tesztelést, a dokumentációt és a megállapodott eredményért való felelősségvállalást.
Felülvizsgálat (Review)¶
A Felülvizsgálati szerződés lehetővé teszi, hogy a csapatod kérjen meg egy másik csapatot strukturált és független vélemény megadására egy meglévő artifact-ról. A felülvizsgált artifact szinte bármi lehet, ami a projekthez kapcsolódik, például GitLab-issue-k, forráskód, dokumentáció, értekezleti emlékeztető, terv, ötlet, prezentáció vagy előadás. A felülvizsgáló csapat nem írja át és nem valósítja meg a munkát, kivéve, ha a szerződés kifejezetten javasolt változtatásokat kér. Fő szállítandó eleme egy világos, hasznos és jól alátámasztott szakmai vélemény.
Ez hasonló a szakértői értékeléshez (peer review), a kód-felülvizsgálathoz, a tervkritikához, a szakértői konzultációhoz, vagy ahhoz, hogy megkérjük az érintetteket egy javaslat értékelésére, mielőtt további munkát fektetnénk bele. Egy külső csapat észreveheti azokat a tisztázatlan feltételezéseket, kockázatokat, inkonzisztenciákat vagy fejlesztési lehetőségeket, amelyeket az eredeti csapat már nem vesz észre.
A felülvizsgálati szerződésnek tartalmaznia kell:
- Felülvizsgálandó artifact-ok: pontos és stabil GitLab-hivatkozás, például issue, commit, merge request, dokumentumverzió, feltöltött prezentáció vagy értekezleti emlékeztető.
- A felülvizsgálat célja: amit a fogadó csapat meg akar tanulni vagy fejleszteni szeretne.
- Felülvizsgálati szempont: például technikai minőség, átláthatóság, megvalósíthatóság, karbantarthatóság, használhatóság, teljesség, konzisztencia vagy meggyőzőerő.
- Hatókör: az artifact mely részeit kell felülvizsgálni, és mi esik a szerződésen kívülre.
- Felülvizsgálati módszer vagy kritériumok: a kérdések, ellenőrző listák, irányelvek vagy szabványok, amelyeket a felülvizsgáló csapat használni fog.
- Ígért szállítandó elem: hol és hogyan lesz rögzítve a felülvizsgálat a GitLabban, például felülvizsgálati dokumentum, issue, issue alatti hozzászólás vagy merge request vita.
- Várható részletesség: mit kell tartalmaznia minden egyes észrevételnek, például a helyét, magyarázatát, fontosságát és egy megvalósítható javaslatot.
- Megegyezett pontok és határidő: hány bónuszpont kerül átutalásra, és mikorra kell befejezni a felülvizsgálatot.
A felülvizsgálati szerződésnek jelentőségteljes felülvizsgálati folyamatot és hasznos jelentést kell megkövetelnie, de nem írhat elő fix számú probléma megtalálását a felülvizsgáló csapat számára. Az artifact már lehet jó is, és a bírálóknak nem szabad gyengeségeket kitalálniuk csak azért, hogy elérjenek egy kvótát. A pozitív megállapítások is értékesek, ha elmagyarázzák, mi miért működik jól.
Példa
A Pine csapat 5 bónuszpontot fizet a Fox csapatnak hat funkciós issue felülvizsgálatáért a fejlesztés megkezdése előtt. A szerződés hivatkozik a pontos issue-kra, és felkéri a Fox csapatot annak ellenőrzésére, hogy minden egyes issue egyértelműen leírja-e a célját, a várt viselkedését, a határait és az elfogadási feltételeit. A Fox csapat egy új GitLab-issue-ban rögzíti a felülvizsgálatát, azonosítja a tisztázatlan részeket, elmagyarázza, miért okozhatnak problémákat a megvalósítás során, és konkrét javításokat javasol. Ha egy issue már világos, a felülvizsgálat elmagyarázza, miért kész a fejlesztésre.
A fogadó csapat külső nézőpontot kap, mielőtt a hibák drágává válnának. A felülvizsgáló csapat megtanulja gondosan megvizsgálni a munkát, alkalmazni az explicit kritériumokat, és úgy közvetíteni a kritikát, hogy ne vegye át az irányítást a másik csapat projektje felett. Mindkét csapat gyakorolja a kritikus gondolkodást, a minőségértékelést, a konstruktív visszajelzést, a professzionális kommunikációt és a tényeken alapuló döntéshozatalt.
Tesztelés (Testing)¶
A Tesztelési szerződés lehetővé teszi, hogy a csapatod kérjen meg egy másik csapatot annak vizsgálatára, hogy a szoftvered hogyan viselkedik a megegyezett feltételek mellett. A tesztelés lehet kézi vagy automatizált, és összpontosíthat a funkcionalitásra, a használhatóságra, a kompatibilitásra, a teljesítményre, a telepítésre, a hozzáférhetőségre vagy más releváns minőségi jellemzőre. A tesztelést szisztematikusan kell elvégezni: az alkalmazás egyszerű kipróbálása vagy terv nélküli kattintgatás nem elég.
Ez hasonló a független tesztelőcsapattal, minőségbiztosítási szakemberrel, béta-tesztelővel vagy külső laboratóriummal való munkához. A tesztelők megkapják a szoftver azonosított verzióját, követnek egy megegyezett megközelítést, rögzítik, mit tettek, és beszámolnak a történtekről. Feladatuk a megbízható bizonyítékok nyújtása – nem pedig annak bizonyítása, hogy a szoftver jó vagy rossz.
A tesztelési szerződésnek tartalmaznia kell:
- Tesztelendő szoftver: pontos futtatható verzió, amelyet kiadás, tag, commit, csomag, üzembe helyezett példány vagy más stabil hivatkozás azonosít.
- Szükséges bemenet: hozzáférési adatok, telepítési és használati útmutatók, tesztfiókok, tesztadatok, támogatott környezet és ismert korlátozások.
- Tesztelési cél: amit a fogadó csapat meg akar tudni a szoftverről.
- Hatókör: mely funkciók, felhasználói folyamatok, platformok, környezetek vagy minőségi jellemzők lesznek tesztelve.
- Tesztelési módszer: a forgatókönyvek, tesztesetek, ellenőrző listák, feltáró tesztelési keretrendszerek (exploratory testing charter), eszközök vagy egyéb szisztematikus megközelítés, amelyet használni fognak.
- Várható lefedettség: a tervezett munka kézzelfogható leírása, például a kiválasztott felhasználói utak, bemeneti kategóriák, környezetek vagy kompatibilitási kombinációk.
- Ígért szállítandó elem: a GitLabban tárolt tesztjelentés, amely leírja a környezetet, az elvégzett teszteket, a megfigyelt eredményeket és az alátámasztó bizonyítékokat.
- Jelentéstételi formátum: hogyan lesznek dokumentálva a hibák és a szokatlan viselkedések, ideértve a reprodukciós lépéseket, a várt és a tényleges viselkedést, a súlyosságot vagy hatást, valamint a releváns képernyőképeket vagy naplókat (logokat).
- Megegyezett pontok és határidő: hány bónuszpont kerül átutalásra, és mikorra kell befejezni a tesztelést.
A tesztelési szerződés nem írhat elő fix számú hiba megtalálását a tesztelő csapat számára. A jól működő szoftver kevés vagy semmilyen megállapítást nem eredményezhet. A teljesítést attól függően ítélik meg, hogy a megegyezett tesztelést szisztematikusan hajtották-e végre és megfelelően dokumentálták-e. A sikeresen lefutó teszt is hasznos eredmény, és a váratlan, de nem hibás viselkedést is rögzíteni kell, ha az segíthet a fogadó csapatnak.
Példa
A Pine csapat 5 bónuszpontot fizet a Fox csapatnak egy címkézett kiadás regisztrációs és bejelentkezési folyamatainak teszteléséért. A Pine csapat biztosítja az üzembe helyezett címet, a tesztfiókokat, a támogatott böngészőket és a használati utasításokat. A Fox csapat teszteli a megegyezett sikeres és sikertelen forgatókönyveket két böngészőben, beleértve az üres mezőket, a érvénytelen e-mail címeket, a helytelen jelszavakat és az ismételt bejelentkezési kísérleteket. Rögzíti a környezetet és az eredményeket egy GitLab-tesztjelentésben, és külön issue-kat hoz létre a reprodukálható hibákhoz.
A fogadó csapat bizonyítékokat szerez a szoftveréről olyan emberektől, akik kevésbé ismerik azt, így kevésbé valószínű, hogy tudatossággal kerülik el a problémákat. A tesztelő csapat megtanulja megtervezni az ismételhető ellenőrzéseket, figyelmesen megfigyelni a viselkedést, szétválasztani a tényeket a feltételezésektől, és úgy jelenteni az eredményeket, hogy egy másik fejlesztő cselekedni tudjon azok alapján. Mindkét csapat gyakorolja a teszttervezést, a minőségértékelést, a reprodukálhatóságot, a technikai kommunikációt, a bizonyítékok gyűjtését és a kockázatalapú gondolkodást.