Was mich das Testen eines Boeing 777 Level D FSTD über sicherheitskritische Systeme gelehrt hat

Beim Testen sicherheitskritischer Systeme geht es nicht um Dashboards, Abdeckungsquoten oder Velocity.
Es geht um Urteilsvermögen, Verantwortung und berufliche Integrität.

Das habe ich auf die harte Tour gelernt, als ich an der Verifikation grosser Flugsimulatoren gearbeitet habe, unter anderem an der Qualifizierung von Boeing 777 Level D Full-Flight-Simulatoren. Das sind keine akademischen Systeme. Mit ihnen werden Piloten für echte Notfälle trainiert. Die Wiedergabetreue muss hoch sein. Die Nachweise müssen glaubwürdig sein. Und wenn du deine Unterschrift unter Testergebnisse und Dokumente setzt, trägt dein Name echte Verantwortung.

Hier sind einige der wichtigsten Lehren, die ich aus dieser Arbeit mitgenommen habe – Lehren, die mich in der Luft- und Raumfahrt, im Verteidigungsbereich und in anderen regulierten Umfeldern begleitet haben.

1. Technische Fähigkeiten sind wichtig, aber menschliche Fähigkeiten zählen mehr, als du denkst

Als ich mit der Arbeit an grossen Simulatorprogrammen anfing, nahm ich an, die grössten Herausforderungen seien technischer Natur. In Wirklichkeit waren viele der schwierigsten Probleme sozialer und organisatorischer Art.

Diese Systeme werden von vielen spezialisierten Teams gebaut: Avionik-Engineers, Softwareentwicklern, Spezialisten für Bewegungssysteme, Experten für Sichtsysteme, Sound-Engineers, Integrationsteams, Technikern und vielen mehr. Probleme lassen sich selten sauber einem einzigen Fachgebiet zuordnen.

Anfangs verhielt ich mich wie viele Tester: Ticket schreiben, Bug dokumentieren, warten. Das funktionierte nicht besonders gut. Viel besser funktionierte es, zu den Leuten an den Arbeitsplatz zu gehen, das Problem persönlich zu besprechen und gemeinsam zu debuggen. Mit der Zeit baute ich Beziehungen in der ganzen Organisation auf. Die Leute sahen in mir nicht mehr "den Testpiloten, der Tickets schreibt", sondern jemanden, der wirklich half, Probleme zu lösen.

Als ich ging, hatte ich Hunderten von Kolleginnen und Kollegen die Hand geschüttelt. Dieses Vertrauen machte alles schneller, reibungsloser und wirksamer.

Was ich daraus gelernt habe:

1. Kommunikation ist Teil des Engineering-Systems.
2. Gute Beziehungen verbessern die Qualität des Systems.

2. Nein sagen gehört zum Job und zur Berufsethik

Eine der schwierigsten Fähigkeiten, die ich entwickeln musste, war zu erkennen, wann ich Nein sagen muss. In regulierten Umfeldern ist der Druck allgegenwärtig:

• "Kannst du alle Tests in drei Tagen durchführen?"
• "Können wir das jetzt freigeben und die Probleme später beheben?"
• "Müssen wir diese Testkampagne wirklich noch einmal durchführen?"

Aber wenn du deinen Namen unter Verifikationsartefakte setzt, die womöglich von Luftfahrtbehörden geprüft werden, hat ein "Ja" Konsequenzen. Ich lernte, anders zu antworten:

• "Nein, das alles kann ich in drei Tagen nicht sicher durchführen. Wir müssen über Trade-offs sprechen."
• "Wir können den Umfang hier reduzieren, wenn wir dieses Risiko formell akzeptieren."
• "Wir brauchen mehr Ressourcen, oder wir passen die Erwartungen an."

Interessanterweise wird das in reifen Luftfahrtumfeldern nicht als Blockade gesehen. Es gilt als Professionalität.

Was ich daraus gelernt habe:

1. Unabhängigkeit in der Verifikation ist nicht nur eine Prozessanforderung.
2. Sie ist eine berufliche und ethische Verantwortung.

3. Gute Manager räumen Hindernisse aus dem Weg, statt sich auf Dashboards zu fixieren

Ich habe Organisationen erlebt, die enorm viel Energie in KPIs, Dashboards, Reifegradmodelle und Reporting-Strukturen stecken. Einiges davon ist nützlich. Aber nach meiner Erfahrung entsteht dadurch keine Qualität. Die besten Manager, mit denen ich gearbeitet habe, konzentrierten sich auf Folgendes:

• Blocker beseitigen
• Prioritäten klären
• Konflikte zwischen Teams lösen
• Zugang zu Rigs und Umgebungen sicherstellen
• Das Team vor Störungen abschirmen

Sie verlangten keine schöneren Diagramme. Sie fragten, was uns ausbremst, und halfen, es zu beheben.

Was ich daraus gelernt habe:

1. In komplexer Verifikationsarbeit zählt der Flow mehr als Metriken.
2. Gute Führung zeigt sich an beseitigten Hindernissen, nicht an produzierten Reports.

4. Wer das Testen früh in Anforderungen und Design einbindet, erspart sich später viel Ärger

Ich habe aufgehört zu zählen, wie oft ich dieses Muster gesehen habe:

• Die Anforderungen wirken für ihren Autor klar
• Die Architektur sieht auf dem Papier elegant aus
• Alles fühlt sich "fertig" an
• Dann beginnt die Verifikation … und die Probleme explodieren

