Living Documentation (auch: lebende Dokumentation)

Von nanologika | 29. Januar 2026 |

Kurzdefinition

Living Documentation ist Dokumentation, die aus automatisierten Tests/„executable specifications“ erzeugt wird und dadurch per Definition aktuell bleibt, weil sie mit jedem Testlauf (z. B. in CI/CD) neu generiert bzw. synchronisiert wird.

Was bedeutet „lebend“ konkret?

Automatisch aktuell: Die Inhalte werden aus der automatisierten Test-Suite abgeleitet; damit spiegelt die Doku stets den tatsächlichen Systemstand wider.
Gemeinsame Verständigungsgrundlage: Sie dient als gemeinsame Basis für Business- und Tech-Teams, weil Features/Szenarien (z. B. in Gherkin) gleichzeitig lesbar und ausführbar sind.
Single Source of Truth: Gut gepflegte Feature-/Szenario-Sammlungen werden oft zur maßgeblichen Quelle, was das System „wirklich“ tut – statt dass Anforderungen, Tests und Code auseinanderdriften.

Typische Bausteine

Gherkin Feature Files (BDD): Features & Szenarien in natürlicher Sprache (Given–When–Then), die als Akzeptanzkriterien dienen und automatisiert werden können.
Test-Reports als Doku: Tools wie Serenity BDD erzeugen aus Tests lesbare Berichte („Requirements“-Sicht) – die Living Documentation ist damit mehr als nur ein Testreport.
CI/CD-Anbindung: Living Docs werden oft aus CI-Testläufen generiert, sodass jede Pipeline automatisch die aktuelle Doku produziert.

Beispiel (Konfigurator / Angebotsprozess)

Idee: BDD-Szenarien beschreiben das erwartete Verhalten (z. B. regelkonforme Konfiguration → Angebot). Aus den erfolgreichen Testläufen wird automatisch die Living Documentation erzeugt.

Feature: Angebotskonfigurator – regelbasierte Konfiguration

  Scenario: Gültige Konfiguration erzeugt ein Angebot
    Given der Nutzer konfiguriert ein Produkt mit Optionen
    When alle Optionen gemäß Regelwerk kombinierbar sind
    Then wird ein gültiges Angebot erzeugt
    And der Gesamtpreis ist berechnet
    And die Konfiguration wird als "fertig" markiert

Warum ist das „living“?
Wenn dieses Szenario automatisiert ist und regelmäßig läuft, ist ein „grüner“ Lauf ein Beleg, dass die beschriebene Funktionalität aktuell stimmt; Änderungen, die das Verhalten brechen, werden sofort sichtbar.

Beispiel (Camunda‑Prozess – Freigabe/Workflow)

Prozesse in BPMN werden „wie Code“ behandelt; auch hier kann Living Documentation entstehen, indem Prozesspfade (Happy Path, Eskalation, Fehlerpfad) automatisiert getestet und dokumentiert werden.

Feature: Camunda-Freigabeprozess

  Scenario: Freigabe innerhalb SLA
    Given ein Vorgang wurde gestartet
    When die User Task "Freigeben" abgeschlossen wird
    Then endet der Prozess mit Status "APPROVED"

  Scenario: Eskalation nach Fristablauf
    Given ein Vorgang wartet auf "Freigeben"
    When die Bearbeitungsfrist (Timer) abläuft
    Then wird der Eskalationspfad ausgeführt

Vorteile

Vertrauen & Nachvollziehbarkeit: Dokumentation ist belastbarer, weil sie aus laufenden, prüfbaren Spezifikationen entsteht.
Bessere Zusammenarbeit: Gemeinsame Sprache zwischen Fachlichkeit & Technik; Features/Szenarien sind „gemeinsames Artefakt“.
Weniger „Dokumentations-Verfall“: Automatisches Synchronisieren aus Testläufen reduziert das Risiko veralteter Wiki-Seiten.

Typische Stolperfallen

Szenarien werden zu technisch: Wenn Gherkin eher UI-Klickpfade als fachliches Verhalten beschreibt, sinkt der Nutzen als Doku.
Fehlende CI-Disziplin: Wenn Tests selten laufen oder Reports nicht veröffentlicht werden, „lebt“ die Doku nicht wirklich.

Best Practices

Domänensprache nutzen (Begriffe aus dem Fachbereich), nicht Implementierungsdetails.
Automatisierte Generierung aus Testläufen (idealerweise CI) als Standard.
Szenarien schlank halten: Ein Szenario = ein Verhalten, klare erwartete Ergebnisse.