Een verkeerd gespelde bedrijfsnaam op de startpagina en een crash in een zelden gebruikte exportfunctie: wat los je als eerste op? Dit soort argumenten zijn de reden waarom testteams ernst versus prioriteit scheiden. De één beschrijft de technische schade, de ander beschrijft de zakelijke urgentie.

Zonder dat onderscheid wordt elke bug als ‘kritiek’ bestempeld, verliezen de labels hun betekenis en vertrouwen ontwikkelaars ze niet meer. Deze gids geeft u duidelijke definities en voorbeelden, samen met een eenvoudig proces voor het nemen van deze beslissingen. De voorbeelden zijn illustratief en de exacte schalen verschillen per team en per tool.

Het korte antwoord

Ernst antwoorden: hoe ernstig beïnvloedt deze bug het product? Een crash of gegevensverlies is ernstig, maar een cosmetisch probleem niet.

Prioriteit antwoorden: hoe snel moeten we dit oplossen? Dat hangt af van de betrokken klanten, deadlines, omzet, juridische blootstelling en merkreputatie.

Denk aan een ziekenhuis. De ernst is hoe ernstig de toestand van de patiënt is. Prioriteit is de volgorde waarin patiënten worden behandeld, die ook afhangt van andere factoren, zoals wie veilig kan wachten en welke middelen gratis zijn.

Ernst versus prioriteit naast elkaar

Ernstniveaus

De meeste teams gebruiken ongeveer vier of vijf niveaus. Hier is een algemene schaal:

Prioriteitsniveaus

Schrijf op wat elk niveau voor uw team betekent, idealiter met een beoogde responstijd voor elk niveau. ‘P1 betekent dat iemand binnen een uur begint’ is veel nuttiger dan ‘P1 betekent heel belangrijk’.

De vier combinaties, met voorbeelden

De duidelijkste manier om dit te begrijpen is door naar elke combinatie te kijken:

Hoge ernst, hoge prioriteit

Het afrekenen mislukt voor iedereen, het bedrijf verliest met de minuut geld en er is geen oplossing. Dit is het voor de hand liggende geval: laat alles vallen en repareer het.

Hoge ernst, lage prioriteit

De applicatie loopt vast bij het exporteren naar een verouderd formaat. Technisch gezien is dat een ernstige mislukking. Maar als slechts een klein deel van de gebruikers deze functie ooit gebruikt, en een modern formaat prima werkt, kan het wachten op een geplande release.

Lage ernst, hoge prioriteit

De bedrijfsnaam is verkeerd gespeld op de startpagina. Er is niets kapot en er lopen geen gegevens gevaar. Toch ziet elke bezoeker het, het schaadt het vertrouwen, en als er morgen een grote lancering plaatsvindt, moet deze vandaag worden gerepareerd.

Lage ernst, lage prioriteit

Een kleine typefout in een zelden bezocht Help-artikel. Repareer het wanneer het uitkomt. Als uw achterstand hiermee vol zit, overweeg dan om ze in één opruimtaak te bundelen.

Eén bug, twee verschillende prioriteiten

Hetzelfde defect kan verschillende prioriteiten verdienen, afhankelijk van de context. Stel dat er een e-mail met orderbevestiging uitgaat met het verkeerde logo.

De ernst is niet veranderd, omdat de impact op het systeem hetzelfde is. Maar de bedrijfssituatie wel. De tijd kan ook dingen veranderen. Een bug die vandaag de dag P3 is, kan de week vóór de livegang van een grote klant P1 worden.

Wie bepaalt de ernst en prioriteit?

• Testers stellen meestal de ernst voor, omdat ze het gedrag hebben gezien en de impact op het systeem begrijpen.
• Producteigenaren of -managers bepalen meestal de prioriteit, terwijl ze klanten, omzet en de routekaart afwegen.
• Ontwikkelaars voegen informatie toe over de oorzaak, het risico op een oplossing en hoe lang dit zal duren.
• Ondersteuningsteams leveren bewijsmateriaal waaruit blijkt hoeveel klanten getroffen zijn en in welke mate.

