Bugs melden voor beginners

Soms kan het best lastig zijn om het precieze probleem uit jouw hoofd en in het hoofd van de ontwikkelaar te krijgen, en dan duurt het oplossen van de bug ook veel langer. Maar met de geheime superkracht ‘goede bugs melden’ kun je dit hele proces enorm versnellen!

1. Wat was je aan het doen?

Waar klikte je op of wat had je getypt toen het systeem niet deed wat je verwachtte? In welke browser, of op wat voor mobiel apparaat? Dit zijn voor de ontwikkelaar allemaal aanwijzingen wat er mis kan zijn gegaan. Grote kans dat je alsnog een hele sloot vragen terugkrijgt over de precieze omstandigheden, maar met een goede omschrijving kunnen al heel veel mogelijke issues worden uitgesloten. Het liefst zien we een ‘reproductiepad’: alle stappen die we na moeten spelen om jouw probleem te zien gebeuren.

ZEG NIET:

“Het betaalsysteem is kapot!”

ZEG WEL:

“Toen ik een kwartaalabonnement pepernoten probeerde te bestellen via de iOS-app was het knopje ‘afrekenen’ grijs en kon ik er niet op klikken.”

2. Wat verwachtte je?

Soms ontstaan bugs door een programmeerfout, maar heel vaak ook door interpretatie- of communicatiefouten. Dan had de ontwikkelaar iets anders begrepen dan de product owner bedoelde (die kan dit voorkomen door de perfecte user story te schrijven). Of misschien probeer je iets te doen wat helemaal niet de bedoeling is en doet het systeem het op zich goed, maar moeten we juist iets verbeteren aan de gebruikerservaring. Of het is wél een programmeerfout, omdat we niet met alle scenario’s rekening hadden gehouden. In al deze gevallen helpt het enorm als je duidelijk zegt wat je dacht dat het systeem ging doen.

ZEG NIET:

“Hoezo maandabonnement?”

ZEG WEL:

“Ik verwacht dat ik naast een maandabonnement ook een kwartaal- of jaarabonnement pepernoten af kan sluiten, net als bij onze chocoladekoekjes- en dropveterabonnementen.”

3. Wat is de prioriteit?

Mijn persoonlijke favoriete bug was er eentje die, twee weken na de start van een project dat over acht maanden live moest gaan, als ‘prioriteit 1 blokkerend’ werd aangemerkt door de klant. ‘P1 blockers’ zijn het equivalent van een piepende hartmonitor op de intensive care: het betekent ‘laat alles uit je handen vallen en FIX DIT NU’. Er zijn natuurlijk problemen waarvoor dit nodig is, maar daar hoort ‘moet over een maand of zeven wel eens gemaakt zijn’ niet bij.

We willen daarom graag weten:

• Kun je wat je probeert te bereiken ook (tijdelijk) op een andere manier doen?
• Hoeveel gebruikers hebben last van hetzelfde als jij? (Als de site helemaal wit is voor iedereen die Chrome gebruikt: best veel. Als het alleen voor gebruikers van de Vivaldi-browser (de wat? precies.) is, mwah.
• Zijn er andere systemen die hierdoor ook problemen hebben of gaan krijgen?

Dit soort dingen willen we niet horen om te weten hoe lang we je aan het lijntje kunnen houden, maar zodat we goed in kunnen schatten wat er uit de formule “aantal gebruikers * hoe irritant de bug is / hoe lastig het is om op te lossen” komt. En die formule is vaak bepalend voor de volgorde waarin we dingen repareren.

ZEG NIET:

“PANIEEEEEK!”

ZEG WEL:

“Dit moet voor de 3e van de volgende maand worden opgelost, omdat we dan nieuwe facturen gaan aanmaken.

Succes met bugs jagen!

Met deze drie stappen meld je voortaan alleen nog superduidelijke en meteen geprioriteerde bugs. En vinden de ontwikkelaars je zo tof dat het best wel eens zou kunnen dat jouw issues per definitie wat hoger op de stapel worden gelegd… Veel plezier!