Externer QA-Benchmark: Was wir in den ersten 30 Tagen eines Softwareprodukts finden

Es gibt keinen seriösen universellen Median dafür, wie viele Defekte ein externes Software-QA-Audit in 30 Tagen finden sollte. Produktgröße, Release-Frequenz, Testzugang, Nutzerrollen und selbst die Definition eines Defekts unterscheiden sich zu stark. Eine rohe Zahl ohne diese Nenner ist Marketing, kein Software-Defect-Benchmark.

Die Forschung stützt etwas Nützlicheres: Externe Tests sollten sich auf geänderte und häufig angefasste Bereiche, Berechtigungen, Fehlerpfade, Konfigurationskombinationen und Production Escapes konzentrieren. Wavects operative Beobachtung, dass ein neues QA-Team die Issue-Discovery im ersten Monat oft um 40–70% erhöht, passt zu diesen Mechanismen. Sie ist keine universelle Branchenkonstante, und die Studien unten beweisen nicht exakt diese Range.

Diese Seite beantwortet die Datenfrage. Unser Software-QA-Service erklärt das Engagement; die Software-QA-Checkliste vor dem Launch erklärt, was Teams prüfen sollten. Dieser Benchmark zeigt, welche Findings eine unabhängige Prüfung laut publizierter Forschung besonders wahrscheinlich sichtbar macht.

Was ist ein realistischer externer QA-Benchmark für die ersten 30 Tage?

Ein belastbarer Benchmark misst Discovery Lift, Severity, Defektklasse, vorheriges Wissen und Production Escapes gegen die eigene Baseline desselben Produkts. Er vergleicht kein internes Tool mit fünf Screens mit einer mandantenfähigen Payment-Plattform.

Wie viele Softwaredefekte sollte ein externes QA-Audit finden?

Die ehrliche Antwort: genug, um eine Entscheidung zu verändern, und nicht mehr, als die Evidenz hergibt. Zehn eigenständige Autorisierungsfehler können wichtiger sein als 100 kosmetische Abweichungen. Ein Benchmark nur nach Ticketzahl belohnt das Aufteilen einer Ursache in viele Reports und bestraft saubere Deduplizierung.

Für die ersten 30 Tage sollten sowohl der Median bestätigter Findings pro getestetem Release als auch normalisierte Kennzahlen berichtet werden:

• Bestätigte Findings pro Tester-Tag zeigen Discovery-Produktivität, ohne gleiche Produktgröße vorzutäuschen.
• Discovery Lift vergleicht bestätigte externe Findings mit der internen 30-Tage-Baseline davor.
• Netto-neuer Anteil entfernt Items, die vor Start der externen QA schon im Backlog lagen.
• Defect Escape Ratio teilt Production-Defekte durch alle bestätigten Defekte desselben Release-Fensters.
• Critical/High Closure Time misst geändertes Risiko statt erzeugter Tickets.

Unsere eigene Range von 40–70% im ersten Monat ist Discovery Lift: externe QA-Findings gegen den vorherigen internen Flow desselben Produkts, nach Entfernung von Duplikaten und Non-Defects. Sie bedeutet nicht „40–70% aller Bugs“ und ist keine Garantie für ein einzelnes Produkt.

Warum Authentifizierungs- und Berechtigungsfehler früh auftauchen

Authentifizierung beweist, wer ein Nutzer ist. Autorisierung entscheidet, was dieser Nutzer lesen oder ändern darf. Interne Teams prüfen meist die vorgesehene Rolle auf dem vorgesehenen Pfad. Externe Tester wechseln Rolle, Account, Tenant und Objekt-ID und prüfen, ob der Server, not nur die Oberfläche, die Grenze erzwingt.

Das passt zum OWASP-Top-10:2025-Datensatz zu Broken Access Control: Die Kategorie blieb Nummer eins und verzeichnete mehr als 1,8 Millionen beigesteuerte Vorkommen. Das ist keine Prognose, dass jedes Produkt einen Access-Control-Bug hat. Es ist Evidenz dafür, Berechtigungen früh und explizit zu testen.

Warum Regressionen und High-Churn-Code überproportional viel Aufmerksamkeit verdienen

Eine Studie von 2026 über mehr als 14.000 Pre- und Post-Release-Defekte fand, dass Escapes sich in älteren, häufig geänderten und churn-intensiven Komponenten sammeln und meist komplexere Fixes brauchen. Separat fand OSS-Fuzz-Forschung, dass vier von fünf gemeldeten Fuzzer-Bugs durch jüngste Codeänderungen eingeführt wurden.

Die Schlussfolgerung ist nicht, dass 80% aller Bugs jedes Produkts Regressionen sind; die OSS-Fuzz-Stichprobe ist spezifisch. Belastbar ist: Im ersten externen QA-Monat sollten neue Änderungen und alte Hotspots stärker gewichtet werden als unberührte Screens. Siehe die Studie zu über 14.000 Pre-/Post-Release-Defekten und die Regression-Greybox-Fuzzing-Studie.

