Je kent het wel: je hebt een bug gevonden en zet die gewoon in een registratiesysteem. En als je dan deze wil reproduceren weet je niet meer hoe. In dit artikel leg ik je uit hoe je dat kunt voorkomen.
Via het onderstaande template kan je eenvoudig een bug registreren. Eerst geef ik je het template en daarna de uitleg.
Het template
- De titel
- Situatie/ het scenario
- Uitkomst
- Reproductie
- Verwachting
Dat is het! Helemaal niet ingewikkeld. Nu hieronder de uitleg per onderdeel. Ow, en onderaan de uitleg heb ik ook nog wat beschreven over de testdata! Dit is echt heel belangrijk.
De titel
Dit is heel belangrijk. Net als een pakkende kop boven een artikel. En zodra je ergens al langer aan het testen bent kan je ook af en toe afkortingen gebruiken. Stel je moet een bussinesregel testen en die heeft een bepaalde code, dan kan je die in de titel gebruiken. Bijvoorbeeld: BR001 – scherm X – deze blijft hangen als ik op knop X druk.
De situatie/ het scenario
Wat was je aan het doen waardoor je deze bug hebt gevonden? Vertel in dit stukje wat je aan het doen was. Vertel niet hoe je hier kwam want dat doe je verderop.
Reproductiestappen
Hier leg je stap voor stap uit hoe de bug is ontstaan. En, neem van mij aan, dit mag echt zo kinderlijk mogelijk. Stel je maar voor tijdens het vastleggen dat je tegen een bejaarde praat die net heeft leren kaarten op de computer. Hieronder een voorbeeld:
- klik op de knop met titel X
- je gaat naar een nieuwe pagina
- ga helemaal naar beneden tot je afbeelding Y ziet staan
- etc etc etc.
Als je dat op deze manier vastlegt kan je zelf later ook nog zien of het klopt. De ontwikkelaar kan dan ook sneller analyseren wat er goed is gegaan of niet. Plus, en dat is voor later, kan je deze stappen ook gebruiken voor het maken van een handleiding.
Afbeeldingen en links
Vergeet geen afbeeldingen toe te voegen! Er zijn genoeg apps die je kunnen helpen met afbeeldingen te maken. Ik heb hier een overzicht met tools. Daar staan ook programma’s tussen voor afbeeldingen.
Uitkomst
Hier beschrijf je dan wat de uitkomst is. En dat hoeft echt niet uitgebreidt. Hier beschrijf je gewoon wat er gebeurt. Niet meer of minder. Bijvoorbeeld: de applicatie blijft hangen en je kunt niet meer verder.
Verwachting
Dit is hetzelfde, over het algemeen, als de uitkomst. Alleen dan het tegenovergestelde. Soms kan het ook zo zijn dat er dan iets moet gebeuren. Dat kan je dan hier ook beschijven.
Specificatie toevoegen
Wat je hier ook bij kunt vermelden is een stuk uit de story of specificatie. Zo kan je de verwachting onderbouwen en kracht bij zetten. De ontwikkelaar kan dan ook vaak nog even nalezen wat er dan moet gebeuren. Ik heb de ervaring dat ontwikkelaars soms iets over het hoofd hebben gezien. Soms is de specificatie niet duidelijk is en dat dit nog naar de tekentafel moet.
De testdata toevoegen
Wat je echt niet moet vergeten bij te voegen is de testdata! Wat versta ik onder testdata?
- testid’s, nummers etc.
- testcontent als afbeeldingen, sheets, bestanden
- testscripts als sql scripts, queries
- etc
Dus eigenlijk alles wat je hebt gebruikt om dit te testen of wat de bug heeft veroorzaakt.
