Codequalität messen: welche Metriken tragen und welche nur beruhigen

Codequalität lässt sich nicht mit einer Zahl ausdrücken. Belastbar wird die Messung erst, wenn Sie vier Dinge nebeneinander betrachten: die Testabdeckung der geänderten Zeilen, den Duplikatanteil, die Änderungshäufigkeit riskanter Dateien und die Zeit bis zur Behebung eines Fehlers. Die internationale Bezugsnorm dafür ist ISO/IEC 25010:2023.

Was ist Codequalität überhaupt?

Codequalität ist kein Eigenschaftswort, sondern ein Modell aus mehreren Merkmalen. Die maßgebliche Norm ist ISO/IEC 25010:2023, Teil der SQuaRE-Familie. Die 2023 überarbeitete Fassung beschreibt neun Produktqualitätsmerkmale.

Neu gegenüber der Vorgängerfassung ist das Merkmal Safety mit Untermerkmalen wie Risikoerkennung, sicherem Zustand im Fehlerfall und Gefahrenwarnung. Außerdem wurden Usability und Portability durch Interaction Capability und Flexibility ersetzt; das frühere „Quality in Use"-Modell steckt seit 2023 in der eigenen Norm ISO/IEC 25019.

Für die tägliche Arbeit ist die Norm zu grob, um direkt zu messen. Sie ist trotzdem nützlich, weil sie eine Diskussion strukturiert: Wenn jemand „bessere Qualität" fordert, klärt der Blick auf die neun Merkmale in zwei Minuten, welches gemeint ist.

Welche Metriken sagen wirklich etwas aus?

Vier, und sie funktionieren nur zusammen. Jede einzelne lässt sich manipulieren, ohne dass die Qualität steigt.

Metrik	Was sie zeigt	Warum allein wertlos
Abdeckung der geänderten Zeilen	ob das Neue geprüft ist	sagt nichts über die Qualität der Zusicherungen
Duplikatanteil	wie oft dieselbe Logik mehrfach existiert	manche Duplikate sind bewusst und richtig
Änderungshäufigkeit × Komplexität	wo Änderungen tatsächlich wehtun	zeigt Symptome, nicht Ursachen
Zeit bis zur Behebung	ob das System beherrschbar ist	lässt sich durch Nichtmelden schönen

Warum ist Testabdeckung allein irreführend?

Weil sie zählt, welche Zeilen ausgeführt wurden, nicht welches Verhalten geprüft wurde. Ein Test, der eine Funktion aufruft und nichts prüft, erzeugt hundert Prozent Abdeckung für diese Funktion und null Erkenntnis.

Bei KI-generierten Tests ist das mehr als ein theoretischer Einwand. Ein Modell, das Tests zu vorhandenem Code schreibt, leitet die erwarteten Werte aus dem Verhalten dieses Codes ab. Enthält der Code einen Fehler, wird der Fehler zur Zusicherung. Der Test ist grün und schützt den Fehler.

Zwei Gegenmittel: Erstens die Abdeckung der geänderten Zeilen messen statt der Gesamtabdeckung — der Gesamtwert verwässert und bewegt sich kaum. Zweitens gelegentlich Mutationstests laufen lassen: Sie verändern den Code absichtlich und prüfen, ob mindestens ein Test das bemerkt. Das ist die einzige verbreitete Methode, die die Qualität der Tests selbst misst. Mehr dazu unter Testabdeckung bei KI-Code.

Wie führe ich Qualitätsmetriken ein, ohne das Team zu demotivieren?

Indem Sie Metriken auf Änderungen anwenden statt auf Personen, und Schwellen für das Neue setzen statt für den Bestand.

• Keine Personenmetriken. Zeilen pro Entwickler, Anzahl Commits, gefundene Fehler je Reviewer — all das erzeugt Verhalten, das die Zahl verbessert und nicht das Produkt.
• Bestand einfrieren, Neues verschärfen. Der Altbestand bleibt, wie er ist; für neue und geänderte Zeilen gilt die Schwelle. So wird jede Änderung eine kleine Verbesserung, ohne dass jemand ein Großreinemachen finanzieren muss.
• Verlauf statt Momentaufnahme. Ein Duplikatanteil von neun Prozent ist ohne Richtung bedeutungslos.
• Wenige Zahlen. Vier Metriken werden gelesen. Zwanzig werden zu einem Bericht, den niemand öffnet.

Welche Metriken sind für KI-gestützte Entwicklung besonders wichtig?

Duplikatanteil und Abhängigkeitszuwachs — beide reagieren direkt auf die typischen Muster generierten Codes.

Für den Duplikatanteil liefert die GitClear-Auswertung die Begründung: Sowohl duplizierte Blöcke als auch kopierter Code haben seit 2022 deutlich zugenommen. Wer nur Testabdeckung misst, sieht diese Bewegung nicht — sie findet zwischen Dateien statt, nicht in ihnen.

Der Abhängigkeitszuwachs ist die zweite blinde Stelle: Ein Werkzeug, das nebenbei Pakete hinzufügt, verändert Ihre Angriffsfläche und Ihre Lizenzsituation, ohne eine einzige Metrik auszulösen, die üblicherweise überwacht wird.

Häufige Fragen zu Qualitätsmetriken

Welche Testabdeckung ist gut?

Eine allgemeingültige Zielzahl gibt es nicht, und jede genannte Prozentzahl ist eine Konvention, keine Norm. Belastbarer ist die Regel: Neuer und geänderter Code sollte nicht unter der bestehenden Abdeckung des Projekts liegen. Damit steigt der Wert von selbst, ohne willkürliche Grenze.

Was ist der Unterschied zwischen ISO 25010 und ISO 25019?

ISO/IEC 25010:2023 beschreibt die Produktqualität, also Eigenschaften der Software selbst. Das frühere „Quality in Use"-Modell — Qualität aus Sicht der Nutzung — ist seit der Überarbeitung 2023 in ISO/IEC 25019 ausgelagert.

Brauche ich dafür ein Werkzeug wie SonarQube?

Nicht zwingend. Duplikatanteil und Komplexität liefern auch freie Analysewerkzeuge, Änderungshäufigkeit liefert Git selbst. Eine Plattform lohnt sich vor allem wegen des Verlaufs und der Schwellenlogik — dafür ist der Begriff Quality Gate geprägt worden, siehe Was ist ein Quality Gate.

Wie oft sollte gemessen werden?

Bei jeder Änderung automatisch, betrachtet einmal im Monat. Häufiger hinsehen erzeugt Rauschen, seltener verpasst Trends.

Gemessen wird schnell, gehandelt selten. Code Guardian schließt diese Lücke, indem das Ergebnis einer Änderung nicht behauptet, sondern belegt wird — mit der Ausgabe der Prüfung, nicht mit der Zusage, dass geprüft wurde.

Quellen

• ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model (neun Merkmale, neu: Safety; Quality in Use ausgelagert nach ISO/IEC 25019).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Stand: 27. Juli 2026. Allgemeine fachliche Einordnung. Normzitate geben den Aufbau wieder und ersetzen nicht den Bezug der Norm.