Code-Qualität prüfen, ohne selbst Entwickler zu sein: Ein Leitfaden für Auftraggeber

Die meisten Auftraggeber erfahren erst beim Abnahmetest, ob die gelieferte Software wirklich taugt - und damit oft erst dann, wenn ein Nacharbeiten teuer und zeitraubend wird. Dabei lässt sich die Code-Qualität schon während des Projekts einschätzen, auch ohne selbst eine Zeile Code lesen zu können. Es geht nicht darum, den Quelltext zu verstehen, sondern darum, die richtigen Fragen zu stellen und auf die richtigen Signale zu achten. Und zwar lange bevor die finale Abnahme ansteht.

Warum Code-Qualität nicht erst am Ende sichtbar wird

Schlechte Code-Qualität zeigt sich selten sofort. Eine Funktion kann in der Demo einwandfrei laufen und trotzdem auf brüchigem Fundament stehen: schwer wartbar, ohne Tests, voller versteckter Abhängigkeiten. Das Problem ist: Genau diese Mängel werden im fertigen Produkt erst sichtbar, wenn sich etwas ändern soll, ein neuer Entwickler übernimmt oder die Nutzerzahl steigt. Wer als Auftraggeber wartet, bis die Abnahme ansteht, hat dann kaum noch Hebel, um gegenzusteuern. Das Budget ist ausgegeben, der Liefertermin nah. Deshalb lohnt es sich, schon während der Projektlaufzeit ein paar einfache, wiederkehrende Prüfpunkte einzubauen.

Eine laufende Staging-Umgebung einfordern

Der wichtigste Prüfpunkt ist simpel: Verlange eine Staging- oder Testumgebung, die regelmäßig - idealerweise nach jedem größeren Feature - aktualisiert wird, statt nur eine finale Demo am Projektende zu sehen. Ein Entwicklungspartner, der dir jederzeit eine laufende, aktuelle Version zeigen kann, hat in der Regel auch einen sauberen, funktionierenden Entwicklungsprozess dahinter. Wer dagegen ausweicht ("zeigen wir dir am Ende alles zusammen") oder die Umgebung wochenlang nicht aktualisiert, verschleiert damit oft den tatsächlichen Fortschritt - und manchmal auch den tatsächlichen Zustand des Codes.

Achte dabei nicht nur darauf, dass die Umgebung existiert, sondern auch darauf, wie sie sich verhält:

Lässt sie sich mit leicht abweichenden Eingaben zum Absturz bringen, obwohl der "Standardfall" in der Demo funktioniert?
Bleiben Zustände nach einem Fehler konsistent, oder wirkt die Anwendung danach "kaputt"?
Wie schnell reagiert das Team, wenn du in der Staging-Umgebung selbst einen Fehler findest?

Nach automatisierten Tests und Testabdeckung fragen

Du musst keinen Code lesen können, um eine Testabdeckung ("Code Coverage") einzuordnen. Eine seriöse Software-Entwicklung bringt automatisierte Tests mit, die bei jeder Änderung automatisch laufen und prüfen, ob bestehende Funktionen noch korrekt arbeiten. Frag konkret nach:

Gibt es automatisierte Tests, und wie hoch ist die Testabdeckung in Prozent?
Läuft eine Continuous-Integration-Pipeline (CI), die bei jeder Änderung automatisch alle Tests ausführt?
Was passiert, wenn ein Test fehlschlägt - wird trotzdem ausgeliefert, oder stoppt die Pipeline?

Eine Testabdeckung von 0% oder eine Antwort wie "das machen wir manuell" ist kein Beinbruch bei einem Wochenend-Prototyp, aber ein ernstes Warnsignal bei Geschäftssoftware, die mit echten Kunden- oder Zahlungsdaten arbeitet. Du musst die Zahl nicht bewerten können wie ein Entwickler - es reicht, sie regelmäßig einzufordern und ihren Verlauf über die Projektlaufzeit zu beobachten. Eine sinkende Testabdeckung bei wachsendem Funktionsumfang ist ein klares Signal, dass Qualität der Geschwindigkeit geopfert wird.

