Blog

Wat is een slecht bugreport?

Het is waarschijnlijk nuttig om eerst de achterliggende reden van deze blogpost aan te halen. Rond het rapporteren van bugs heerst er bij veel developers (niet alleen bij ons) grote frustratie. Al te vaak krijgen we een bugreport binnen via een collega of klant zonder klaar en duidelijk te melden wat er mis is, of erger: met verkeerde informatie. Ik denk dat iedereen wel al eens één van volgende mails heeft zien voorbij komen.

• Hij doet het niet!
• Er staat een fout op de website!
• Er gebeurt niks bij het verzenden van het formulier.
• Niks werkt er! Ik kan niks doen!

De frustratie van de persoon die de bug rapporteert straalt er vaak van af en is te begrijpen, maar met deze informatie raakt een developer geen meter verder. Het is in ieders belang dat een bug snel, efficiënt en correct opgelost wordt, en dat kan enkel door een goed bugreport in te sturen.

Wat staat in een goed bugreport?

Eerst en vooral moeten we het doel van een bugreport duidelijk maken. Een bugreport heeft als doel een developer in staat te stellen zo snel en makkelijk mogelijk een bug te vinden, reproduceren en oplossen. In principe zou de developer door het lezen van het bugreport al onmiddelijk een idee moeten hebben waar de oorzaak van de bug mogelijk kan liggen. Om dit te bewerkstelligen hebben we voldoende nuttige en correcte informatie nodig.

Jouw omgeving is de mijne niet

Geef de developer een beetje krediet, waarschijnlijk gebruikt hij een andere setup en systeem waardoor de bug bij hem nog niet is voorgekomen of hij de bug nog niet heeft gezien. Vermeld daarom zeker je besturingssysteem (bv. Windows Vista) en je browser (bv. Internet Explorer 7) in het report. Vaak gebruiken wij een tool zoals www.supportdetails.com die naast de twee bovenstaande items nog een heleboel extra informatie verzamelt over het systeem van de gebruiker.

In sommige gevallen is het ook niet duidelijk of een bug gevonden werd in de dev, staging of live omgeving van een website. Vermeld dus best ook altijd het webadres waar de bug zich heeft voorgedaan, dit kan later nuttig blijken.

Indien je software of website gebruik maakt van versienummers kan je deze ook best vermelden, het is namelijk goed mogelijk dat het een bug betreft die al gerepareerd is in een nieuwere versie van de software en dus een dubbel is. Vaak is een update van de software dan voldoende om de bug op te lossen.

Wat heb je gedaan?

Aan “Het werkt niet” hebben we niet veel. In principe zou je er vanuit moeten gaan dat je voldoende specifieke informatie geeft in het bugreport zodat de developer de bug kan reproduceren.

Welke handelingen heb je uitgevoerd die verband kunnen houden met de bug? Heb je net een instelling veranderd? Heb je net iets verwijderd? Dit kan allemaal waardevolle informatie zijn.

Vermeld in een aantal duidelijke stappen/punten wat er gebeurd is. Leg uit hoe je te werk bent gegaan, welke gegevens je ingevuld hebt, op welke knoppen je gedrukt hebt, enz … Hoe meer informatie hoe beter maar gebruik niet te veel veronderstellingen. Beperk je tot de feiten.

Dit is een voorbeeld van een goede omschrijving wat iemand gedaan kan hebben in enkele duidelijke stappen.

1. Meld aan als beheerder
2. Ga naar de gebruikersmodule
3. Klik op de knop “nieuw”
4. Geef “root” in als gebruikersnaam en eender welk wachtwoord
5. Druk op “opslaan”

Wat is er gebeurd?

Natuurlijk wil de developer die je bug gaat moeten oplossen ook weten wat er precies is mis gelopen. Vermeld daarom altijd wat er gebeurd is. Wat zag je, waaraan zag je dat het mis ging? Stond er een foutmelding op het scherm? Vermeld die dan ook letterlijk en integraal in je report. Dit kan zeer waardevolle informatie bevatten voor de developer.

Zet ook altijd het webadres waar de fout voorkomt in het report en voeg een screenshot toe van de fout indien van toepassing.

Wat had er moeten gebeuren?

Belangrijk is zeker ook te vermelden wat er had moeten gebeuren. Vaak gebeurt het dat een tool of software verkeerd gebruikt wordt en hierdoor foutmeldingen verkeerd als bug worden aanzien. Meld daarom zeker ook wat je probeerde te doen en wat het eindresultaat had moeten zijn. Misschien is het de bedoeling van het systeem om zo te reageren omdat je er als gebruiker verkeerd gebruik van maakt?

Samenvatting

Kort samengevat bestaat een goed bugreport uit een aantal essentiële onderdelen. Al deze onderdelen zouden in het report moeten staan.

• Welke browser, computer, besturingssyteem, … gebruikte je?
• Wat is de precieze url waarop de fout voorkwam?
• Wat heb je gedaan om de bug te vinden?
• Wat is er gebeurd?
• Wat had er moeten gebeuren?

Het belangrijkste is eigenlijk dat je te allen tijde grondig en duidelijk bent als je een bug rapporteert. Vaak zit het in de details als het over bugs gaat, het zijn die details die een developer op voorhand zou moeten weten zodat hij snel aan de slag kan met het oplossen van de bug in plaats van eerst veel tijd te verliezen met het zoeken naar een manier om de bug te reproduceren.

Heb je zelf nog tips heb je een paar "customer-from-hell" scenario's meegemaakt wat bugs rapporteren betreft? Deel dan je ervaringen door een reactie achter te laten onder deze blogpost!