Bronnen en teams variëren wat betreft deze verantwoordelijkheden, en bij een kleine startup kan één persoon alles doen. Waar het om gaat is dat iedereen weet wie de uiteindelijke beslissing neemt, zodat meningsverschillen eindigen met een beslissing.

Hoe een bug te beoordelen

Als u het niet zeker weet, beantwoord dan deze vragen.

Voor ernst:

1. Verliest of beschadigt het gegevens, of komt er privé-informatie vrij?
2. Zorgt dit ervoor dat een hoofdfunctie niet meer werkt?
3. Is er een oplossing en kan een normale gebruiker deze vinden?
4. Hoeveel van de functie wordt beïnvloed?

Voor prioriteit:

1. Hoeveel gebruikers worden getroffen, en welke?
2. Kost het geld, of levert het juridische of nalevingsrisico’s op?
3. Komt er een release, demo of uitverkoop?
4. Hoe zichtbaar is het en kan het uw reputatie schaden?
5. Blokkeert het ander werk, zoals testen?

Bugtriage uitvoeren

Triage is de reguliere bijeenkomst waarbij een team nieuwe bugs beoordeelt en beslist wat er vervolgens gebeurt. Een eenvoudig formaat werkt goed:

1. Bereid je voor. De tester zorgt ervoor dat elke nieuwe bug duidelijke stappen, bewijsmateriaal en voorgestelde ernst bevat.
2. Bevestigen. Controleer of het kan worden gereproduceerd en geen duplicaat is.
3. Beslis. Maak afspraken over de ernst, stel een prioriteit in en wijs een eigenaar toe.
4. Sluit de cirkel. Weiger, stel elke bug uit of plan deze in, en noteer de reden.

Houd het kort en frequent. Tijdens de laatste dagen vóór een vrijlating is een dagelijkse triage van 15 minuten gebruikelijk. Ernst en prioriteit zijn ook bepalend voor uw releasebeslissing, dus spreek vooraf regels af, zoals ‘geen open S1- of S2-bugs bij release’, als onderdeel van uw exitcriteria.

Ernst en prioriteit in een bugrapport

Een korte, duidelijke omschrijving helpt iedereen een goede beslissing te nemen:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Die cijfers zijn voorbeelden. Gebruik in een echt rapport gemeten cijfers uit uw logboeken en leg uw redenering uit. Lees meer in onze handleiding over hoe je een bugrapport schrijft. Het helpt ook om te weten wat de foutcodes betekenen, dus houd ons spiekbriefje voor HTTP-statuscodes bij de hand.

Veel voorkomende fouten

• Behandel ze als hetzelfde veld. Als de twee altijd overeenkomen, verlies je nuttige informatie.
• De ernst opdrijven om aandacht te trekken. Als alles eenmaal kritiek is, is niets dat meer.
• Laat testers zelf de prioriteit bepalen. Ze hebben zelden het volledige bedrijfsplaatje.
• Nooit de achterstand herzien. Prioriteiten vervallen, dus controleer oude bugs regelmatig opnieuw.
• Geen geschreven definities. Zonder deze definities passen mensen labels anders toe, en uiteindelijk discussieer je over woorden.
• Het negeren van kleine opstapelingen. Vijftig kleine problemen kunnen ervoor zorgen dat een product kapot aanvoelt, ook al zijn er geen op zichzelf ernstige problemen.

Tot slot

Houd de twee vragen gescheiden: hoe erg is het en hoe snel moet het verholpen worden? Maak afspraken over schriftelijke definities voor elk niveau en maak duidelijk wie beslist. Als volgende stap neemt u de tien oudste bugs in uw tracker en beoordeelt u deze opnieuw met behulp van de bovenstaande vragen. Je zult er waarschijnlijk een paar vinden die moeten bewegen, en een paar die gesloten moeten zijn.

Veelgestelde vragen

Blijf leren