Verifikation

Hat es außerhalb des Labors funktioniert?

Eine Technologie besteht ihren Piloten. Die Ergebnisse sind gut, der Bericht ist positiv, die Zertifizierung ist vorhanden. Sie wird beschafft und deployt.

Dann trifft sie auf Bedingungen, die niemand getestet hat. Operatoren unter Zeitdruck statt eines engagierten Projektteams. Integration mit Systemen, die nie Teil des Piloten waren. Degradierte Stromversorgung, schlechte Konnektivität, Interferenzen, Kälte, Staub, Last. Ein Gegner, der sich anders verhält als im Testszenario. Innerhalb weniger Monate wird um die Fähigkeit herumgearbeitet, die im Piloten funktioniert hatte.

Die meisten Beteiligten haben ihre Arbeit korrekt gemacht. Der Pilot hat gezeigt, was er zeigen sollte. Das Problem ist, dass man ihn etwas anderes beweisen ließ: dass die Fähigkeit dort funktioniert, wo sie gebraucht wird.

Das ist das Problem, das wir mit Verifikation meinen. Fähigkeiten werden routinemäßig auf Basis von Evidenz deployt, die anderswo, unter anderen Bedingungen und oft von jemandem mit Interesse am Ergebnis gesammelt wurde. Bis eine Fähigkeit gezeigt hat, dass sie dort funktioniert, wo sie gebraucht wird, beruht der Einsatz auf einer Annahme.

Unsere Position ist einfach zu formulieren. Validiert ist nicht deployt. Evidenz ist eine Eigenschaft einer Fähigkeit unter benannten Bedingungen, und sie ist nur so stark wie die Bedingungen, unter denen sie gesammelt wurde.

Ein erfolgreicher Pilot beweist den Piloten

Piloten werden so entworfen, dass sie erfolgreich sein können. Das ist kein Zynismus; so werden sie aufgebaut. Der Scope ist begrenzt, das Team motiviert, der Anbieter eng beteiligt, die Umgebung vorbereitet, und Probleme werden gelöst, wenn sie auftreten.

Das macht einen Piloten zu einem guten Test der Frage, ob etwas funktionieren kann. Es macht ihn zu einem schlechten Test der Frage, ob es funktionieren wird, wenn der Anbieter Abstand nimmt, das ursprüngliche Team weiterzieht und die Fähigkeit im normalen Betrieb funktionieren muss.

Die Lücke dazwischen ist bekannt. In der Innovationspolitik wird sie oft „valley of death“ genannt: der Weg zwischen einem vielversprechenden Ergebnis und einer deployten Fähigkeit, auf dem viele Initiativen enden. Die übliche Reaktion ist mehr Finanzierung für mehr Piloten. Das produziert mehr vielversprechende Ergebnisse und dasselbe Tal.

Was fehlt, ist selten noch ein Pilot. Es ist eine Methode, Evidenz unter den Bedingungen zu sammeln, denen die Fähigkeit tatsächlich begegnen wird.

Verifikation und Validierung sind verschiedene Fragen

Systems Engineering unterscheidet seit Langem zwei Fragen, die leicht vermischt werden.

Verifikation fragt, ob das System richtig gebaut wurde: Tut es, was die Spezifikation sagt? Validierung fragt, ob das richtige System gebaut wurde: Tut es, was Nutzer tatsächlich brauchen, in der Umgebung, in der sie es brauchen? Standards wie IEEE 1012 behandeln beide zu Recht als unterschiedliche Aktivitäten.

Eine Fähigkeit kann Verifikation bestehen und Validierung nicht. Sie erfüllt auf dem Papier jede Anforderung und funktioniert dennoch nicht für die Menschen und Bedingungen, für die sie beschafft wurde, weil die Anforderungen selbst für eine sauberere Welt geschrieben wurden.

Wir verwenden „Verifikation“ in dem weiteren Sinn, in dem Menschen außerhalb des Engineering das Wort verwenden: mit Evidenz feststellen, dass eine Fähigkeit dort funktioniert, wo sie funktionieren soll. Das umfasst beide Fragen. Nur die erste zu beantworten ist, wie Systeme zertifiziert und ungenutzt enden.

Readiness Levels messen Reife, nicht Eignung

