📊 statistics

An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

Dit artikel stelt een distributievrije bovengrens voor op de waarschijnlijkheid dat een gebruiker een niet-ontdekte softwarefout tegenkomt, waarbij wordt aangetoond dat het fractie van defecten die tijdens de bètatest exact één keer zijn gerapporteerd ( $s/n$ ) dient als een conservatieve, modelonafhankelijke schatting die geschikt is voor releasebeslissingen.

Oorspronkelijke auteurs: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Gepubliceerd 2026-07-21

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Grote Bug Hunt: Waarom het tellen van bugs niet genoeg is

Stel je voor dat je een chef-kok bent die een gigantisch banket gaat serveren aan duizenden gasten. Voordat je de deuren opent, heb je een team van proefproeverij-experts (je bètatesters) die het eten hebben gegeten en uitroepen: "Hé, deze soep is te zout!" of "Er zit een steen in deze cake!" Je lost de problemen op die zij vinden. Maar hier komt de angstaanjagende vraag: Als je nu de deuren opent, wat is dan de kans dat een willekeurige gast die binnenloopt, een steen bijt die jij hebt gemist?

Dit is de kern van een probleem in de informatica dat "softwarebetrouwbaarheid" wordt genoemd. Decennialang hebben ontwikkelaars geprobeerd dit te beantwoorden door te tellen. Ze vragen: "Hoeveel stenen liggen er nog in de keuken?" Ze gebruiken complexe wiskunde om het totale aantal verborgen bugs te raden. Maar er is een addertje onder het gras: weten dat er tien stenen over zijn, vertelt je niet of ze allemaal achterin de voorraadkast liggen (waar misschien maar één persoon ze vindt) of dat er één enorme rotsblok direct bij de voordeur staat (waar iedereen over struikelt). De oude methoden blijven vaak hangen in het proberen te tellen van de stenen, waarbij ze negeren dat sommige stenen veel gevaarlijker zijn dan andere vanwege de locatie waar ze zich bevinden.

Om dit op te lossen, moeten we stoppen met het tellen van stenen en beginnen met het tellen van mensen. We moeten weten wat de waarschijnlijkheid is dat een willekeurige persoon tegen een probleem aanloopt. Dit artikel behandelt precies die vraag: in plaats van te vragen "Hoeveel bugs zijn er nog over?", vraagt het: "Wat is de kans dat een gebruiker een bug tegenkomt die hij nog nooit eerder heeft gezien?" Het blijkt dat er een verrassend eenvoudige manier is om dit te raden, met een truc die kijkt naar hoe vaak testers dezelfde bug meer dan één keer vinden.

Het Grote Idee van het Papier: De "One-Time Wonder" Regel

De auteurs, Carlos M. Hernández-Suárez en Karla Hernández-Cuevas, stellen een slimme afkorting voor. Ze suggereren dat om de kans te raden dat een gebruiker een verborgen bug tegenkomt, je niet het totale aantal bugs hoeft te weten, hoe de software is gebouwd, of zelfs hoeveel mensen het gebruiken. Je hoeft alleen maar naar je bugrapporten te kijken en iets heel specifieks te tellen: de bugs die precies één keer zijn gerapporteerd.

Laten we een analogie gebruiken. Stel je voor dat je een detective bent die probeert uit te zoeken hoeveel verschillende soorten buitenaardse wezens je stad bezoeken. Je hebt een logboek met waarnemingen.

Als je "Zog" 50 keer ziet, weet je dat Zog een veelvoorkomende alien is.
Als je "Xyl" 3 keer ziet, is Xyl een beetje zeldzamer.
Maar als je "Blorp" precies één keer ziet, en nooit meer, wat zegt dat dan?

Het artikel betoogt dat deze "Blorps"—de bugs die precies één keer zijn gezien—de sleutel vormen. Ze noemen de fractie van deze enkelvoudige waarnemingen ( $s$ ) gedeeld door het totaal aantal waarnemingen ( $n$ ) een "conservatieve bovengrens". In gewone mensentaal: Het percentage bugs dat precies één keer is gerapporteerd, is een veilige, "worst-case" schatting voor het percentage gebruikers dat een gloednieuwe, ongeziene bug zal tegenkomen.

Waarom dit werkt (De "Gesloten Deur" Logica)

