Een kwaliteitsmelding wegklikken is ook een besluit.

De melding verdwijnt. Het risico misschien niet.

Op 13 oktober 2026 introduceerde GitHub auditregistratie voor het handmatig afwijzen en heropenen van Code Quality-bevindingen. De registratie bevat onder meer wie de actie uitvoerde, wanneer en welke bevindingen erbij hoorden. De uitbreiding is beschikbaar op GitHub Team en Enterprise Cloud, niet op Enterprise Server. [1]

Dat maakt handelingen beter traceerbaar. De inhoudelijke vraag blijft: waarom was deze beslissing verantwoord? Een dashboard met minder open meldingen vertelt nog niet of de software is verbeterd. Voor Quality Engineering is juist de verbinding tussen signaal, onderzoek en besluit belangrijk.

Geef verschillende besluiten een eigen betekenis

Een automatische controle geeft aanleiding tot onderzoek. Soms wijst ze op een defect, soms ontbreekt context en soms past de regel niet bij de gekozen oplossing. GitHub beschrijft bijvoorbeeld dat een bevinding kan worden afgewezen wanneer die niet relevant of bruikbaar is. [2]

SonarQube maakt expliciet onderscheid: Accepted betekent dat herstel wordt uitgesteld, terwijl False positive aangeeft dat de analyse volgens de beoordelaar onjuist is. [3] De precieze statussen verschillen per hulpmiddel. Spreek daarom binnen het team af wat een status inhoudelijk betekent.

Gebruik “onterechte melding” alleen wanneer je kunt onderbouwen waarom de analyse niet klopt. Een echt probleem met een lage prioriteit blijft een echt probleem. En een risico bewust accepteren vraagt een afweging over gevolgen en bevoegdheid. Die drie situaties verdienen verschillende uitleg, ook wanneer de interface uiteindelijk dezelfde sluitknop biedt.

Onderzoek wat er werkelijk kan gebeuren

Neem een fictief voorbeeld. Een controle signaleert dat een fout bij het opslaan van een klantverzoek wordt opgevangen zonder verdere afhandeling. Een ontwikkelaar vermoedt dat een andere laag de gebruiker al informeert. Dat vermoeden is een onderzoeksvraag, geen reden om de melding direct te sluiten.

Volg het uitvoerpad en simuleer de opslagfout. Blijft het verzoek bewaard? Ziet de gebruiker een melding? Is herstel mogelijk? Als niemand de mislukking zichtbaar maakt, kan werk verloren gaan. Als de andere laag aantoonbaar de afgesproken afhandeling verzorgt, leg dat bewijs vast bij de bevinding.

Dit voorbeeld beschrijft geen SBIT-klantproject. Het laat zien hoe je van een technische melding naar een concrete gebruikersverwachting gaat. Beoordeel de mogelijke impact en de omstandigheden waarin het probleem optreedt. Gebruik de ernstclassificatie van de scanner als input, met kennis van het product en het werkproces erbij.

Leg een klein maar bruikbaar besluit vast

Een goede onderbouwing hoeft geen rapport te worden. Onderstaande checklist is een voorgestelde teamafspraak, geen ingebouwde verplichting van GitHub. Bewaar haar bij de bevinding of in een gekoppeld ticket, zodat een collega de beslissing later kan reconstrueren.

1. Waarneming: welke regel, codeversie en situatie zijn onderzocht? Link naar de bevinding en het relevante uitvoerpad.
2. Bewijs: welke controle, test of analyse ondersteunt de conclusie? Noteer ook wat nog onzeker is.
3. Besluit: herstellen, verder onderzoeken, uitstellen of gemotiveerd afwijzen. Beschrijf het resterende risico in begrijpelijke taal.
4. Eigenaarschap: wie volgt het werk op en wie mag het risico accepteren? Sluit aan op bestaande bevoegdheden en escalatieafspraken.
5. Herbeoordeling: bij welke wijziging of op welke datum bekijken we dit opnieuw? Koppel uitgesteld herstel aan zichtbaar vervolgwerk.

Maak uitzonderingen niet permanent uit gewoonte

Een besluit geldt binnen een context. Een interne functie kan later extern beschikbaar worden. Een klein gegevensvolume kan groeien. Een aanname over foutafhandeling kan na een refactor verdwijnen. Laat zulke veranderingen aanleiding zijn om relevante uitzonderingen opnieuw te bekijken.

Plan daarom naast herstelwerk ook een korte periodieke controle op uitgestelde bevindingen. Controleer of de eigenaar nog betrokken is, de onderbouwing nog geldt en de afgesproken termijn niet ongemerkt is verstreken. Een heropenende melding is geen persoonlijke nederlaag; nieuwe informatie kan een ander besluit rechtvaardigen.

Voor duidelijke technische afwijkingen kan een ontwikkelaar binnen teamafspraken beslissen. Voor risico’s met bredere bedrijfsimpact moet de passende verantwoordelijke worden betrokken. Quality Engineering helpt het risico en het bewijs scherp te krijgen. Het neemt daarmee niet automatisch het zakelijke mandaat over.

Gebruik de registratie om samen te leren

Bekijk aantallen gesloten meldingen altijd samen met hun redenen. Veel herhaalde onterechte meldingen kunnen aanleiding zijn om een regel of configuratie te onderzoeken. Veel uitgestelde echte problemen kunnen vragen oproepen over capaciteit, ontwerp of prioriteiten. Zoek het patroon voordat je een conclusie over mensen trekt.

Begin klein: kies deze week enkele recent gesloten bevindingen en bespreek met development, Quality Engineering en de Product Owner of de besluiten begrijpelijk zijn. Kan een collega zien wat onderzocht is, welk risico overblijft en wanneer vervolg nodig is? Vul ontbrekende informatie aan en maak één werkafspraak voor volgende meldingen.

Zo ontstaat bruikbare feedback uit automatisering. Voor SBIT hoort kwaliteit bij de manier waarop teams beslissingen voorbereiden en opvolgen. Een melding sluiten kan terecht zijn. Zorg dat de reden net zo duidelijk is als de status.