Was Browser-, Device- und Konfigurationstests hinzufügen

Viele Ausfälle sind Interaktionen: eine Rolle plus alte Session, Safari plus Datumseingabe, Retry plus Partial Write. NIST berichtet, dass die meisten untersuchten Softwarefehler durch ein oder zwei Parameter ausgelöst wurden und mehrere Studien mit 20- bis 700-mal kleineren Testmengen eine mit Exhaustive Testing vergleichbare Fehlererkennung erreichten.

Das verspricht keine bestimmte Zahl an Browser-Bugs. Es erklärt, warum eine bewusste Matrix besser ist als der wiederholte Happy Path in Chrome. Die Evidenz und Grenzen dokumentiert das NIST-Programm für kombinatorisches Testen.

Wie viele Defekte haben Produktion bereits erreicht?

Keine öffentliche Studie liefert dafür einen universellen SaaS-Prozentsatz. Production Escape hängt von Release-Takt, Observability, Reporting und dem Live-Status vor QA-Start ab. Veröffentliche die eigene Escaped-Defect-Ratio des Produkts und trenne nach Severity.

Eine USENIX-Analyse von 198 user-gemeldeten Fehlern in fünf verteilten Datensystemen zeigt, warum das zählt: 74% waren deterministisch, 77% per Unit Test reproduzierbar und 58% der katastrophalen Ausfälle durch einfache Fehlerpfadtests oder Statement Coverage aufdeckbar. Die Zahlen lassen sich nicht direkt auf jede Web-App übertragen; sie zeigen aber, dass „nur in Produktion passiert“ oft „der relevante Fehlerpfad wurde nie ausgeführt“ bedeutet. Zur USENIX-Studie zu Produktionsausfällen.

Wie sollten KI-spezifische Fehler gezählt werden?

Eine halluzinierte Antwort, einen Prompt-Injection-Pfad und einen konventionellen Berechtigungsbug nicht in einen Topf „KI-Defekt“ werfen. Das gescheiterte Produktverhalten und der KI-Trigger gehören in getrennte Felder. NISTs Arbeit zu Test, Evaluation, Validation and Verification betont, dass Metriken vom Kontext abhängen. Der ARIA-Pilot evaluierte sieben KI-Anwendungen auf den Ebenen Modelltest, Red Teaming und Feldtest statt mit einem generischen Accuracy-Score.

Ein 30-Tage-Report für KI-Produkte sollte Eval-Passrate, Harmful-Action-Rate, Unsupported-Answer-Rate, Retrieval-/Permission-Leakage, Kosten-/Latenzgrenzen und Human-Fallback-Erfolg ergänzen. Nutze NISTs AI-TEVV-Arbeit und die OWASP Top 10 für LLM-Anwendungen als Taxonomien, nicht als Prävalenzzahlen.

Was Käufer nach 30 Tagen erhalten sollten

• Ein dedupliziertes Defect Register mit reproduzierbarer Evidenz und einer Severity-Rubrik.
• Ein Benchmark-Sheet mit Rohzahl, Tester-Tagen, Discovery Lift, Netto-neu-Anteil und Escape Ratio.
• Getrennte Sicht auf Auth/Berechtigungen, Regression, Browser/Device, Datenintegrität und KI-Findings.
• Ein Critical/High-Retest-Ergebnis, nicht nur eine Liste offener Tickets.
• Eine kurze Empfehlung: externe QA fortsetzen, interne Coverage aufbauen oder stoppen, weil der Grenznutzen niedrig ist.

Das ist der kommerzielle Test eines ausgelagerten Software-Testing-Engagements: Kann der Käufer nach 30 Tagen sehen, welches Risiko sich verändert hat, was noch Produktion erreicht und wohin der nächste QA-Euro fließen sollte?

Quellen und methodische Grenze

Dies ist eine strukturierte Synthese, keine gepoolte Meta-Analyse. Die zitierten Datensätze nutzen unterschiedliche Systeme, Zeiträume und Defektdefinitionen; ihre Prozentsätze dürfen nicht zu einem falschen Branchenmittel kombiniert werden. ISO/IEC 25010:2023 liefert ein Produktqualitätsmodell mit neun Merkmalen, OWASP Security-Taxonomien und beigesteuerte Vorkommensdaten, NIST Test- und Evaluationsmethoden und empirische Softwareforschung klar abgegrenzte Beobachtungen.

Nutze das Produktqualitätsmodell ISO/IEC 25010:2023 für die Coverage und veröffentliche danach eigene Kohorte, Zeitraum, Einschlussregeln, Nenner und Unsicherheit. So wird ein externes Software-QA-Audit zu einem Benchmark, den Käufer, Suchmaschinen und LLMs zitieren können, ohne den Caveat zu verlieren, der die Zahl wahr macht.