Ob Code-Reviews wirklich inhaltlich stattfinden

Bei seriösen Entwicklungsteams liest ein zweiter Entwickler jede Änderung gegen, bevor sie in die Hauptversion übernommen wird ("Code Review" oder "Pull Request Review"). In den meisten modernen Code-Repositories lässt sich das sogar technisch erzwingen: Ohne Freigabe einer zweiten Person lässt sich eine Änderung gar nicht erst übernehmen. Genau deshalb ist die naheliegende Frage "wird jede Änderung gegengelesen?" wenig aussagekräftig - in einem technisch sauber aufgesetzten Projekt ist die Antwort ohnehin immer "ja", weil das Tool es erzwingt.

Das eigentliche Risiko liegt woanders und ist in der Softwarebranche als "Rubber Stamping" gut dokumentiert: eine Änderung wird formal freigegeben, ohne dass die zweite Person sie tatsächlich gelesen oder verstanden hat - oft nur mit einem reflexhaften "LGTM" ("looks good to me"). Die Freigabe existiert dann zwar im System, die inhaltliche Kontrolle dahinter aber nicht. Frag dein Entwicklungsteam deshalb nicht, ob Reviews stattfinden, sondern wie inhaltlich sie ablaufen:

Wie sieht ein typisches Review konkret aus - gibt es Kommentare, Rückfragen oder Änderungswünsche, oder wird praktisch jede Änderung ohne ein einziges Wort freigegeben?
Wie viel Zeit vergeht typischerweise zwischen einer umfangreichen Änderung und ihrer Freigabe? Eine Freigabe innerhalb weniger Minuten bei einer größeren Änderung ist ein Hinweis darauf, dass sie kaum gelesen wurde.
Arbeitet an deinem Projekt tatsächlich mehr als eine Person, die sich inhaltlich - nicht nur formal - gegenseitig kontrollieren kann?

Bei einem Ein-Personen-Team ist ein echtes Code-Review naturgemäß unmöglich, unabhängig davon, was das Tool technisch erzwingt. Das ist kein Ausschlusskriterium, sollte dich aber dazu bringen, andere Absicherungen einzufordern - etwa eine externe Zweitmeinung vor der Abnahme oder eine höhere automatisierte Testabdeckung als Ausgleich.

Auf Diskrepanzen zwischen Demo und Realität achten

Ein Warnsignal, das viele Auftraggeber erst zu spät bemerken: Eine Funktion, die in der Demo mit den immer gleichen Testdaten reibungslos läuft, aber bei leicht abweichenden Eingaben - einem leeren Feld, einem Sonderzeichen, zwei gleichzeitigen Nutzern - versagt. Das deutet darauf hin, dass für den Präsentationsfall entwickelt wurde, nicht für den echten Betrieb. Ein einfacher, aber wirkungsvoller Praxistest: Bitte in jeder Demo darum, spontan selbst ein paar unübliche Eingaben auszuprobieren, statt nur zuzusehen. Wie das Team auf unerwartetes Verhalten reagiert - gelassen und nachvollziehbar erklärend oder ausweichend und überrascht - sagt oft mehr über die Code-Qualität aus als die Funktion selbst.

Technische Dokumentation als Liefergegenstand vereinbaren

Code-Qualität, die nur im Kopf der aktuellen Entwickler existiert, ist für dich als Auftraggeber wertlos, sobald das Team wechselt oder das Projekt endet. Verlange deshalb schon im Vertrag eine technische Dokumentation als festen Liefergegenstand - nicht als optionale Kür am Ende. Dazu gehören mindestens eine Beschreibung der Systemarchitektur, eine Übersicht der eingesetzten Technologien und Abhängigkeiten sowie eine Anleitung, wie ein neues Team das Projekt übernehmen könnte. Was passiert, wenn diese Übergabe tatsächlich ansteht und worauf du dabei zusätzlich achten musst, beschreibt der Artikel Software-Übergabe: was passiert, wenn dein Dienstleister geht? im Detail. Eine gute Dokumentation ist damit auch ein indirekter Qualitätsnachweis: Wer sein System nicht verständlich beschreiben kann, hat es oft selbst nicht sauber durchdacht.