Technology Readiness Levels sind eine nützliche gemeinsame Sprache. Sie beschreiben, wie weit eine Technologie gekommen ist, von Grundprinzipien bis zu einem System, das in seiner Betriebsumgebung bewiesen wurde. Europäische Forschungsprogramme verwenden sie, um zu beschreiben, wo ein Projekt beginnt und wo es enden soll.

Sie sind auch leicht zu weit zu lesen. Ein Readiness Level sagt, wie reif eine Technologie entlang eines allgemeinen Pfads ist. Es sagt nicht, ob sie zu den Bedingungen, Systemen und Menschen einer konkreten Institution passt. Ein System, das in „an operational environment“ demonstriert wurde, wurde in einer Betriebsumgebung demonstriert, nicht notwendigerweise in Ihrer.

Deshalb behandeln wir einen Readiness Level als Anfang eines Gesprächs über Evidenz, nicht als Ende. Die nächste Frage ist immer dieselbe: Wo demonstriert, unter welchen Bedingungen, und wie nah liegen diese an unseren?

Die Umgebung ist Teil des Tests

Wo eine Fähigkeit getestet wird, bestimmt, was der Test zeigen kann. Ein Labor kann Leistung unter kontrollierten Bedingungen feststellen. Es kann nicht feststellen, wie sich die Fähigkeit unter den Bedingungen verhält, die echten Betrieb schwierig machen.

Verschiedene Umgebungen legen verschiedene Arten von Fehlern offen. Eine isolierte oder gehärtete Umgebung testet, was passiert, wenn Support, Konnektivität und Supply wegfallen. Eine reale maritime Umgebung testet Wetter, Korrosion, Entfernung und die Schwierigkeit physischen Zugangs. Eine Umgebung, die eine administrative oder nationale Grenze überschreitet, testet, ob Autorität, Verfahren und Übergaben funktionieren, wenn sie gebraucht werden. Ein gewöhnliches Büro oder eine Cloud-Testumgebung testet nichts davon.

Deshalb behandeln wir die Testumgebung als Instrument an sich. Ihre Wahl ist eine Designentscheidung: Sie bestimmt, welche Ausfallbedingungen geübt werden können und damit welche Aussagen das Ergebnis tragen kann.

Jedes Ergebnis hat Bedingungen

Ein Testergebnis, das seine Bedingungen nicht nennt, lädt dazu ein, weiter verallgemeinert zu werden, als gerechtfertigt ist.

Für jedes Verifikationsergebnis wollen wir mindestens wissen: was getestet wurde, in welcher Konfiguration, in welcher Umgebung, von wem, unter welchen Bedingungen, wie lange, was gemessen wurde, was geschah und was bewusst nicht einbezogen wurde. Der letzte Punkt fehlt am häufigsten und ist für den nächsten Käufer am wichtigsten.

Ein enges Ergebnis, das seine Grenzen nennt, ist brauchbar. Man kann sich darauf verlassen, es vergleichen und darauf aufbauen. Eine breite Aussage ohne Bedingungen kann nur geglaubt oder nicht geglaubt werden.

Das ist dieselbe Disziplin, die für Resilienzaussagen gilt. Ein Ergebnis innerhalb einer Envelope beweist nichts außerhalb davon. Siehe Resilienz.

Negative Ergebnisse sind Evidenz

Tests, die scheitern, sagen uns mindestens so viel wie Tests, die bestehen. Sie zeigen, wo die Grenzen einer Fähigkeit tatsächlich liegen, mit welchen Bedingungen sie nicht umgehen kann und welche Annahmen im Design nicht gehalten haben.

Sie sind auch die Ergebnisse, die am ehesten verschwinden. Anbieter haben wenig Anreiz, sie zu veröffentlichen. Käufer wollen vielleicht nicht eingestehen, dass eine Beschaffung scheiterte. Programme werden an Erfolgsgeschichten gemessen.

Wir behandeln dokumentiertes Scheitern als Teil der Evidence Base. Ein Verifikationsdossier mit nur erfolgreichen Tests beschreibt entweder eine Fähigkeit, die nie an ihre Grenzen gedrängt wurde, oder lässt etwas aus.

Der Käufer muss urteilen können

Die meiste Verifikationsevidenz erreicht eine Institution über jemanden mit Interesse am Ergebnis: einen Testbericht des Anbieters, eine vom Vendor erhaltene Zertifizierung, eine Referenz eines anderen Kunden. Nichts davon ist wertlos. Nichts davon ist unabhängig.