Manche Anforderungen erweisen sich als mehrdeutig, sobald du versuchst, sie zu testen.
Manche Architekturen sind logisch schlüssig, aber praktisch nicht testbar.
Manchen Systemen fehlt die Observability, sodass sich Fehler unmöglich diagnostizieren lassen.

In Projekten, in denen die Verifikation früh dabei war – beim Schreiben der Anforderungen, bei Diskussionen über Schnittstellen, bei Architekturentscheidungen –, gingen die Probleme in den späteren Phasen drastisch zurück.

Was ich daraus gelernt habe:

1. Testbarkeit ist kein Thema des Testens.
2. Sie ist eine Eigenschaft des Designs.

5. Irgendwann habe ich aufgehört, dem Testzeitplan allzu sehr zu vertrauen

Zu Beginn meiner Karriere habe ich viel Energie in detaillierte Testzeitpläne gesteckt. Mit der Zeit bewies mir die Realität immer wieder etwas Unbequemes: Der Zeitplan überlebte fast nie unbeschadet. Der Testplan, also das Dokument, das Tools, Prozesse, Verantwortlichkeiten und die Verifikationsstrategie beschreibt, blieb stabil. Das sollte er auch. Mit dem Zeitplan sah es aber anders aus:

• Der Reifegrad der Hardware änderte sich.
• Die Reihenfolge der Integration änderte sich.
• Tools fielen aus.
• Abhängigkeiten verschoben sich.
• Unerwartetes Verhalten tauchte auf.

Schliesslich änderte ich meinen Ansatz. Statt zu viel in statische Zeitpläne zu investieren, konzentrierte ich mich stärker darauf, die aktuelle Lage laufend neu zu bewerten:

• Was ist gerade das grösste Risiko?
• Was hat sich seit letzter Woche geändert?
• Wo brauchen wir Tiefe, und wo ist oberflächliches Testen vertretbar?

Diese Denkweise führte zu besseren Entscheidungen, als veralteten Plänen blind zu folgen.

Was ich daraus gelernt habe:

1. Disziplin heisst nicht, dem Zeitplan zu folgen.
2. Disziplin heisst, sich laufend an Risiko und Realität anzupassen.

6. Die Ursachenanalyse unterscheidet reife Teams von beschäftigten Teams

Unter Zeitdruck ist es verlockend, sich darauf zu konzentrieren, Symptome zu beheben. In sicherheitskritischen Umfeldern ist das aber eine gefährliche Angewohnheit. Ich habe gelernt, wie wertvoll es ist, Defects präzise zu dokumentieren und sinnvoll zu klassifizieren. Statt "Softwarefehler" hielten wir zum Beispiel fest:

• "Pointer out of bounds in Schleife"
• "Race Condition bei der Bus-Initialisierung"
• "Socket-Timeout unter Last"

Diese Präzision ermöglichte echte Analysen. Muster wurden sichtbar. Ursachen wurden behoben. Wiederholungen nahmen ab.

Was ich daraus gelernt habe:

1. Gute Fehlerdaten sind keine Bürokratie.
2. Sie sind organisationales Lernen.

7. Sicherheitskritische Arbeit verändert dein Denken – dauerhaft

Die Arbeit an Flugzeugsystemen, Simulatoren und in regulierten Umfeldern verändert dich. Du wirst weniger tolerant gegenüber:

• vagen Anforderungen
• ungeprüften Annahmen
• schwacher Dokumentation
• kosmetischer Compliance

Und du achtest stärker auf:

• Traceability
• Nachweise
• Klarheit
• Verantwortung
• langfristige Folgen

Diese Denkweise bleibt. Sie prägt, wie du an jedes komplexe System herangehst, ganz gleich in welchem Fachgebiet.

Was ich daraus gelernt habe:

1. Sicherheitskritische Erfahrung ist nicht nur technische Erfahrung.
2. Sie prägt das berufliche Urteilsvermögen.

Warum diese Lehren immer noch zählen

Tools entwickeln sich weiter. Technologien entwickeln sich weiter. Methoden entwickeln sich weiter. Die grundlegenden Realitäten aber bleiben.

• Komplexe Systeme werden von Menschen gebaut.
• Menschen treffen Annahmen.
• Annahmen müssen hinterfragt werden.
• Nachweise müssen gepflegt werden.
• Verantwortung muss ernst genommen werden.

Ob Luft- und Raumfahrt, Verteidigung, Medizinprodukte oder kritische Infrastruktur: Das zugrunde liegende Muster ist dasselbe. Die Qualität eines Systems spiegelt letztlich die Reife der Menschen wider, die es bauen und verifizieren.

Zum Schluss

Durch die Arbeit an Boeing-777-Simulatoren habe ich das Flugzeug sehr genau kennengelernt. Noch wichtiger aber: Sie hat mir gezeigt, was Verantwortung im Engineering wirklich bedeutet.

Sie steckt nicht in Tools.
Sie steckt nicht in Dashboards.
Sie steckt nicht in Prozess-Frameworks.

Sie steckt darin, wie Engineers:

• kommunizieren
• widersprechen
• entscheiden
• dokumentieren
• zusammenarbeiten
• Verantwortung übernehmen

Genau das schützt am Ende die Menschen, die sich darauf verlassen: Piloten im Cockpit, Operatoren in einem Kontrollraum und alle, die darauf angewiesen sind, dass sicherheitskritische Systeme dann korrekt funktionieren, wenn es am meisten darauf ankommt.