Regelmäßige, kurze Statusfragen statt großer Kontrollrunden

Du musst kein wöchentliches Audit veranstalten, um die genannten Punkte im Blick zu behalten. Es reicht, sie in bestehende Jour-fixe-Termine einzubauen - etwa mit drei wiederkehrenden Fragen: Wie sieht die aktuelle Testabdeckung aus? Wie viele der letzten Änderungen wurden mit Kommentaren oder Rückfragen versehen, statt nur ohne Anmerkung durchgewunken zu werden? Läuft die Staging-Umgebung noch mit dem aktuellen Stand? Ein Team mit sauberen Prozessen beantwortet diese Fragen ohne zu zögern. Ausweichende oder vage Antworten über mehrere Termine hinweg sind meist der zuverlässigste Frühindikator, den du als Nicht-Entwickler zur Verfügung hast.

Fazit

Du musst keine Zeile Code lesen können, um die Qualität eines Softwareprojekts einzuschätzen. Eine aktuelle Staging-Umgebung, eine nachvollziehbare Testabdeckung, gelebte Code-Reviews, ehrliche Reaktionen auf spontane Praxistests und eine vertraglich fixierte Dokumentation sind Signale, die du während der gesamten Projektlaufzeit einfordern und beobachten kannst - nicht erst beim finalen Abnahmetest.

Häufig gestellte Fragen

Wie kann ich Code-Qualität beurteilen, wenn ich selbst nicht programmieren kann?

Du bewertest nicht den Code selbst, sondern nachvollziehbare Prozess-Signale: eine regelmäßig aktualisierte Staging-Umgebung, die Testabdeckung in Prozent, ob Code-Reviews stattfinden und wie das Team auf spontane, unübliche Testeingaben reagiert.

Was ist der Unterschied zwischen dieser laufenden Prüfung und der Abnahme am Projektende?

Die Abnahme nach § 640 BGB ist der formelle, rechtlich bindende Schlussakt eines Projekts. Die hier beschriebenen Prüfpunkte sind informelle, laufende Signale während der Projektlaufzeit, mit denen du frühzeitig gegensteuern kannst, statt erst bei der Abnahme von Problemen überrascht zu werden.

Was sagt eine Testabdeckung von 0% über ein Projekt aus?

Bei einem Wochenend-Prototyp ist das unproblematisch. Bei Geschäftssoftware, die mit echten Kunden- oder Zahlungsdaten arbeitet, ist eine fehlende automatisierte Testabdeckung ein ernstes Warnsignal, weil Änderungen dann nicht zuverlässig auf Nebenwirkungen geprüft werden.

Muss ich als Auftraggeber Code-Reviews einfordern, auch wenn ich den Code nicht lesen kann?

Ja, aber nicht in erster Linie ihre bloße Existenz - die erzwingen die meisten Code-Repositories über Merge-Schutzregeln ohnehin technisch. Entscheidend ist die inhaltliche Tiefe: Frag nach, ob Reviews zu Kommentaren und Rückfragen führen oder Änderungen ohne inhaltliche Prüfung durchgewunken werden ("Rubber Stamping", ein in der Branche gut dokumentiertes Risiko). Bei einem Ein-Personen-Team solltest du stattdessen nach alternativen Absicherungen wie einer externen Zweitmeinung fragen.

Warum sollte technische Dokumentation vertraglich vereinbart werden?

Weil sie sonst häufig informell im Kopf der aktuellen Entwickler bleibt und beim Team- oder Dienstleisterwechsel verloren geht. Als fester Liefergegenstand im Vertrag stellt sie sicher, dass die Qualität deines Systems auch nach einem Wechsel extern nachvollziehbar bleibt.