Je zou je kunnen afvragen: "Wat als er bugs verborgen zitten achter andere bugs? Zoals een geheime kamer achter een gesloten deur?" De auteurs gaan dit aan met een briljant stuk logica.

Stel je voor dat de software een groot landhuis is met veel kamers. Sommige bugs zitten in de gang (makkelijk te vinden). Sommige zitten in een geheime kamer achter een gesloten deur (moeilijk te vinden).

Als een gebruiker de gesloten deur raakt (een bug), kan hij niet in de geheime kamer erachter komen.
Daarom is het aantal mensen dat de geheime kamer kan bereiken altijd kleiner dan of gelijk aan het aantal mensen dat de gesloten deur raakt.

De auteurs laten zien dat, vanwege deze "geneste" structuur, je je geen zorgen hoeft te maken over de verborgen kamers. De "single-report" bugs die je wel hebt gevonden, dekken al het risico van de verborgen ones af. Als een bug één keer wordt gerapporteerd, fungeert deze als een "deur" die het risico van alles daarachter beperkt. Dus het tellen van de enkelvoudige rapportages is voldoende om het hele huis te dekken.

Wat ze deden en wat ze vonden

De auteurs hebben niet alleen gegokt; ze hebben een wiskundig model gebouwd genaamd de "Canonical Form" (denk aan een speciale soort urn of pot gevuld met gekleurde ballen). Ze hebben wiskundig bewezen dat als je je bugrapporten behandelt als het trekken van ballen uit deze pot, de fractie van de ballen die slechts één keer voorkomen ( $s/n$ ) de exacte maximum-likelihood schatting is voor de "missing mass" (de ongeziene bugs).

Cruciaal is dat ze hebben aangetoond dat deze schatting conservatief is. Dit betekent dat deze de kans de neiging heeft om de risico's te overschatten in plaats van te onderschatten.

Waarom dit goed is: Als je een ontwikkelaar bent die moet beslissen of je software gaat releasen, wil je veilig zijn. Als de wiskunde zegt "Er is een kans van 5% op een bug," en de echte kans is 3%, dan ben je veilig. Als de wiskunde 3% zei en de echte kans was 5%, dan zou je in de problemen zitten. Deze methode zorgt ervoor dat je altijd aan de veilige kant blijft, waarbij je uitgaat van voorzichtigheid.

Ze hebben dit idee getest met computer-simulaties (het creëren van fictieve populaties van bugs met bekende antwoorden).

In één test met 20 bugs ontdekten ze dat naarmate ze meer gebruikers "testten" (het vergroten van de steekproefomvang van 25 naar 400), hun schatting ( $s/n$ ) altijd hoger dan of gelijk aan het werkelijke aantal ongeziene bugs was.
Bijvoorbeeld, met 100 testgebruikers was het werkelijke ongeziene risico 0,0059, en hun schatting was 0,0063. De schatting was iets te hoog (conservatief), maar nooit te laag.

Wat dit NIET is (De regels van het spel)

Het papier is zeer duidelijk over wat deze methode niet kan doen, en het is belangrijk dit goed te begrijpen:

Het is NIET bedoeld om bugs te tellen. Het vertelt je niet "Er zijn nog 50 bugs over." Het vertelt je "Er is een kans van 2% dat een gebruiker een bug tegenkomt."
Het is NIET voor publieke buglijsten. De auteurs sluiten expliciet uit dat dit gebruikt kan worden op standaard bugdatabases (zoals die op internet). Waarom? Omdat in die lijsten een bug meestal één keer wordt gerapporteerd door één persoon, zelfs als 1.000 mensen hem hebben gevonden. De "telling" gaat verloren. Om deze methode te gebruiken, heb je data nodig die zegt: "Deze bug werd door 50 verschillende gebruikers geraakt," en niet alleen: "Deze bug is gerapporteerd."
Het is GEEN magische kristallen bol voor de toekomst. Het geeft een momentopname van het risico op dit moment. Als je de bugs oplost en opnieuw test, moet je de berekening opnieuw uitvoeren.

De Kern van de Zaak

