Wenn Computer und Steuerungssysteme zum Beispiel in einer Chemiefabrik etwas anderes machen, als sie sollen, dann sind sie nicht mehr beherrschbar. Und je größer und komplexer solche Computersysteme sind, um so weniger transparent und überschaubar sind sie. So kann heutzutage beispielsweise kein Softwareentwickler mehr bei der Steuerung für einen Autopiloten im Flugzeug das gesamte Programmsystem überblicken.

Der Doyen der Fehleranalyse, der emeritierte Münchner Informatik-Professor Heinz Gerd Hegering, erläutert das so:

"In der Tat ist es so, dass wir Systeme bauen können, wo noch nicht alle Fragestellungen geklärt sind. Das ist wahr. Das Zweite ist, dass wir uns zunehmend damit beschäftigen müssen, dass wir Teile des Managements solcher Systeme automatisieren. Das bedeutet aber, dass die dahinter liegenden Prozesse gut verstanden werden, sodass wir dann Ausschnitte nehmen können, die wir dann durch die Maschine selbst wieder automatisieren lassen können."

Es ist also nicht damit getan, Algorithmen zu schreiben, die in umfangreichen Programmen nach Fehlern suchen. Informationstechnische Systeme bleiben nur dann beherrschbar, wenn Entwickler auch aus Fehlern lernen können. Doch damit das klappt, müssen einige Voraussetzungen erfüllt sein. Eine Kultur der Fehlertoleranz gehört unbedingt dazu. Doch die etabliert sich nur mühsam. Viele – insbesondere staatliche – Großprojekte demonstrieren das.

Das Dokumentenmanagement Maris für Asylverfahren, das Mautsystem Toll Collect oder die elektronische Gesundheitskarte sind da nur drei Beispiele. Auf Druck der Politik - und weil Verwaltungsfachleute die Technik nicht verstehen – werden Projekte nicht zu Ende gedacht. Die Zeitvorgaben sind zu kurz, systematische Tests unterbleiben. So programmierte Anwendungssoftware arbeitet meist nicht korrekt. Der österreichische Computerwissenschaftler Professor Heinrich Mayr kennt eine wesentliche Ursache dafür:

"Ich glaube, hier liegt das Problem, dass solche Situationen nicht vorhergesehen wurden und daher, das ist ja bekannt, eigentlich der Fehler bereits in der Anforderungsanalyse lag, also im Requirements Engineering, dass hier nicht ganz genau alle möglichen Situationen ermittelt und durchgespielt worden sind."

Und das führt dann zu systematischen Fehlern in der Softwarestruktur. Nicht weniger relevant sind die unvermeidlichen Fehler, die Programmierern nun einmal unterlaufen, weil auch sie nur Menschen sind. Pro 1.000 Programmzeilen, also den Regieanweisungen für den Computer, finden sich in der Regel 30 bis 40 Fehler. Da wird auf eine falsche Speicheradresse verwiesen oder auf eine falsche Stelle im Programmcode gesprungen.

Mitunter wird auch ein Programmbefehl einfach einmal vergessen beim Programmieren. Diese Fehler müssen aufgespürt und beseitigt werden. Denn diese Fehler können die organisierte Kriminalität oder auch Geheimdienste später für Spähattacken und Hackerangriffe nutzen – wenn sie bekannt sind. Zumindest in einem kleineren Kreis von Experten müssen sie veröffentlicht werden. Doch sie werden geheim gehalten.

Denn Schwachstellenhändler können nur so lange mit diesen Programmierfehlern ein gutes Geschäft machen, solange sie nicht öffentlich bekannt sind. Lukas Grunwald, Cheftechniker beim Netzexperten Greenbone Networks aus Osnabrück, fordert deshalb nachdrücklich, Programmierfehler und Schwachstellen in Programmen zu veröffentlichen. Das begründet er so:

"Da gibt es die Forderung, selbst von US-Stellen, dass man das komplette Schwachstellen-Business eigentlich austrocknen müsste, indem man so viel wie möglich Schwachstellen von staatlicher Seite aufkauft und dann diese entsprechenden Schwachstellen als freie Information unter einer Open-Source-Lizenz oder unter einer freien Lizenz der Community und der Welt zur Verfügung stellt."

Und auch das reicht immer noch nicht aus, um wirklich fehlertolerante System entwickeln zu können. Statt die bereits eingesetzten Anwendungssysteme kontinuierlich und systematisch zu testen, warten nicht wenige Softwarehäuser einfach ab. Sie warten darauf, dass sich solche Programmierfehler nach und nach im Einsatz bemerkbar machen, ohne großen Schaden anzurichten.

Aber 16 Prozent eines Anwendungssystems ändern sich im Laufe eines Jahres. Bei 100.000 Programmzeilen müssen also pro Jahr 16.000 Programmzeilen angepasst werden. Und die in Verwaltung und Industrie eingesetzten Softwaresysteme bestehen im Schnitt aus vielen hundert Millionen Programmzeilen. Das ergibt einen Anpassungsbedarf in zweistelliger Millionenhöhe. Und jeder Anpassungstag zieht in der Regel zwei Testtage nach sich. Rechnet man diese Zahlen hoch, dann fehlen allein in Deutschland rund 40.000 Softwaretester.