Grün ist ein Signal, kein Abschluss
Der Build läuft durch. Die Plattform meldet „Ready“. Der Healthcheck antwortet mit HTTP 200. Das sind wichtige Signale – aber sie beantworten nur einen Teil der Frage: Kann ein realer Nutzer den versprochenen Ablauf wirklich abschließen?
Zwischen Code und nutzbarem Produkt liegen mehrere Zustände. Wer sie vermischt, erklärt Infrastruktur zu früh zum fertigen Produkt.
- Implementiert: Code und zugehörige Tests existieren.
- Deployed: Der erwartete Stand ist beim richtigen Provider angekommen.
- Konfiguriert: Schlüssel, Rollen, Domains und Providerzustände passen.
- Operational: Ein realer Nutzer kann den Ablauf Ende zu Ende ausführen.
- Auffindbar: Der Einstieg ist über Navigation oder einen klaren Link erreichbar.
- Sichtbar wertvoll: Das Ergebnis löst das angekündigte Problem tatsächlich.
Wo grüne Deployments trotzdem brechen
Eine Scan-API kann implementiert und deployed sein. Wenn der Worker nicht auf die Produktionsdatenbank zugreifen kann, bleibt der Ablauf stehen. Wenn der Scan läuft, das Ergebnis aber nach einem Reload verschwindet, fehlt Persistenz. Wenn alles funktioniert, aber niemand den Einstieg findet, ist das Feature nicht auffindbar.
Keiner dieser Fälle ist mit „der Code ist fertig“ ausreichend beschrieben. Entscheidend ist der Übergang zwischen den Systemen – und ob er unter realen Bedingungen nachweisbar funktioniert.
Der kleinste belastbare Nachweis
Vor einer Beta muss nicht jede denkbare Variante abgedeckt sein. Wichtiger ist ein enger Referenzpfad mit einem echten Nutzer und einem sichtbaren Ergebnis.
Für jeden Übergang braucht es eine überprüfbare Aussage: Wer war autorisiert? Welcher Stand wurde ausgeliefert? Wurde das Ergebnis gespeichert? Ist es nach einem neuen Seitenaufruf noch da? Scheitert derselbe Zugriff für einen fremden Nutzer geschlossen?
Nutzeraktion → API → Verarbeitung → Persistenz → sichtbares Ergebnis nach Reload
Eine bessere Releasefrage
Statt „Ist das Feature fertig?“ hilft eine präzisere Frage: Was kann ein realer Nutzer heute vollständig tun – und welche Evidence belegt jeden Übergang?
Wenn die Antwort nach dem ersten technischen Substantiv abbricht – API, Queue, Datenbank oder Worker –, beschreibst du wahrscheinlich Infrastruktur statt eines abgeschlossenen Ergebnisses.
Illustratives Beispiel
Ein Deployment, sechs unterschiedliche Zustände
Ein fiktiver SaaS-Checkout wurde erfolgreich deployed. Erst der Readiness-Pfad zeigt, wo die Nutzung tatsächlich abbricht.
| Implementiert | Bestätigt | Checkout-Code und 38 automatisierte Tests liegen im Release-Commit. |
|---|---|---|
| Deployed | Bestätigt | Build 1842 läuft auf der vorgesehenen Produktionsdomain. |
| Konfiguriert | Offen | Der Webhook nutzt noch die Testumgebung des Zahlungsproviders. |
| Operational | Fehlgeschlagen | Eine Testbestellung bleibt nach der Zahlung im Status „pending“ stehen. |
| Auffindbar | Bestätigt | Der Checkout ist aus Warenkorb und Produktseite erreichbar. |
| Sichtbar wertvoll | Nicht belegt | Ohne abgeschlossene Bestellung entsteht für den Nutzer kein Ergebnis. |
Keine echte VLDX7-Messung. Alle Werte und Bezeichnungen dienen nur dazu, das Vorgehen nachvollziehbar zu machen.