bla bla bla

Der Sinn einer Prüfung

TÜV kennt jeder. Die Hauptuntersuchung des Autos ist ein wichtiger Beitrag zur Verkehrssicherheit.

Dennoch können Unfälle passieren und das auch auf Grund von Defekten. Ist doch klar: weil zwischen den Prüfung alles mögliche kaputt gehen kann. In zwei Jahren kann viel passieren. Aber eben auch, weil eine Prüfung eines komplexen Gegenstandes nicht allumfassend und schon gar nicht fehlerfrei sein kann. Dass Defekte übersehen werden, hat sicher jeder, der damit zu tun hat und bspw. schon mit einem älteren Auto beim TÜV war, das er in-und-auswendig kennt, schon erlebt.

Was aber, wenn schon das Konzept einer Prüfung die wichtigsten Teile sowieso schon außen vor lässt?

Dann sind wir in der IT.

Wie gefällt dir Vorstellung, dass bei einer Hauptuntersuchung, also der Prüfung des Autos, das Fahrwerk als grundsolide Basis vorausgesetzt wird, aber Türgriffe ausgiebig kontrolliert werden? Der Hauptsinn eines Autos ist doch der Transport von Menschen, oder nicht? Diese müssen einsteigen und sitzen. Daher ist es doch logisch, dass insbesondere Türen und Sitze kontrolliert werden müssen, oder nicht? Die Gefahr, nicht einsteigen oder aussteigen zu können, ist omnipräsent und primäre Prüfaufgabe. So ähnlich sieht die Prüfung eines Produktes im Bereich IT aus.

Die Prüfung eines IT-Produktes beliebiger Funktion bedeutet gerne mal primär, sich die Generierung von Audit Logs anzusehen, Authentifikation des Administrators, vielleicht auch nebenbei ein wenig das Management der Attribute, also insbesondere bspw. dass Regeln, die man einträgt, auch erscheinen. Vielleicht auch noch, dass die Krypto auf der Managementschnittstelle in Ordnung ist. Die Managementschnittstelle, wichtig. Krypto, besonders wichtig!

Die Kernfunktion des Produktes und die Basis, auf der das alles läuft? Na, die wird schon funktionieren.

Die Prüfung selber erfolgt dabei primär auf Dokumentenbasis. Entwicklerdokumentation. Vielleicht mal Quelltexte im Verwaltungssystem des Entwicklers, so wie dieser sie vorführt. Nicht am Stückgut selber, also bspw. durch Reverse Engineering des Inhaltes eines konkreten, unabhängig im Einzelhandel erlangten Exemplars.

Getestet wird auch viel. Aber Testen der eigentlichen Kernfunktion des Produktes? Die Betriebssystembasis? Oder gar einzelne Komponenten der dieses ausführenden Hardware? Nicht mehr als einzelne Punkte hieraus. Üblicherweise werden Kernkomponenten als funktionsfähige Basis gar vorausgesetzt, ohne diese im Einzelnen überhaupt zu betrachten. Indirekt wird dabei definiert, dass wenn man anschließend die als wichtig ausgemachten Funktion testet und die dafür genutzten Komponenten festzurrt, so dass diese damit auch mit getestet wurden und somit das gesamte Produkt getestet wurde. Per Definition.

So als würde das Auto bei besagtem obigen Test, beim Betrachten von Türen und Sitzen, insgesamt abgenommen. Es fährt ja offensichtlich gut, wenn bei der Prüfung von Türen und Sitzen nichts weiter festgestellt wurde und man die mitgetesteten Fahrwerkskomponenten nur gut genug festgelegt hat. Eben die, die bei der Prüfung zugegen waren.

Aber bitte nicht nur die, die konkret getestet wurden, sondern deren Baumuster. Also alles der Art!

So als ob der TÜV nach einer Prüfung das Siegel an alle Autos klebt, die durch die Gegend fahren, wenn der Hersteller mit seinem Baumuster bei der Prüfung war.