Eine Institution, die solche Evidenz nicht kritisch lesen kann, hat keine Möglichkeit, eine starke Aussage von einer gut präsentierten zu unterscheiden. Sie kann nicht fragen, welche Bedingungen getestet wurden, ob sie den eigenen Bedingungen entsprechen oder was ausgelassen wurde. Sie kauft das Label.

Hier hängt Verifikation von Urteilsfähigkeit ab. Der Käufer braucht Menschen, die Evidenz anderer beurteilen und nach der Evidenz fragen können, die die Frage tatsächlich entscheiden würde. Diese Fähigkeit muss innerhalb der Institution bestehen, nicht nur bei ihren Beratern. Siehe Fähigkeitstransfer.

Vom Piloten zur Infrastruktur

Der Endpunkt der Verifikation ist kein Bericht. Es ist eine Fähigkeit, die die Institution selbst unter ihren eigenen Bedingungen betreibt, mit Evidenz, dass sie dort funktioniert.

Viele Initiativen enden beim Piloten, weil die Finanzierung endet. Das Ergebnis ist eine Demonstration, die niemand betreibt. Wir behandeln einen Piloten als einen Schritt in einer längeren Reihenfolge: unter kontrollierten Bedingungen testen, dann unter den Bedingungen, die zählen, dann im Betrieb durch die Menschen, die damit arbeiten werden, mit dokumentierter Evidenz bei jedem Schritt.

Das ist die Operations-Disziplin in Die Reihenfolge: implementiert, unter realen Bedingungen getestet und in etwas verwandelt, das unabhängig und dauerhaft läuft, nachdem die Initiative, die es geschaffen hat, beendet ist.

Wie wir gemeinsam daran arbeiten

Unsere Arbeit an Verifikation beginnt bei den Bedingungen, denen die Fähigkeit begegnen wird, nicht bei der Fähigkeit selbst.

Die Betriebsbedingungen benennen. Vereinbaren, wo und wie die Fähigkeit tatsächlich eingesetzt wird, einschließlich der Bedingungen, für die niemand gern plant.

Die vorhandene Evidenz lesen. Feststellen, was gezeigt wurde, wo, unter welchen Bedingungen und was ausgelassen wurde.

Den Test um die Lücke herum entwerfen. Eine Umgebung und Szenarien wählen, die die Bedingungen ausüben, die bestehende Evidenz nicht abdeckt.

Das Ergebnis mit seinen Bedingungen aufzeichnen. Einschließlich dessen, was scheiterte und was nicht getestet wurde.

Urteilsfähigkeit hinterlassen. Die Institution soll mit Menschen enden, die die nächste Anbieteraussage, den nächsten Testbericht oder die nächste Zertifizierung selbst beurteilen können.

Wenn wir gemeinsam mit einem Partner eine Fähigkeit betrachten, arbeiten wir typischerweise diese Fragen durch:

Wo wir vorsichtig sind

Wir halten uns an einige Verpflichtungen darüber, was wir behaupten.

Wir verallgemeinern ein Ergebnis nicht über die Bedingungen hinaus, unter denen es erzielt wurde.

Wir behandeln einen Readiness Level, eine Zertifizierung oder einen Anbieterbericht nicht als Beweis dafür, dass eine Fähigkeit in einer konkreten Umgebung funktioniert.

Wir präsentieren Testumgebungen nicht als Ergebnisse. Eine Umgebung ermöglicht stärkere Evidenz; sie ist selbst keine Evidenz.

Wir lassen Scheitern nicht aus dem Dossier.

Und wir beschreiben eine Fähigkeit nicht als bewiesen, ohne zu benennen, wo, unter welchen Bedingungen und von wem.

Weiterführende Literatur

• Europäische Kommission, Horizon Europe General Annexes, Definitionen der Technology Readiness Levels.
• IEEE 1012, Standard for System, Software, and Hardware Verification and Validation.

Verwandte Themen: Resilienz · Fähigkeitstransfer · Frühwarnung

Änderungen an dieser Position

• 24. September 2026 — Erstmals veröffentlicht.

Materielle Änderungen werden hier mit Datum aufgeführt. Korrekturen an Formulierungen oder Links nicht.