Dit artikel biedt een direct, no-nonsense antwoord op de beslissing om te releasen. Het zegt: "Maak je geen zorgen over hoeveel bugs er in het donker schuil de. Kijk gewoon naar hoeveel bugs je testers precies één keer hebben gevonden. Dat aantal, gedeeld door je totale tests, is je veilige, bovengrens-schatting voor hoeveel gebruikers vast komen te zitten op een bug die jij hebt gemist."

Het is een instrument dat een complexe, angstaanjagende onzekerheid omzet in een simpel, veilig getal, zodat ontwikkelaars een helder en conservatief beeld hebben van het risico voor hun gebruikers wanneer de software wordt uitgebracht.

Technische Samenvatting: Een bovengrens op de waarschijnlijkheid dat een gebruiker een niet-ontdekt defect tegenkomt

Probleemstelling
Het artikel behandelt een kritiek besluitvormingsgat in software release management: het bepalen van de waarschijnlijkheid dat een gebruiker van een uitgebracht product een defect tegenkomt dat niet tijdens de bètatest is ontdekt. Bestaande literatuur richt zich primair op het schatten van het aantal resterende defecten (met behulp van software reliability growth models of capture-recapture methoden) of de dekking van ongeziene klassen in fuzzing-contexten. Deze benaderingen slagen er echter niet in om direct de release-vraag te beantwoorden omdat:

