Jeg ved godt jeg ikke er med i dette projekt, men da jeg lever af at teste software, kan jeg ikke holde fingerene fra denne tråd. Håber det er OK. Følgende skal udelukkende opfattes som forslag og gode råd
Da der er tale om et mindre projekt uden en tydelig kravsspecifikation eller projektplan, er der naturligt nok heller ikke hverken teststrategi eller testplan, og som en naturlig følge heraf heller ikke testcases. Det betyder at ting som testdækning, fejlhåndtering o.lign. ikke er formaliseret, hvilket vil betyde, at der slipper fejl igennem. Men husk, at der altid slipper fejl igennem, intet kan testets 100%, men dette må ikke blive en undskyldning for at undlade test eller dele af test. Spiltest er ikke bare at gennemføre et spil et par gange. Det er gentagende (og til tide dødkedeligt) arbejde.
Med alt dette i mente, vil jeg foreslå, at der udnævnes en testkoordinator (test-lead), der sørger for at fordele testopgaver, lave testcases samt samle op på fejlmeldinger.
Testcases bør som minimum være en beskrivelse af;
Preconditions: hvilke kriterier skal være opfyldt for at gennemføre en testcase (f.eks. specifik jre, build, styresystem osv.),
Steps: Hvad skal gennemføres
Forventet resultat: Er der f.eks. kendte fejl man skal se bort fra under testen
Ovenstående punkter sikrer en ensrettet test, når flere testere gennemfører de samme testcases.
Der findes masser af gratis fejlhåndteringsværkstøjer (projektet benytter allerede Subversion til kodespor, der findes en issue tracker til dette), Jira er også ganske udemærket. Uanset hvad I vælger, så sørg for at formalisere fejlrapporterne, som minimum med;
Fejl: detaljeret beskivelse af fejlen. Hellere en linie for meget end en linie for lidt
Setup: Hvilket setup blev benyttet (alt fra drivere til skræmopløsning har relevans her).
Steps to reproduce: Kan fejlen genskabes, så beskriv hvordan (dette er skelettet til testcases, når fejlen er rettet).
Bilag: Skrærmbilleder, logs, fejlmeddelelser alt hvad systemet returnerer lægges til fejlrapporten.