Und das Siegel ist auch nicht 2 Jahre gültig, sondern eher 5 oder gar noch mehr. Bei agil entwickelter Software, die heute gerne mal im Wochenrhythmus Änderungen erfährt! Sacht ma, tickts bei euch noch ganz richtig?

Wie systemimmanent das in der IT ist, ist mir erst kürzlich bei einem Streitgespräch mit einer entscheidenden Person in der deutschen Behördenlandschaft wirklich deutlich geworden. Angesprochen wurde ich aufgrund einer flappsigen Nebenaussage von mir zu einem Detail, das an der Stelle mein Gegenüber interessiert hat. Einem Detail, das mir selber nicht die größte Rolle gespielt hat. Kernaussage war eine ganz andere. Aber das interessiert nicht: Das Detail war zu klären. Ich lag – zugegeben – bei diesem Detail daneben. Das war’s. Thema geklärt. Dass eine ganz andere Kernaussage die viel wichtigere ist und dort klaffende Probleme bestehen? Uninteressant. Das Gespräch war in dem Moment zu Ende. Fertig. Rum. Das an der Stelle interessante Detail ja schließlich geklärt und ich im Unrecht.

So wie ein Motorradfahrer, der ohne Helm und Schutzkleidung mit 200 Sachen über die Autobahn brettert und angehalten wird: wegen des fehlenden Helmes. Helm wurde übersehen. Es stellt sich heraus, der ist ja doch da. Blick in die Normen: Alles bestens. Sorry. Fehler. Gute Weiterfahrt. Eine Diskussion darüber, dass weitere Schutzkleidung wie ein Motorradkombi an der Stelle nicht vielleicht doch sinnvoll wäre, muss nicht geführt werden. Das steht nicht in der Norm und ist auch nicht Teil der Prüfung.

Ein Glück ist dieses physische Ding zu offensichtlich, den meisten fass- und ohne ausgiebige Detailerklärung verständlich und Motorradfahrer tragen freiwillig – und das, wie ich finde, erstaunlich oft und selbst bei dazu eigentlich völlig ungeeignetem Wetter – sinnvolle Schutzkleidung. Das ist halt sichtbar, greifbar und wird daher von vielen instinktiv richtig gemacht.

Nicht in der IT. Das Thema ist komplex und eben nicht greifbar und daher gibt es hier keinen natürlichen Instinkt des Menschen, der automatisch beim Großteil der Nutzer und Prüfer einen sinnvollen Reflex auslöst.

So sehen IT-Produktprüfungen in der Praxis halt anders aus. Die Definition des Prüfgegenstandes und der Schutzziele und somit relevanter Teile kann sich von dem, was man als Laie oder auch als nicht in dem System steckender Experte erwarten würde, beträchtlich unterscheiden. Ein komplexes IT-Produkt, zertifiziert und zugelassen, kann nicht vollends bis ins kleinste Detail betrachtet werden. Vieles wird einfach vorausgesetzt. Und Details, die man betrachtet, müssen letztendlich nicht einmal die entscheidenden des Gesamtproduktes sein. Unter Experten kann sich hier eine Gruppendynamik entwickeln, die gemeinsam in eine völlig falsche Richtung führt, ohne dass es natürliche Prozesse gibt, die dem Einhalt gewähren.

Wenn bei der PKW-Prüfung eine Expertenkommission dazu abdriftet, sich immer weiter auf Türen und Lenkräder zu konzentrieren und Fahrwerk und Reifen letztendlich immer weiter missachtet werden, reicht es wenn einzelnen auffällt, dass man da irgendwo das Ziel aus den Augen verloren hat und es ist instinktiv greifbar, dass da etwas nicht stimmt. Nicht so in der IT. Das kann beliebig in völlig falsche Detailrichtungen driften, ohne dass das auffällt.

Der Stempel „zertifiziert“ oder „zugelassen“ ist am Ende dann aber auf dem Gesamtprodukt und wofür dieser steht einfach uninteressant. Das Ding ist zertifiziert und zugelassen und mehr will der Anwender nun halt auch gar nicht.