A hétvége során rengeteg rossz megoldást láttunk, ezért is lett meghosszabbítva a beadási határidő. A hibák legtöbbször szövegértési gondokra vezethetők vissza, hadd mutassak be néhány tipikus hibát, kérdést, és azokra a választ:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tipikus hiba #1: A dokumentáció nem tartalmazza a fedést tartalmazó képernyőképeket, vagy tartalmaz ilyeneket, de azon nem látszik a ChessClockStatemachine.java fedése
Ez szerintünk feketén fehéren le van írva, hogy a dokumentációnak tartalmaznia kell a fedést ábrázoló képernyőképeket, így nem nagyon tudunk mit kezdeni azzal, aki ezeket nem adta be.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tipikus hiba #2: A tesztkészlet áttekintő leírása nem szerepel.
Nagyon sokan gondolták úgy, hogy leírják az összes tesztesetüket, hogy melyik részletesen mit csinál (rosszabb esetben csak beszúrják a forráskódot, hogy abból olvassuk ki) és ezt szánják áttekintő leírásnak. Ez pont annyira áttekintő leírás, mint az Aranyember olvasónaplója címén beadni az eredeti könyvet, mert abban úgyis minden információ szerepel.
Minden teszteset részletes leírása többnyire felesleges, mert a chessclock.feature fájl tartalmazza ezeket, és a Gherkin nyelv miatt abszolút olvasmányosan (a feladat egyik célja ezt megmutatni a hallgatóknak). Ellenben szerepelnie kéne itt annak, hogy hány teszteset van, ezek közül hány teszteset célozza az A funkció tesztelését, hány teszteset célozza a B funkció tesztelését, ... Célszerű lehet itt megemlíteni, ha a teszteseteket hierarchiába lehet szervezni. Esetleg meg lehet tenni azt is, hogy a sakkóráról egy képet is mellékelni, amin színkódolással ábrázolva van, hogy melyik teszteset, mely éleket / állapotokat fedi.
Továbbá tartalmaznia kéne ennek a résznek a fedésről szóló információkat. Mint az előadásokon szerepelt, rengeteg fedési metrika van, itt pontosan meg kéne jelölni, hogy melyiket használtátok.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tipikus hiba #3: Nincsenek tervezési szempontok
Szintén nagyon sokan azt tekintik tervezési szempontoknak, hogy "Célom volt maximális fedést elérni". Ez bár lehet igaz, de ez a feladat célja volt (a kiírás szerint), és egyedüli vezérlő szempontként kevés. Amit ezalatt elvárnánk, hogy miért az az X teszteset került megvalósításra, részletes indoklással, gondolatmenettel. Analógiaként, ahogyan egy BSZ ZH-ban is elvárják a gondolatmenet leírását, és csupán a végeredmény közléséért nem jár pont, itt is, csupán a tervezés kimenetének közlése (a tesztesetek) nem elegendő.
Mint a feladatkiírásban szerepel, a pontozás szempontja, a munka reprodukálhatósága. A tervezési szempontokat tartalmazó részt úgy kell megírni, hogy ha két független ember ez alapján készítene teszteseteket, akkor ugyanazokkal a tesztesetekkel álljanak elő. Itt amit ki lehet fejteni az a szisztéma, ami alapján a tesztek kialakításra kerültek, a további tesztesetek kialakításához használt visszacsatolások, ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tipikus kérdés #1: Ha a fenti dolgokat mind megcsinálom, akkor a 10 pontot megkapom?
A rövid válasz az, hogy nem. Mint írtuk:
A feladat értékelésének alapja a tesztelt modell helyessége, az elért
kódfedettség, a dokumentáció minősége, és a megoldás dokumentáció
alapján való reprodukálhatósága, továbbá a védésen nyújtott szóbeli
teljesítmény.
Ennek része az, hogy akinek nem sikerül 100%-os fedettséget elérnie, az megmagyarázza, hogy miért nem sikerült az, része az, hogy a dokumentáció igényesen van formázva, a munka ez alapján reprodukálható, a benne szereplő információk helytállóak, valamint az, hogy a hallgató a szóbeli védésen felkészülten, a felmerült kérdésekre helytállóan tud válaszolni.