Op aantallen gebaseerde methoden een "operationeel profiel" vereisen (de distributie van hoe software in het veld wordt gebruikt) om een defectaantal om te zetten naar een door de gebruiker ervaren falingswaarschijnlijkheid. Dit profiel is uiterst moeilijk in te schatten.
Dekkingsmethoden (bijv. Good-Turing) zijn toegepast op software fuzzing, waarbij de "sampler" een machine is die inputs genereert. In deze context weerspiegelt de overvloed van een bug de willekeur van de machine, niet de frequentie waarmee menselijke gebruikers het tegenkomen.
Structurele complexiteit: Software is geen vlakke, uitwisselbare populatie zoals biologische soorten; het heeft een bereikbaarheidsstructuur (bomen of DAG's) waarbij sommige defecten "achter" andere defecten liggen. Bestaande methoden houden geen rekening met hoe deze architectuur de waarschijnlijkheid beïnvloedt dat een gebruiker een specif근 defect tegenkomt.

De auteurs stellen dat de beslissing over de release een directe schatting vereist van de gebruikersgewogen ontbrekende massa (user-weighted missing mass): de waarschijnlijkheid dat een willekeurige gebruiker een defect uitvoert dat nog niet in de test is gezien.

Methodologie
Het artikel stelt een distributievrije estimator voor gebaseerd op de canonieke urn-constructie (Hernández-Suárez [10]), aangepast voor de software release-context.

Data-interpretatie: Elk bèta-testrapport wordt behandeld als een trekking uit de gebruikerspopulatie, en elk afzonderlijk defect wordt behandeld als een "klasse". De invoerdata is de set van rapport-aantallen voor elk defect.
De Canonieke Vorm: De auteurs definiëren een populatiemodel waarbij klassen worden onderverdeeld in:
- Gewone klassen: Defecten die meerdere keren zijn waargenomen.
- Het Reservoir (All-different component): Een theoretisch component met een oneindig aantal klassen met verwaarloosbaar kleine waarschijnlijkheden, zodanig dat elke trekking uit dit reservoir een unieke, voorheen ongeziene klasse oplevert.
Maximum Likelihood Estimation (MLE):
- Het artikel demonstreert dat onder de canonieke vorm de fractie van defecten die precies één keer zijn gerapporteerd ( $s/n$ ), waarbij $s$ het aantal singletons is en $n$ het totaal aantal rapporten, de exacte Maximum Likelihood Estimate (MLE) is van de ongeziene proportie ( $U$ ).
- Conservatieve Bias: De canonieke vorm wijst elk singleton (een defect dat precies één keer is gezien) toe aan het "ongeziene reservoir" in plaats van het te behandelen als een zeldzame gewone klasse. Hierdoor overschat de schatting $s/n$ systematisch de werkelijke ongeziene proportie. Dit creëert een eenzijdige, conservatieve bovengrens, wat de gewenste richting is voor een release-beslissing (fouten vermijden door aan de veilige kant te blijven).
Afhandeling van Architectuur: De methode is invariant voor de interne structuur van de software (boom versus DAG). De auteurs argumenteren dat de "bereikbaarheid" van een defect al is gecodeerd in de rapport-aantallen: een defect achter een gesloten deur wordt door nul gebruikers gerapporteerd, terwijl een defect op een veelvoorkomend pad door vele gebruikers wordt gerapporteerd. Omdat de estimator uitsluitend op deze aantallen vertrouwt, begrenst het automatisch het risico van geneste, verborgen defecten zonder het bereikbaarheidsgrafiek te hoeven modelleren.

Belangrijkste Bijdragen

Herformulering van de Estimand: Het artikel verschuift de focus van het schatten van een residueel defect aantal naar het schatten van de waarschijnlijkheid dat een gebruiker een ongezien defect tegenkomt, waardoor de noodzaak voor een operationeel profiel wordt geëlimineerd.
Theoretische Rechtvaardiging: Het biedt een rigoureuze MLE-fundering voor de $s/n$ estimator binnen de canonieke urn-framework, en bewijst dat $s/n$ de exacte MLE is van de ongeziene massa onder deze constructie.
Conservatieve Bovengrens: Het stelt vast dat $s/n$ niet louter een schatting is, maar een conservatieve bovengrens op het gebruikersrisico, aangezien de canonieke constructie singletons in het ongeziene reservoir dwingt, waardoor de schatting het risico nooit onderschat.
Structurele Invariantie: Het toont aan dat de estimator robuust is voor de complexiteit van de softwarearchitectuur, aangezien de veelvoud aan rapporten de bereikbaarheidsbeperkingen inherent vastlegt.
Validatie: De estimator wordt gevalideerd tegen synthetische populaties met een bekende grondwaarheid (ground truth), waarbij wordt bevestigd dat de gemiddelde schatting de werkelijke ontbrekende massa consistent evenaart of overstijgt ( $E[s/n] \geq E[U]$ ).

Resultaten

Synthetische Validatie: Experimenten op synthetische populaties (zowel uniforme als heavy-tailed) laten zien dat de $s/n$ estimator accuraat maar consistent conservatief is. In scenario's waar de populatie bijna verzadigd is (alle defecten gevonden), nadert de werkelijke ontbrekende massa nul, terwijl $s/n$ positief blijft door de overmatige toewijzing van singletons aan het ongeziene reservoir.
Eenzijdige Aard: De waarschijnlijkheid dat de schatting de werkelijke ongeziene proportie overschrijdt is hoog (bijv. 0,89 tot 1,00 in de geteste scenario's), wat de betrouwbaarheid van de grens voor risicomijdende beslissingen bevestigt.
Datavereisten: Het artikel benadrukt dat de methode encounter-level data vereist (bijv. bèta-kanaal telemetrie of crashrapporten die registreren hoeveel gebruikers per defect werden getroffen). Het stelt expliciet dat standaard publieke defectarchieven ongeschikt zijn omdat deze doorgaans een enkele vermelding per bug registreren, ongeacht hoeveel gebruikers de bug tegenkwamen, waardoor de benodigde veelvoud-data verloren gaat.

Betekenis en Claims
Het artikel claimt een direct, distributievrij antwoord te bieden op de software release-vraag. De betekenis ligt in:

Het overbruggen van de kloof: Het verbindt de statistische theorie van dekking (Good-Turing) met de praktische beperkingen van software release, waarbij specifet wordt ingegaan op het "gebruikersgerichte" karakter van het risico.
Eliminatie van Aannames: Het elimineert de noodzaak voor operationele profielen, aannames over het totale aantal defecten of modellen van de interne structuur van het programma.
Besluitvormingsondersteuning: Het biedt een principieel, conservatief metriek ( $s/n$ ) waarmee ontwikkelaars kunnen beslissen wanneer ze releasen: door te blijven testen totdat de bovengrens van de waarschijnlijkheid dat men een ongezien defect tegenkomt, onder een getolereerde risicodrempel valt.

De auteurs blijven bescheiden over de beperkingen van de methode en merken op dat deze van toepassing is op de softwarestatus op het moment van berekening en specifieke typen telemetrie-data (encounter-level) vereist in plaats van standaard bug tracking logs. Ze beweren niet het probleem van het schatten van het totale aantal defecten op te lossen, maar wel de specifieke waarschijnlijkheid van gebruikersblootstelling aan het onbekende.