Flowchart for bug triage-processen

Sådan fungerer det

1. Omdøb banerne til de roller, I har

   Erstat Anmelder, Support, Triage-ansvarlig, Udvikling og QA med jeres egne funktioner. Små teams lægger ofte support og triage i én bane, og et team uden en dedikeret QA-funktion flytter typisk verifikationen til en anden udvikler. Brug én bane pr. beslutningstager frem for pr. person — ellers holder diagrammet op med at passe, så snart nogen skifter job.

2. Skriv jeres definitioner af alvorlighed og prioritet på triage-trinnet

   Alvorlighed er konsekvensen, hvis fejlen opstår; prioritet er, hvornår der bliver arbejdet på den. Definer hvert niveau med et konkret eksempel — for eksempel datatab eller en blokeret betalingsflow øverst og en kosmetisk forskydning nederst. Uden eksempler ankommer alle rapporter på øverste niveau, og feltet holder op med at bære information.

3. Fastlæg tærsklen for eskalering

   Erstat den generiske beslutning 'Kritisk eller produktion nede?' med jeres reelle trigger: antal berørte kunder, en blokeret omsætningsvej, data i fare. Angiv, hvem der må erklære en hændelse, og hvor incident-processen ligger — triage overleverer fejlen på det tidspunkt, mens fejlsagen bliver stående åben til den permanente rettelse.

4. Beslut, hvor længe informationssløjfen kører

   Beslutningen 'Svarer anmelderen i tide?' kræver en angivet ventetid og som regel én rykker. Skriv tallet på trinnet. Uden det står rapporter, der aldrig kunne reproduceres, åbne i det uendelige, og backloggen holder op med at afspejle reelt arbejde.

5. Aftal, hvad verifikation betyder, og hvor en genåbning lander

   Angiv, om QA verificerer mod anmelderens oprindelige trin, mod en regressionssuite eller begge dele. Denne skabelon sender en fejlet verifikation tilbage til udvikling på den samme sag, så historikken bliver ét sted. Ret den til at gå tilbage til triage, hvis en genåbnet fejl skal prioriteres på ny frem for at blive taget op igen med det samme.

6. Udgiv den, og hold én gældende version

   Læg diagrammet ved siden af fejlrapporteringsformularen og i vagt-runbooken, indhent godkendelse fra support, udvikling og QA, og gem de tidligere versioner, så I kan se, hvornår processen ændrede sig. Tag den frem igen efter enhver fejl, der tog markant længere tid end den burde, og ret det trin, hvor den gik i stå.

Ofte stillede spørgsmål

Hvilke faser består en bug triage-proces af?

Fem i de fleste teams. Modtagelse, hvor rapporten registreres med nok detaljer til at kunne handles på. Reproduktion, hvor support bekræfter, at fejlen findes og ikke er en konfigurations- eller brugerfejl. Triage, hvor dubletter knyttes sammen, og alvorlighed, prioritet og et ansvarligt team tildeles. Rettelse, som dækker udvikling og code review. Verifikation, hvor QA tjekker rettelsen mod den oprindelige rapport, før den frigives, og anmelderen får besked. Diagrammet ovenfor bruger de fem som faser, hvor reproduktion og triage bærer de beslutninger, der gør det meste af arbejdet.

Hvad er forskellen på alvorlighed og prioritet?

Alvorlighed beskriver fejlens konsekvens: datatab, et blokeret arbejdsflow, en kosmetisk fejl. Prioritet beskriver, hvornår der bliver arbejdet på den. De besvarer forskellige spørgsmål og bør blive i hvert sit felt. En slåfejl i en offentliggjort pris har lav alvorlighed og høj prioritet; et nedbrud i en funktion, to kunder bruger, kan have høj alvorlighed og lav prioritet. At slå dem sammen til ét felt er den mest udbredte grund til, at en triage-proces mister troværdighed — for så ender alt i toppen af skalaen.

Hvor ofte skal bug triage køre, og hvem skal deltage?

En kort, tilbagevendende gennemgang af alt, der er kommet ind siden sidst: dagligt for et live forbrugerprodukt, to gange om ugen ved langsommere releasecyklusser. Tre roller er som regel nok til at beslutte: en fra support, der kan tale om kundekonsekvensen, en triage-ansvarlig, der ejer alvorlighed og prioritet, og en udviklingsansvarlig, der ved, hvilket team der ejer koden. Alt, der er kritisk eller udgør et produktionsnedbrud, skal ikke vente på mødet — derfor eskalerer dette diagram det straks til en hændelse i stedet for at sætte det i kø.

Hvad skal der ske med en fejl, der ikke kan reproduceres?

Luk den — men først efter en eksplicit sløjfe. Bed én gang om de manglende detaljer (build, miljø, præcise trin, en skærmoptagelse), ryk inden for en angivet ventetid, og luk derefter som 'kan ikke reproduceres' med begrundelsen noteret og en åben invitation til at genåbne, hvis fejlen opstår igen. Denne skabelon tegner den sløjfe som en beslutning i Anmelder-banen frem for at overlade den til den enkeltes skøn, fordi rapporter, der ikke kan reproduceres og bliver stående åbne, er præcis dét, der gør en backlog til en liste, ingen læser.