Komplexe Software ist kein rein technisches Problem: Sie gehört zur gleichen Kategorie wie Medizin, Wetter und Finanzen, wo sich Ergebnisse nicht im Voraus vorhersagen lassen. Beim Testen geht es in diesem Zusammenhang darum, herauszufinden, was funktioniert und was nicht – und nicht darum, alle Fehlhandlungen von vornherein zu verhindern. Die praktische Lösung besteht darin, kleine Updates häufig zu veröffentlichen und sich anhand echter Produktionsdaten anzupassen.
Das Wichtigste in Kürze
- Software ist kein kompliziertes System wie eine Brücke; sie ist ein komplexes System, was bedeutet, dass Ergebnisse unvorhersehbar sind und erst im Nachhinein beobachtbar, nicht aber im Voraus berechnet werden können.
- Tester für Fehlerwirkungen zu verantwortlich machen, zeugt von einem Missverständnis der Natur komplexer Systeme, bei denen eine lückenlose Vorhersage vor der Veröffentlichung strukturell unmöglich ist – es handelt sich nicht um eine Kompetenzlücke.
- Testen in einer komplexen Umgebung ist ein Lernprozess: Das häufige Einbringen kleiner Änderungen schafft Erkenntnisse darüber, was funktioniert, anstatt eine bereits bekannte richtige Antwort zu bestätigen.
- Experimente, bei denen Fehler erlaubt sind, Feedbackschleifen und Metriken ersetzen das technische Ziel, eine einzige richtige Lösung zu finden, durch kontinuierliche Anpassung auf Basis realer Produktionsdaten.
Software ist nicht nur Technik
Code zu schreiben ist Technik. Was passiert, nachdem der Code live gegangen ist, ist es oft nicht.
Jean-Francois Riverin macht eine Unterscheidung, die die Art und Weise, wie das Testen funktionieren sollte, neu definiert. Software wird in andere Software integriert. Sie bildet Ökosysteme, die miteinander kommunizieren. Sobald dein Programm Daten mit anderen Programmen austauscht – und zunehmend auch mit KI, die ihr eigenes Verhalten neu definiert –, verlässt du die Welt der vorhersehbaren Technik.
Eine Brücke kommuniziert nicht mit einer anderen Brücke. Brücken interagieren nicht miteinander. Software tut das jedoch ständig, und genau bei dieser Interaktion bricht die Vorhersehbarkeit zusammen.
Der technische Teil bleibt real. Du schreibst immer noch Code, entwirfst immer noch Architektur. Aber in dem Moment, in dem dein System in einem größeren Netz aus sich bewegenden Teilen existiert, reicht die Technik allein nicht mehr aus, um zu beschreiben, womit du es zu tun hast.
Kompliziert versus komplex: Warum der Unterschied wichtig ist
Ein kompliziertes Problem hat eine beste Lösung. Ein komplexes Problem hat keine.
Diese Unterscheidung stammt aus dem Cynefin-Framework von Dave Snowden, das etwa aus dem Jahr 2000 stammt. Im komplizierten Bereich führt eine ausreichende Analyse zur richtigen Lösung. Eine Brücke ist das klassische Beispiel: Ein Ingenieur kann die Belastungen berechnen und die Konstruktion für ein hundertjähriges Hochwasser auslegen, da das Verhalten vorhersehbar ist.
Im komplexen Bereich funktioniert das anders. Medizin, Wetter und Finanzen gehören hierher. Ein Arzt nutzt alles verfügbare Wissen, um dich zu behandeln, kann aber das Ergebnis nicht versprechen. Ein Meteorologe kann das Wetter fünf Tage im Voraus nicht mit Sicherheit vorhersagen. Wäre Finanzen Ingenieurwesen, wären alle reich.
Die meisten Softwareprobleme gehören in den komplexen Bereich, nicht in den komplizierten. Der Fehler besteht darin, sie als kompliziert zu behandeln: anzunehmen, dass man Überraschungen vor der Veröffentlichung beseitigen kann, wenn man nur gut genug testet und sorgfältig genug entwirft.
Warum „alles testen“ das falsche Ziel ist
Man kann nicht alles testen. Diese Aussage ist bereits ein Hinweis darauf, dass das zugrunde liegende Modell falsch ist.
Das ISTQB selbst stellt fest, dass ein erschöpfender Test unmöglich ist. Wenn man nicht alles wissen kann, dann jagt eine Strategie, die darauf basiert, am Ende jeden Fehlerzustand zu finden, etwas, das es gar nicht gibt. Das Paradigma ist falsch, nicht der Aufwand.
Das alte Versprechen lautet so: Die Entwicklung erstellt die Software, übergibt sie an den Test, der Test überprüft sie, und nichts Unerwartetes gelangt in die Produktion. Wenn die Produktion trotzdem ausfällt, bekommen die Tester die Schuld. „Warum habt ihr das nicht getestet? Warum habt ihr das nicht vorausgesehen?“
In einem komplexen System lautet die ehrliche Antwort, dass es nicht vorhersehbar war. Komplexes Verhalten ist per Definition unvorhersehbar. Die richtige Antwort kennst du erst im Nachhinein, wenn das System in der realen Welt gelaufen ist.
Beim Testen geht es ums Lernen, nicht darum, Recht zu haben
In der komplexen Welt geht es beim Testen nicht mehr darum, Fehlhandlungen zu verhindern. Es geht darum, zu erfahren, was funktioniert und was nicht. Es geht also ums Lernen, nicht darum, Recht zu haben. — Jean-Francois Riverin
Das ist der Wandel. Wenn sich das Ziel von der Vermeidung hin zum Lernen verschiebt, ändert sich alles, was danach kommt. Man hört auf, zu versuchen, die Korrektheit der Software zu beweisen, und fängt an, herauszufinden, wie sie sich tatsächlich verhält.
Riverin hat mehr als zwanzig Jahre lang genau umgekehrt gearbeitet. Von Natur aus analytisch, ISTQB-zertifiziert und darauf bedacht, wie man richtig testet, stellte er sich immer wieder dieselbe Frage, wenn die Produktion ausfiel: Was habe ich falsch gemacht? Die Antwort lag nicht in mangelnden Fähigkeiten. Es war das falsche Paradigma, das auf die falsche Art von Problem angewendet wurde.
Du weißt nicht, wie Kunden reagieren werden, bis die Software vor ihnen liegt. Du musst sie veröffentlichen, um herauszufinden, ob etwas funktioniert. Diese Verfügbarkeit des Wissens ist nicht im Voraus vorhanden, sondern erst im Nachhinein.
Klein veröffentlichen, oft veröffentlichen, schnell lernen
Kleine, häufige Releases sind besser als ein großes Release, weil sie jede Bereitstellung in ein kontrolliertes Experiment verwandeln.
Die Logik dahinter ist einfach: Wenn eine Änderung klein ist und fehlgeschlagen ist, ist der Schaden gering und die Erkenntnis klar. Wenn du sechs Monate Arbeit in einem Release bündelst und dieser fehlgeschlagen ist, hast du ein großes Problem, einen Rollback und kein klares Signal darüber, was schiefgelaufen ist.
Genau hier kommen Agilität und DevOps ins Spiel: Es sind die Methoden, die zu einem komplexen Bereich passen. Stellt oft bereit, führt Experimente durch und betrachtet das Ergebnis als Information statt als Urteil.
Es gibt einen sprachlichen Unterschied, den man klar unterscheiden sollte. Im Engineering geht es um „Fail-Safe“: Man entwirft mit Backups, damit das System nicht ausfällt. Bei komplexen Aufgaben geht es um „Safe-to-Fail“: Man gestaltet jeden Schritt so klein, dass eine Fehlerwirkung dir etwas lehrt, ohne großen Schaden anzurichten.
Was in einem komplexen System tatsächlich hilft
Fünf Prinzipien tragen den Ansatz für komplexe Bereiche und ersetzen den Instinkt, alles im Voraus lösen zu wollen.
- Anpassen. Plane für das nächste Release, nicht weit im Voraus. Langfristige Pläne setzen eine Vorhersehbarkeit voraus, die du nicht hast.
- Fehler sicher machen. Halte Änderungen klein, damit die Fehlerwirkung kostengünstig und lehrreich ist.
- Schaffe Rückkopplungsschleifen. Leite die Reaktionen des realen Systems und der echten Nutzer schnell an das Team weiter.
- Achte auf die richtigen Metriken. Entscheidungen in einem komplexen System basieren auf Daten aus der Produktion, nicht auf Annahmen, die vor dem Release getroffen wurden.
- Überwache. Durch kontinuierliche Beobachtung erkennst du Verhaltensweisen, die du nicht vorhersagen konntest.
Mit Überwachung und den richtigen Metriken triffst du Entscheidungen auf der Grundlage dessen, was das System tatsächlich tut. Ohne sie fällst du in Vermutungen zurück und in die alte Gewohnheit, das Unvermeidbare verhindern zu wollen.
Demut als Arbeitsweise
Sei bescheiden in Bezug auf deine Antwort, denn in einem komplexen System erreichst du niemals hundertprozentige Gewissheit.
Ein Arzt wendet fundiertes Wissen an und räumt dennoch ein, dass die Diagnose falsch sein könnte. Selbst ein Sprachmodell gibt seine Zuversicht nur vorsichtig wieder, anstatt absolute Genauigkeit zu behaupten. Die gleiche Haltung gilt für Software: Wende die beste Lösung an, die dir zu diesem Zeitpunkt zur Verfügung steht, und bleibe offen dafür, dass sie falsch sein könnte.
Das ist keine Ausrede, weniger zu testen. Es ist ein Grund, bewusst zu lernen. Du bringst deine Erfahrung ein, du stellst die Lösung bereit, du beobachtest, was passiert, und du passt dich an. Von dem Team zu erwarten, dass es die Antwort schon vor der Veröffentlichung kennt, verkennt das Verhalten komplexer Systeme.
Wenn du weiterhin das komplizierte Paradigma anwendest, entsteht Chaos
Wenn du kompliziertes Denken auf eine komplexe Welt anwendest, gerätst du in einen permanenten Löschdienst.
Das Muster ist bekannt. Du veröffentlichst an einem Freitag, nachdem du dein Bestes bei der Entwicklung und beim Testen gegeben hast. Über das Wochenende fangen die Anrufe an. Der Support wird überflutet. Du behebst ein Problem und verursachst ein neues. Nichts war vorhersehbar, und jetzt löschst du Brände, die immer wieder aufflammen.
Diese Reaktion macht alles noch schlimmer. Teams bekommen Angst vor Releases. „Wartet sechs Monate, es ist nicht sicher, das Produkt zu veröffentlichen.“ Dann kommt das verspätete Release mit einem großen Problem und einem kostspieligen Rollback auf den Markt. Cynefin nennt diesen Absturz den Einsturz in den chaotischen Bereich.
Die Kosten häufen sich auf offensichtliche Weise an. 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 ist der Preis für das falsche Paradigma, nicht der Preis für die falschen Leute.
Das Argument, das du deinem CEO vorbringen solltest
Das Austauschen von Mitarbeitern wird ein Problem nicht lösen, das im Modell liegt, nicht bei den Mitarbeitern.
Riverin bringt es auf den Punkt: Wenn du immer wieder dieselben Lösungen für eine „komplizierte Welt“ anwendest, bekommst du immer wieder dasselbe Ergebnis. Dem Tester die Schuld zu geben, jemand anderen einzustellen – nichts davon ändert etwas am Ergebnis, denn die Ursache ist struktureller Natur. „Software ist unvorhersehbar“ ist wahr, und diese Wahrheit erfordert eine andere Reaktion als noch mehr Vorausplanung.
Die Antwort lautet: Plane gerade so viel wie nötig für das nächste Release, bring kleine Updates häufig heraus und lerne aus den Erkenntnissen aus der Produktion. Ein Teil des Widerstands kommt von den Managern und dem Unternehmen, die ein festes Budget und eine vorhersehbare Prognose erwarten. Das kannst du von einem Arzt nicht verlangen. Und das kannst du auch von Software nicht verlangen.
Gebt den Teams Raum zum Arbeiten und zum Lernen. Entwickler und Tester werden die bestmögliche Lösung finden, aber erst im Laufe der Arbeit und erst im Nachhinein. Der Kompromiss, den ihr dem Unternehmen anbietet, ist konkret: weniger Zeitverlust durch Feuerwehreinsätze und Kundenbeschwerden, mehr Kapazität des Teams, die in Wertschöpfung statt in Fehlerbehebung fließt.
