Was wir prüfen, bevor ein echter Betrieb damit arbeitet

DriveFlow ist unser eigenes Produkt, eine Plattform für Schweizer Fahrschulen mit Buchung, Ausbildungskarte, Rechnungen und Schulverwaltung. Wir haben es gebaut, wir betreiben es, und es geht in den Pilotbetrieb.

Davor haben wir es geprüft, als hätte es jemand anders geschrieben und als wären wir gefragt worden, ob man sich darauf verlassen kann.

Bei einem Kundenprojekt ist das normal. Beim eigenen Produkt ist es leicht zu überspringen, und dieses Überspringen ist der Grund, warum die meisten kleinen Teams etwas über ihre Software von den Leuten erfahren, die dafür bezahlen.

Die Regel, die eine Prüfung überhaupt wert macht

Die Versuchung beim eigenen Code ist, die Frage nach der Reife danach zu beantworten, wie man sich damit fühlt. Du weisst, welche Teile solide sind, weil du sie gebaut hast, und dieses Wissen tritt still an die Stelle von Belegen.

Die Prüfung lief deshalb auf einer einzigen Regel. Eine Aussage darüber, ob etwas funktioniert, zählt nur, wenn tatsächlich etwas ausgeführt wurde. Alles, was stattdessen aus der Kenntnis der Codebasis stammt, wird als Rückschluss gekennzeichnet, im Bericht, schriftlich.

Das klingt nach Buchhaltung, bis du es anwendest und merkst, wie viel an einem gewöhnlichen Reifegespräch aus Rückschlüssen besteht, die sich als Tatsachen anziehen. Die Sicherheitsprüfung ist ein gutes Beispiel. Sie war eine statische Lesung: Nichts wurde gegen die produktive Datenbank oder ein Zahlungskonto ausgeführt. Diese Einschränkung steht oben im Dokument, weil ein Leser ohne dieses Wissen jede Aussage darin zu Recht für getestet halten würde.

Die Kennzeichnung kostet einen Absatz. Sie wegzulassen heisst, dass die nächste Person, die den Bericht liest, uns selbst in einem halben Jahr eingeschlossen, eine sorgfältige Einschätzung für eine Messung hält.

Die vier Fragen

Wir stellen sie in der Reihenfolge, die den Betrieb interessiert, und nicht in der, in der der Code aufgebaut ist.

Kann jemand Daten lesen, die ihm nicht gehören. Kann jemand Daten ändern, die ihm nicht gehören. Kommt das Geld dort an, wo es hingehört. Und wenn eines davon schiefgeht, würden wir es merken.

Die ersten drei betreffen das System. Die vierte betrifft uns, und sie ist die, die kleine Teams am schlechtesten beantworten, weil sie die einzige ist, bei der die ehrliche Antwort oft nein lautet.

Was gut herauskam

Die Applikationsschicht hat gehalten. Jede Route authentifiziert, prüft, ob die Anfrage zur richtigen Fahrschule gehört, bevor sie irgendetwas tut, und schreibt erst danach mit erhöhten Rechten. Die Reihenfolge zählt: Eine Prüfung nach dem Schreiben ist keine Prüfung.

Der Umgang mit Geld war in genau den Punkten sorgfältig, die sich schlecht nachrüsten lassen. Der Zahlungs-Webhook beansprucht eine Zahlung genau einmal, damit eine wiederholte Zustellung nicht doppelt belasten kann. Er erstattet automatisch zurück, wenn das Bezahlte nicht zustande kommt. Und er liest nach der Belastung nie einen Preis neu ein, denn das ist die Lücke, durch die ein geänderter Preis stillschweigend eine abgeschlossene Transaktion umschreibt.

Nichts davon war Glück. Es kommt dabei heraus, wenn Billing in der ersten Woche eingebaut wird und nicht dann, wenn es endlich etwas zu verrechnen gibt.

Wo die Arbeit hinging

Die wesentliche Änderung war, die Berechtigungen eine Ebene tiefer zu legen.

Prüfungen, die im Applikationscode leben, sind korrekt, bis jemand eine Route ergänzt und vergisst, sie aufzurufen, und dieser Jemand bist meistens du selbst, achtzehn Monate später, in Eile. Prüfungen an der Datenbankgrenze lassen sich nicht vergessen, weil es keinen Weg an ihnen vorbei gibt. Eine Migration hat eine lange Liste davon in diese Schicht verschoben, wo sie hingehört, und das ist der Grund, warum die entsprechende Liste nicht wieder auftauchen wird.

Das ist ein allgemeines Prinzip und keines von DriveFlow. Wenn die Regel eines Systems darüber, wer was ändern darf, nur in dem Code existiert, der sie heute zufällig aufruft, dann ist diese Regel eine Konvention. Leg sie dorthin, wo die Daten liegen, und sie wird zu einer Bedingung.

Der Befund, mit dem wir nicht gerechnet haben

Das nützlichste Ergebnis der Prüfung betraf nicht das Produkt. Es war, dass unsere Testsuite uns weniger sagte, als wir dachten.

Vierzehn End-to-End-Specs, rund 157 Tests, die Buchung, Onboarding, Einladungen, Inhaberabläufe und Barrierefreiheit abdecken. An der Tiefe lag es nie. Es lag daran, dass sich ein Test ohne verfügbare Zugangsdaten selbst übersprungen hat, und in einer Zusammenfassungszeile sehen ein übersprungener und ein bestandener Test genau gleich aus. Ein grüner Lauf bewies also sehr wenig, still, und das eine ganze Weile lang.

Das ist schlimmer als eine rote Suite. Eine rote Suite sagt dir, dass du hinschauen sollst.

Die allgemeine Fassung davon lohnt sich für jedes Projekt, das lange genug existiert, um Werkzeuge angesammelt zu haben. Die Arbeit bringt das Produkt voran, und nichts im Ablauf bemerkt, wenn die Belegschicht zurückgeht. Niemand entscheidet das. Es passiert, weil der Fortschritt gemessen wird und die Messungen nicht.

Es ist behoben, und zwar strukturell statt durch den Vorsatz, künftig aufmerksamer zu sein: Die Werkzeugkette läuft bei jedem Push und jedem Pull Request und hängt an vier Prüfungen statt daran, ob jemand daran gedacht hat.

Was das für dein Projekt heisst

Wenn du Software in Auftrag gibst, wird dir jeder sagen, dass er testet. Die Frage, die unterscheidet, lautet: Was hat die letzte Prüfung gefunden, und was ist danach passiert.

Ein Team, das nie eine Schlussfolgerung aufgeschrieben hat, die ihm nicht gefiel, hatte entweder ausserordentliches Glück oder hat nicht genau genug hingeschaut, um überhaupt etwas nicht mögen zu können. Wertvoll ist nicht das Urteil. Wertvoll ist die Bereitschaft, es aufzuschreiben, bevor man entscheidet, wie man dazu steht.

Das ist jenseits des Bauens der grössere Teil von Produktentwicklung: zu wissen, was belegt ist, das getrennt zu halten von dem, was bloss geglaubt wird, und einem Kunden sagen zu können, was wovon ist, ohne vorher nachschauen zu müssen. Derselbe Reflex zieht sich durch unsere Entscheidung, wo ein Modell laufen darf, wo die interessante Frage ebenfalls ist, welche Aussagen geprüft und welche angenommen sind.

Wir schreiben wieder, sobald DriveFlow in echten Fahrschulen läuft. Dieser Text wird nützlicher sein als der hier, weil ein Pilot Dinge zeigt, an die keine Prüfung heranreicht.