Code-Qualität messbar machen: Tests, Analyse und Code-Review
Ob Ihr Dienstleister die Code-Qualität sichert, zeigen Belege aus dem Repository: ein grüner Prüflauf vor jedem Merge, ein Testbericht, die Stufe der statischen Analyse und Review-Regeln. Wer so arbeitet, zeigt Ihnen jeden dieser Belege in wenigen Minuten.
Wer Software bezahlt, sieht zuerst die Oberfläche: Funktionen, die laufen, und Rechnungen, die kommen. Ob dahinter Code entsteht, den ein anderes Team in drei Jahren noch ändern kann, zeigt sich erst bei der ersten größeren Erweiterung oder beim Wechsel des Dienstleisters. Dann ist es teuer, das nachzuholen.
Qualität lässt sich vorher prüfen, ohne eine Zeile Code zu lesen. Automatisierte Tests, statische Analyse und Code-Review hinterlassen Spuren im Repository, in der Prüfpipeline und in den Einstellungen der Versionsverwaltung. Diese Spuren können Sie anfordern. Wie man die Prüfpipeline technisch einrichtet, steht unter GitHub Actions CI für Laravel + Statamic. Die Belege unten sind die, die ein Auftraggeber ohne eigene Entwickler anfordern und lesen kann.
Erste Spur
Automatisierte Tests
Ein automatisierter Test ist ein kleines Programm, das prüft, ob ein Teil der Software das Erwartete tut, etwa ob eine Rechnung mit drei Positionen die richtige Summe ergibt. Tests laufen bei jeder Änderung von selbst. Bricht eine Änderung eine bestehende Funktion, schlägt der Test fehl, bevor der Fehler beim Nutzer ankommt.
Für Sie zählen zwei Fragen: Laufen die Tests bei jeder Änderung automatisch, und decken sie die Abläufe ab, mit denen Ihr Unternehmen Geld verdient oder Pflichten erfüllt? Ein Testbericht beantwortet beides. In Laravel erzeugt php artisan test --coverage eine Übersicht, welcher Anteil des Codes beim Testlauf ausgeführt wurde; mit --min=80 schlägt der Lauf fehl, wenn die Testabdeckung unter 80 Prozent fällt. Die Messung braucht laut Laravel-Dokumentation die PHP-Erweiterung Xdebug oder PCOV.
Eine hohe Prozentzahl allein sagt wenig, denn ein Test kann Code ausführen, ohne ein Ergebnis zu prüfen. Fragen Sie deshalb nach den drei Abläufen, die Ihnen am wichtigsten sind, und lassen Sie sich die Tests dafür zeigen. Wer Tests für eine Bestandsanwendung erst nachrüsten muss, findet den Weg unter Legacy-Code ohne Tests.
Zweite Spur
Statische Analyse und Codestil
Statische Analyse liest den Code, ohne ihn auszuführen, und findet Fehler, die erst zur Laufzeit auffallen würden: Aufrufe auf Werte, die leer sein können, falsche Typen, Code, der nie erreicht wird. Ein Werkzeug dafür ist PHPStan. Es kennt die Stufen 0 bis 10; jede Stufe schließt die Prüfungen der vorherigen ein. Stufe 5 prüft die Typen übergebener Argumente, Stufe 8 meldet Methodenaufrufe und Eigenschaftszugriffe auf Werte, die null sein können, Stufe 10 behandelt auch fehlende Typangaben streng.
Wie viel die Stufe ausmacht, zeigt ein kleiner Versuch mit PHPStan 2.3.1, erschienen am 08.10.2026. Eine Methode sucht einen Kunden und gibt null zurück, wenn es ihn nicht gibt; eine zweite Methode liest danach ohne Prüfung die E-Mail-Adresse. Auf Stufe 5 meldet PHPStan keinen Fehler. Auf Stufe 8 kommt die Meldung „Cannot access property $email on App\Customer|null.“ mit Exit-Code 1, und die Prüfpipeline stoppt. Im Betrieb wäre dieselbe Stelle bei der ersten unbekannten Kundennummer mit einem Fehler abgebrochen.
Die Stufe steht in der Datei im Repository; die Baseline listet die Altlasten, die bewusst noch offen sind.
includes:
- phpstan-baseline.neon
parameters:
level: 8
paths:
- app
reportUnmatchedIgnoredErrors: true
Was die Baseline über ein Projekt verrät
Wer ein Bestandsprojekt auf eine höhere Stufe hebt, bekommt alle alten Meldungen auf einmal. PHPStan bietet dafür die Baseline: Der Befehl vendor/bin/phpstan analyse --generate-baseline schreibt alle aktuellen Meldungen mit ihrer Anzahl je Datei in die Datei phpstan-baseline.neon, und spätere Läufe ignorieren genau diese. Neuer Code wird damit streng geprüft, alte Fehler warten. Im Versuch blieb die Baseline wirksam, bis eine zweite Methode in derselben Datei denselben Fehler einbaute: Dann meldete PHPStan beide Stellen, weil die Anzahl nicht mehr stimmte.
Für Sie heißt das: Fragen Sie nach der Stufe und nach der Größe der Baseline, und ob sie über die Monate kleiner wird. Die PHPStan-Dokumentation nennt es das Lebensziel einer Baseline, nicht zu existieren. Eine Baseline, die mit jedem Release wächst, zeigt, dass Fehler dort abgelegt statt behoben werden.
Der Codestil ist der kleinere Teil der Arbeit. PSR-12 ist der Formatierungsstandard der PHP-FIG; in Laravel-Projekten setzt das Werkzeug Pint einen festen Stil automatisch durch, ohne Einstellung das Laravel-Profil, auf Wunsch das Profil psr12. Formatierung ändert kein Verhalten, sie macht aber Reviews kürzer, weil niemand mehr über Leerzeichen spricht.
Dritte Spur
Code-Review als feste Regel
Beim Code-Review liest eine zweite Person eine Änderung, bevor sie in den Hauptzweig kommt. Ob das Regel ist oder Absicht, steht in den Einstellungen des Repositorys. Auf GitHub heißen sie Branch-Schutzregeln: „Require a pull request before merging“ verlangt einen freigegebenen Pull Request, „Require status checks to pass before merging“ verlangt grüne Prüfläufe. Mit der Option zum Verwerfen veralteter Freigaben muss neu freigegeben werden, sobald nach der Freigabe noch Code dazukommt.
Ein Praxisdetail aus der GitHub-Dokumentation: Ohne weitere Einstellung gelten diese Regeln nicht für Personen mit Administratorrechten am Repository. Erst „Do not allow bypassing the above settings“ bindet auch sie. Lassen Sie sich deshalb einen Screenshot der Regel zeigen, auf dem diese Option zu sehen ist.
Bei uns ist der Ablauf auf der Seite Standards beschrieben: Statische Analyse läuft in jeder Pipeline, und Pull Requests ohne grünen Check werden nicht gemergt, auch nicht in Bestandsprojekten. Am Ende einer Liefer-Phase sieht das Ergebnis so aus wie beim FinTech-Backend für eine Versicherungs-App: Dort haben wir Code mit Test-Abdeckung in den kritischen Pfaden übergeben, dazu Architecture Decision Records für die größeren Abzweigungen und kurze Übergabe-Notizen pro Modul.
Fragen, die Sie Ihrem Dienstleister stellen können
Jede Frage lässt sich mit einem Bildschirmfoto, einem Link oder einer Datei aus dem Repository beantworten. Antworten ohne Beleg sind Absichtserklärungen.
Achten Sie bei der vorletzten Zeile auf den Verlauf: Eine Prüfung, die im Frühjahr eingeschaltet und im Sommer still entfernt wurde, sieht man in der Versionsgeschichte der Konfigurationsdatei.
| Was eine gute Antwort zeigt | Beleg, den Sie anfordern | |
|---|---|---|
| Laufen Tests bei jeder Änderung automatisch? | Jeder Pull Request startet einen Testlauf, rote Läufe blockieren das Zusammenführen | Link auf den letzten Lauf in der Prüfpipeline, etwa GitHub Actions |
| Welche Abläufe sind durch Tests abgesichert? | Die geschäftskritischen Abläufe sind benannt und haben eigene Tests | Testbericht mit Abdeckung, dazu die Testdateien zu drei Abläufen Ihrer Wahl |
| Welche Stufe hat die statische Analyse? | Eine feste Stufe in der Konfiguration, für neuen Code hoch | Datei phpstan.neon aus dem Repository |
| Wie groß ist die Baseline, und wie entwickelt sie sich? | Die Zahl der ignorierten Meldungen ist bekannt und sinkt | phpstan-baseline.neon in zwei Ständen, etwa vom Quartalsanfang und vom Quartalsende |
| Wer prüft eine Änderung, bevor sie live geht? | Eine Regel im Repository, die Freigaben verlangt, auch für Administratoren | Screenshot der Branch-Schutzregel mit allen Optionen |
| Welcher Codestil gilt? | Ein benannter Standard, automatisch geprüft | Konfiguration des Formatierers, etwa pint.json, und der Prüfschritt in der Pipeline |
| Was passiert, wenn ein Prüflauf kurz vor einem Termin rot ist? | Der Fehler wird behoben, nicht die Prüfung abgeschaltet | Verlauf der Pipeline-Konfiguration ohne nachträglich deaktivierte Schritte |
| Bekomme ich Zugriff auf das Repository? | Lesezugriff ist jederzeit möglich, das Repository liegt idealerweise bei Ihnen | Einladung in das Repository |
Für Auftraggeber
Häufige Fragen
-
Testabdeckung ist der Anteil des Codes, der beim Durchlauf aller automatisierten Tests ausgeführt wird, angegeben in Prozent der Zeilen oder Verzweigungen. Sie zeigt Lücken, sagt aber nicht, ob die Tests das Ergebnis prüfen. 80 Prozent Abdeckung mit Tests der wichtigen Abläufe können mehr wert sein als 95 Prozent, die vor allem kleine Hilfsfunktionen treffen.
-
Den Code selbst bewerten Sie ohne Fachwissen kaum, die Prozesse dahinter schon. Ob Tests laufen, welche Analyse-Stufe gilt und ob Änderungen ohne Freigabe in den Hauptzweig kommen, zeigen Einstellungen und Berichte, die jeder lesen kann. Für das Urteil über den Code selbst brauchen Sie eine Person mit Entwicklungserfahrung, die nicht am Projekt beteiligt ist.
Belege statt Versprechen
Auf unserer Standards-Seite steht, welche Prüfungen in unseren Pipelines laufen und welche Zertifikate wir bewusst nicht behaupten. Legen Sie die Fragen aus der Tabelle daneben und fordern Sie die Belege an.
Nachweise
Quellen und Stand
Stand: 14.10.2026. Den PHPStan-Versuch haben wir mit PHPStan 2.3.1 unter PHP 8.4 auf macOS an einer Beispielklasse mit einem ungeprüften Null-Wert ausgeführt, auf Stufe 5 und Stufe 8, mit erzeugter Baseline und mit einem zweiten gleichartigen Fehler in derselben Datei.
Artikel teilen