Komplex oder kompliziert, das ist hier die entscheidende Unterscheidung. Komplexe Software ist kein rein technisches Problem: Sie gehört in dieselbe Kategorie wie Medizin, Wetter und Finanzen, in denen sich Ergebnisse nicht im Voraus vorhersagen lassen. Testen heißt in diesem Umfeld herauszufinden, was funktioniert und was nicht, statt alle Fehler vorab zu verhindern. Die praktische Antwort: klein releasen, oft releasen und sich anhand echter Produktionsdaten anpassen.
Das Wichtigste in Kürze
- Software ist kein kompliziertes System wie eine Brücke, sondern ein komplexes: Ergebnisse sind unvorhersehbar und lassen sich erst im Nachhinein beobachten, nicht vorab berechnen.
- Wer Tester für Fehler in der Produktion verantwortlich macht, verkennt komplexe Systeme, denn eine lückenlose Vorhersage vor dem Release ist dort strukturell unmöglich und keine Frage fehlender Kompetenz.
- Testen in einem komplexen Umfeld ist Lernen: Häufige kleine Änderungen erzeugen Wissen darüber, was funktioniert, statt eine vorab bekannte richtige Antwort zu bestätigen.
- Safe-to-Fail-Experimente, Feedbackschleifen und Monitoring-Metriken ersetzen das Ingenieursziel der einen richtigen Lösung durch laufende Anpassung auf Basis echter Produktionsdaten.
Software ist nicht nur Ingenieursarbeit
Code schreiben ist Ingenieursarbeit. Was danach passiert, wenn der Code live ist, oft nicht. Genau hier setzt das Cynefin-Framework an, und es verändert, wie Testen komplexer Systeme funktionieren sollte.
Jean-Francois Riverin begründet das so: Software wird in andere Software integriert. Sie bildet Ökosysteme, die miteinander sprechen. Sobald dein Programm Daten mit anderen Programmen austauscht, und immer öfter auch mit KI, die ihr eigenes Verhalten umschreibt, verlässt du die Welt der vorhersehbaren Technik.
Eine Brücke spricht nicht mit einer anderen Brücke. Brücken interagieren nicht. Software tut es ständig, und genau in dieser Interaktion geht die Vorhersehbarkeit verloren.
Der technische Teil bleibt trotzdem real. Du schreibst weiter Code, du entwirfst weiter Architektur. Aber sobald dein System in einem größeren Geflecht aus beweglichen Teilen lebt, reicht Technik allein nicht mehr, um zu beschreiben, womit du es zu tun hast.
Kompliziert oder komplex: der Unterschied im Cynefin-Framework
Ein kompliziertes Problem hat eine beste Lösung. Ein komplexes Problem hat keine.
Diese Unterscheidung stammt aus dem Cynefin-Framework von Dave Snowden, entstanden um das Jahr 2000. Im komplizierten Bereich führt genug Analyse zur richtigen Lösung. Die Brücke ist das klassische Beispiel: Ein Ingenieur kann die Lasten berechnen und sie für ein Jahrhunderthochwasser auslegen, weil das Verhalten vorhersehbar ist.
Im komplexen Bereich läuft es anders. Medizin, Wetter und Finanzen gehören hierher. Eine Ärztin nutzt alles verfügbare Wissen, um dich zu behandeln, kann dir das Ergebnis aber nicht versprechen. Ein Meteorologe kann das Wetter in fünf Tagen nicht sicher vorhersagen. Wären Finanzen Ingenieurwesen, wären alle reich.
Die meisten Softwareprobleme gehören in den komplexen Bereich, nicht in den komplizierten. Der Fehler liegt darin, sie wie komplizierte zu behandeln: anzunehmen, man könne alle Überraschungen vor dem Release beseitigen, wenn man nur gut genug testet und sorgfältig genug entwirft.
Warum “alles testen” das falsche Ziel ist
Man kann nicht alles testen. Allein dieser Satz zeigt schon, dass das zugrunde liegende Modell nicht stimmt.
Das ISTQB hält selbst fest, dass vollständiges Testen unmöglich ist. Wenn du nicht alles wissen kannst, jagt eine Strategie, die am Ende jeden Fehler finden will, etwas hinterher, das es nicht gibt. Falsch ist das Paradigma, nicht der Aufwand.
Das alte Versprechen geht so: Die Entwicklung baut die Software, übergibt sie an den Test, der Test prüft sie, und nichts Überraschendes landet in Produktion. Geht in Produktion trotzdem etwas kaputt, sind die Tester schuld. “Warum habt ihr das nicht getestet? Warum habt ihr das nicht vorhergesehen?”
In einem komplexen System lautet die ehrliche Antwort: Es war nicht vorhersehbar. Komplexes Verhalten ist per Definition unvorhersehbar. Die richtige Antwort kennst du erst hinterher, wenn das System in der echten Welt gelaufen ist.
Beim Testen geht es ums Lernen, nicht ums Rechthaben
“In der komplexen Welt geht es beim Testen nicht mehr darum, Fehler zu verhindern. Es geht darum herauszufinden, was funktioniert und was nicht. Es geht also ums Lernen, nicht ums Rechthaben.”
(Jean-Francois Riverin)
Das ist der eigentliche Wechsel. Wenn sich das Ziel vom Verhindern zum Lernen verschiebt, ändert sich alles, was danach kommt. Du hörst auf, beweisen zu wollen, dass die Software korrekt ist, und fängst an herauszufinden, wie sie sich tatsächlich verhält.
Riverin hat über zwanzig Jahre genau andersherum gearbeitet. Analytisch veranlagt, ISTQB-zertifiziert, immer auf der Suche nach dem richtigen Testen, stellte er sich bei jedem Produktionsausfall dieselbe Frage: Was habe ich falsch gemacht? Die Antwort war keine Lücke im Können. Es war das falsche Paradigma, angewendet auf die falsche Art von Problem.
Wie Kunden reagieren, weißt du erst, wenn die Software vor ihnen liegt. Du musst ausliefern, um herauszufinden, ob etwas funktioniert. Dieses Wissen hast du nicht im Voraus, sondern erst im Nachhinein.
Testen komplexer Systeme: klein releasen, oft releasen, schnell lernen
Kleine, häufige Releases schlagen ein großes Release, weil sie jedes Deployment zu einem kontrollierten Experiment machen.
Die Logik ist einfach. Ist eine Änderung klein und geht schief, ist der Schaden klein und die Lehre klar. Bündelst du sechs Monate Arbeit in ein Release und das geht schief, hast du ein großes Problem, einen Rollback und kein klares Signal, was eigentlich falsch war.
Genau hier kommen Agilität und DevOps ins Spiel: Sie sind die Arbeitsweisen, die zu einem komplexen Bereich passen. Liefere oft aus, mach Experimente und betrachte das Ergebnis als Information, nicht als Urteil.
Ein sprachlicher Unterschied lohnt sich dabei. Im Engineering geht es um “Fail-Safe”: Man plant Backups ein, damit das System nicht ausfällt. In komplexen Bereichen geht es um “Safe-to-Fail”: Jeder Schritt ist so klein, dass dir ein Fehlschlag etwas beibringt, ohne viel kaputt zu machen.
Was in einem komplexen System wirklich hilft
Fünf Prinzipien tragen den Ansatz für komplexe Bereiche und ersetzen den Reflex, alles vorab lösen zu wollen.
- Anpassen. Plane für das nächste Release, nicht weit voraus. Langfristige Pläne setzen eine Vorhersehbarkeit voraus, die du nicht hast.
- Safe-to-Fail arbeiten. Halte Änderungen klein, damit ein Fehlschlag billig und lehrreich ist.
- Feedbackschleifen bauen. Bring die Reaktionen des echten Systems und echter Nutzer schnell zurück ins Team.
- Die richtigen Metriken wählen. Entscheidungen in einem komplexen System beruhen auf Daten aus der Produktion, nicht auf Annahmen von vor dem Release.
- Überwachen. Durch laufende Beobachtung entdeckst du Verhalten, das du nicht vorhersagen konntest.
Mit Monitoring und den richtigen Metriken entscheidest du auf Basis dessen, was das System tatsächlich tut. Ohne sie fällst du ins Raten zurück und in die alte Gewohnheit, das Unvermeidbare verhindern zu wollen.
Demut als Arbeitsweise
Bleib bescheiden mit deiner Antwort, denn in einem komplexen System erreichst du nie hundert Prozent Gewissheit.
Eine Ärztin wendet fundiertes Wissen an und hält trotzdem für möglich, dass die Diagnose falsch ist. Selbst ein Sprachmodell formuliert seine Sicherheit vorsichtig, statt absolute Genauigkeit zu behaupten. Dieselbe Haltung passt zu Software: Setz die beste Lösung ein, die du gerade hast, und bleib offen dafür, dass sie falsch sein kann.
Das ist keine Ausrede, weniger zu testen, sondern ein Grund, bewusst zu lernen. Du bringst deine Erfahrung ein, du lieferst aus, du beobachtest, was passiert, und du passt dich an. Vom Team zu erwarten, dass es die Antwort schon vor dem Release kennt, verkennt, wie sich komplexe Systeme verhalten.
Wer am komplizierten Paradigma festhält, landet im Chaos
Wer kompliziertes Denken auf eine komplexe Welt anwendet, landet im Dauereinsatz als Feuerwehr.
Das Muster kennst du. Du lieferst an einem Freitag aus, nach bester Entwicklung und bestem Testen. Am Wochenende klingelt das Telefon. Der Support läuft über. Du behebst ein Problem und verursachst ein neues. Nichts davon war vorhersehbar, und jetzt löschst du Brände, die immer wieder aufflammen.
Die Reaktion darauf macht es schlimmer. Teams bekommen Angst vor Releases. “Wartet sechs Monate, es ist zu riskant, das auszuliefern.” Dann kommt das verspätete Release mit einem großen Problem und einem teuren Rollback. Cynefin nennt diesen Absturz den Kollaps in den chaotischen Bereich.
Die Kosten türmen sich sichtbar auf. Die Hälfte des Werts, den ein Team liefern könnte, fließt in Bugfixing, Incident-Verfolgung und Kundenbeschwerden. Das ist der Preis des falschen Paradigmas, nicht der Preis der falschen Leute.
Das Argument für deinen CEO
Leute auszutauschen löst kein Problem, das im Modell steckt und nicht bei den Menschen.
Riverin bringt es auf den Punkt: Wer immer wieder dieselben Lösungen für eine komplizierte Welt anwendet, bekommt immer wieder dasselbe Ergebnis. Dem Tester die Schuld geben, jemand anderen einstellen: Nichts davon ändert das Ergebnis, weil die Ursache strukturell ist. “Software ist unvorhersehbar” stimmt, und diese Wahrheit verlangt eine andere Antwort als noch mehr Vorausplanung.
Die Antwort heißt: gerade so viel planen wie für das nächste Release nötig, klein und oft ausliefern und aus dem lernen, was die Produktion zeigt. Ein Teil des Widerstands kommt vom Management und vom Business, die ein festes Budget und eine verlässliche Prognose erwarten. Das verlangst du von keiner Ärztin. Von Software kannst du es genauso wenig verlangen.
Gib den Teams Raum zum Arbeiten und zum Lernen. Entwickler und Tester finden die bestmögliche Lösung, aber erst im Tun und erst im Nachhinein. Was du dem Unternehmen dafür anbietest, ist konkret: weniger Zeitverlust durch Feuerwehreinsätze und Kundenbeschwerden, mehr Teamkapazität für Wertschöpfung statt Reparatur.
Häufig gestellte Fragen
Warum verhält sich Software weniger vorhersehbar als eine Brücke?
Eine Brücke kommuniziert nicht mit einer anderen Brücke. Software schon: Sie wird in andere Software integriert, bildet Ökosysteme, die Daten austauschen, und interagiert zunehmend mit KI, die ihr eigenes Verhalten neu programmiert. Ein Ingenieur kann Belastungen berechnen und für ein hundertjähriges Hochwasser auslegen. Das Verhalten von Software innerhalb eines größeren Netzwerks aus sich bewegenden Teilen lässt sich erst beobachten, sobald sie in der realen Welt läuft.
Ist Softwareentwicklung eine ingenieurwissenschaftliche Disziplin?
Teilweise. Das Schreiben von Code und das Entwerfen der Architektur bleiben ingenieurwissenschaftliche Arbeit mit vorhersehbaren Regeln. Was passiert, nachdem der Code live gegangen ist, ist das oft nicht. Sobald ein System in einem System von Systemen und echten Nutzern existiert, reicht das Ingenieurwesen allein nicht mehr aus, um das Problem zu beschreiben, und die meisten Software-Fragen verlagern sich in den komplexen Bereich des Cynefin-Frameworks statt in den komplizierten.
Sind Tester schuld, wenn ein Fehlerzustand in die Produktion gelangt?
Nein. Testern die Schuld zu geben, setzt voraus, dass die Fehlerwirkung vorhersehbar war, und in einem komplexen System war das meist nicht der Fall. Eine lückenlose Vorhersage vor der Veröffentlichung ist strukturell unmöglich, kein Mangel an Kompetenz. Den Tester zu ersetzen oder jemand anderen einzustellen, ändert nichts am Ergebnis, denn die Ursache liegt im Modell, das auf das Problem angewendet wird, nicht beim Personal.
Warum verhindern gründlichere Tests vor der Veröffentlichung keine Überraschungen in der Produktion?
Weil das zugrunde liegende Versprechen nicht eingehalten werden kann. Das ISTQB selbst stellt fest, dass ein erschöpfender Test unmöglich ist; daher jagt eine Strategie, die darauf abzielt, jeden Fehler am Ende zu entdecken, etwas nach, das es gar nicht gibt. Man weiß erst, wie Kunden reagieren werden, wenn die Software vor ihnen liegt. Dieses Wissen entsteht erst im Nachhinein.
Was ist der Unterschied zwischen „Fail-Safe“ und „Safe-to-Fail“?
„Fail-Safe“ ist die technische Herangehensweise: Man entwirft Backups und Redundanzen, damit das System nicht ausfällt. „Safe-to-Fail“ ist die Herangehensweise in komplexen Bereichen: Man hält jede Änderung so klein, dass ein Fehlschlag etwas beibringt, ohne großen Schaden anzurichten. Ersteres versucht, Fehlerwirkungen zu beseitigen, letzteres akzeptiert sie als kostengünstige Informationsquelle.
Was kostet es ein Team, Software weiterhin als kompliziertes Problem zu behandeln?
Etwa die Hälfte des Wertes, den ein Team liefern könnte, fließt in die Behebung von Fehlern, die Nachverfolgung von Vorfällen und die Bearbeitung von Kundenbeschwerden. Das Muster sieht so aus: eine Veröffentlichung am Freitag, ein Wochenende voller Supportanrufe und ein Fix, der den nächsten nach sich zieht. Teams bekommen dann Angst vor der Veröffentlichung, verzögern sie um Monate und landen schließlich bei einem großen Problem mit einem kostspieligen Rollback.
Worauf stützt ihr Release-Entscheidungen, wenn sich die Ergebnisse nicht vorhersagen lassen?
Auf Daten aus der Produktion statt auf Annahmen, die vor dem Release getroffen wurden. Das erfordert kontinuierliche Überwachung, Metriken, die so gewählt sind, dass sie aussagekräftig sind, und Feedbackschleifen, die die Reaktionen realer Systeme und echter Nutzer schnell an das Team zurückmelden. Ohne sie verfällt man in Spekulationen und versucht, das Unvermeidbare zu verhindern.
Wie antwortest du Managern, die ein festes Budget und eine vorhersehbare Prognose erwarten?
Indem man darauf hinweist, dass das auch von keinem Arzt verlangt wird. Es wird fundiertes Wissen angewendet, das Ergebnis bleibt offen. Der praktikable Ansatz ist, gerade genug für das nächste Release zu planen, kleine Releases häufig zu veröffentlichen und aus der Produktion zu lernen. Der konkrete Vorteil für das Unternehmen: weniger Kapazität geht durch Feuerwehreinsätze und Beschwerden verloren, mehr fließt in den Mehrwert.
