Katalog
concept#Qualitätssicherung#Zuverlässigkeit#Observability#Softwareentwicklung

Defect Metrics

Systematische Kennzahlen zur Erfassung, Bewertung und Steuerung von Software-Defects. Unterstützt Priorisierung, Qualitätsüberwachung und Trends zur kontinuierlichen Verbesserung.

Defect Metrics sind messbare Kennzahlen, die Auftreten, Schwere und Behandlung von Software-Fehlern quantifizieren.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Issue-Tracker (z. B. Jira, GitHub Issues)CI/CD- und Build-Systeme für automatische Metrik-ErfassungObservability-Tools zur Korrelation mit Produktionsfehlern

Prinzipien & Ziele

Messgrößen sind handlungsorientiert und auf Entscheidungen ausgerichtet.Kombiniere quantitative Kennzahlen mit qualitativen Ursachenanalysen.Standardisiere Definitionen (Was ist ein Defect?) über Teams hinweg.
Iteration
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Gaming der Kennzahlen statt echter Qualitätsverbesserung.
  • Überfrachtung der Teams mit Metrik-Reporting-Aufwand.
  • Falsche Priorisierung leidt die Kundenwahrnehmung.
  • Verwende sowohl absolute Zahlen als auch Relative-Kennzahlen.
  • Kombiniere automatisierte Metriken mit Ursachenanalysen.
  • Setze Metriken in Beziehung zu Geschäftsauswirkungen.

I/O & Ressourcen

  • Fehler-Tickets mit Metadaten (Datum, Komponente, Severity)
  • Quellcode-Größenangaben oder LOC-Metriken
  • Testresultate und Testabdeckung
  • Dashboards mit Trend- und Heatmap-Visualisierungen
  • Priorisierte Defect-Backlogs und Handlungspläne
  • KPIs für Release-Entscheidungen

Beschreibung

Defect Metrics sind messbare Kennzahlen, die Auftreten, Schwere und Behandlung von Software-Fehlern quantifizieren. Sie ermöglichen Trendanalysen, Priorisierung von Fehlerbeseitigung und Bewertung von Release-Qualität. Richtig angewendet verbessern sie Transparenz und lenken Investitionen in Wartung und Qualitätssicherung.

✔

  • Verbesserte Transparenz über Qualitätstrends und Hotspots.
  • Bessere Priorisierung von Wartungsaufwand und Ressourcen.
  • Objektive Entscheidungsgrundlage für Release-Freigaben.

✖

  • Metriken können ohne Kontext irreführend sein.
  • Unterschiedliche Erfassungspraktiken erschweren Vergleichbarkeit.
  • Fokus auf Zahlen kann Ursachenanalyse vernachlässigen.

  • Defect Density

    Anzahl Defects pro 1.000 Lines of Code; dient zum Vergleich von Komponenten.

  • Mean Time To Repair (MTTR)

    Durchschnittliche Zeit zur Behebung eines Defects vom Bericht bis zur Verifikation.

  • Escape Rate

    Anteil der Defects, die aus Teststufen in Produktion entkommen sind.

Defect Density pro Modul

Berechnung der Anzahl Fehler pro 1.000 LOC zur Vergleichbarkeit von Komponenten.

Escape Rate für Tests

Anteil der Produktionsfehler, die zuvor nicht durch Testfälle entdeckt wurden.

MTTR für Fehlerbehebung

Durchschnittliche Zeit vom Fehlerbericht bis zur Behebung und Verifikation.

1

Standarddefinitionen für Defects und Severities festlegen.

2

Quellen (Issue-Tracker, Tests, CI) anbinden und Daten normalisieren.

3

Kernmetriken auswählen, Dashboards implementieren und Schwellenwerte definieren.

4

Regelmäßige Reviews und Retrospektiven zur Interpretation etablieren.

⚠️ Technische Schulden & Engpässe

  • Alte Komponenten ohne Tests erschweren aussagekräftige Messungen.
  • Fehlende Automatisierung führt zu manuellen Erfassungsaufwänden.
  • Inkonsistente Ticket-Metadaten verhindern aggregierbare Analysen.
Unzureichende Testabdeckung in kritischen KomponentenManuelle Fehlerklassifikation verzögert ReaktionInkonsequente Definitionen über Teams hinweg
  • Teams reduzieren Berichte, um Defect-Zahlen künstlich zu verbessern.
  • Fokus auf kurzfristige Reduktion statt nachhaltiger Fehlerbeseitigung.
  • Metriken werden isoliert ohne Verknüpfung zu Geschäftszielen genutzt.
  • Vergleich unterschiedlicher Modules ohne Normalisierung führt zu Fehlschlüssen.
  • Ignorieren von Fluktuation durch Releases und Teamgrößenänderungen.
  • Zu viele Kennzahlen parallel ohne Fokus auf die wichtigsten Indikatoren.
Kenntnis von Testmethoden und FehlerklassifikationDatenanalyse und VisualisierungskompetenzVerständnis von Softwarearchitektur und Release-Prozessen
Messbarkeit von Zuverlässigkeit und FehlerdichteNotwendigkeit schneller Feedback-Schleifen im CI/CDSkalierbare Datenerfassung und -aggregation
  • • Datenschutz- und Ticketzugriffsrechte limitieren Datenverfügbarkeit
  • • Legacy-Tools ohne strukturierte Metriken erschweren Aggregation
  • • Unterschiedliche Release-Zyklen beeinträchtigen Vergleichbarkeit