Testen als Invariante des Engineerings — Perspektive eines Physikers

Nach jahrelanger Tätigkeit im Bereich des Systemtestens – überwiegend von Software- und Enterprise-Systemen – bin ich zu dem Schluss gekommen, dass ich das Testen aufgrund meines physikalischen Hintergrunds ganz anders betrachte als die meisten Kollegen, die im Rahmen ihres Informatikstudiums damit in Berührung kamen. Die Physik ist eine Disziplin, in der (sofern sie so funktioniert, wie sie sollte) Hypothese, Interpretation und Experiment einander motivieren und bedingen. Die Messung steht im Mittelpunkt; die Art und Weise, wie ein Experiment aufgebaut ist, spiegelt gleichzeitig den Grad des Verständnisses des Problems sowie die Methode der Datengewinnung und -auswertung wider – die Umwandlung in das, was man gemeinhin als „physikalische Größe“ bezeichnet. Der Wert einer physikalischen Größe ist nur dann sinnvoll, wenn er mit einem Messverfahren und einer Einheit verknüpft ist. Dasselbe Prinzip gilt ohne Einschränkung für die Softwarequalität.

Dies bedeutet jedoch nicht, dass es in Softwareprojekten auch angemessen repräsentiert wird. Als erfahrener Praktiker kann ich sagen, dass ich es nur sehr selten erlebt habe, dass ein Testarchitekt oder Testanalyst bereits in der „Inception“-Phase des gesamten „Abenteuers“ angemessen präsent war. Dies führt regelmäßig dazu, dass solche Projekte im Sinne einer Extremsportart tatsächlich zu einem reinen Adrenalin-Abenteuer werden.

Messung als fundamentaler Akt

Kelvins Diktum ist eindeutig: „Wenn du messen kannst, worüber du sprichst, und es in Zahlen ausdrücken kannst, weißt du etwas darüber; wenn du es aber nicht messen kannst … ist dein Wissen von dürftiger und unbefriedigender Art.“ Qualität, die nicht gemessen werden kann, ist eine Meinung. Qualität, die nach definierten Kriterien gemessen wird, ist ein ingenieurtechnisches Ergebnis. Das Testen in Ingenieurdisziplinen repräsentiert – obwohl im Prinzip identisch – etwas anderes als in der wissenschaftlichen Arbeit (zumindest wenn wir von erstklassiger Arbeit sprechen und nicht von bloßer Wiederholung, aber das ist ein Thema für ein anderes Mal). Ein Testarchitekt „sieht“ dies am besten während der Testdesign-Phase, in der eine ganzheitliche Sichtweise und eine umfassendere Risikobewertung erforderlich sind. Wir werden diesem Thema sicherlich in weiteren Beiträgen mehr Aufmerksamkeit widmen; es ist ein grundlegendes Thema, das selbst in der gängigen Software-Literatur nicht besonders gut behandelt wird.

Aus dieser Perspektive ist die Testanalyse der Akt der Ableitung messbarer Test Targets (Testziele) aus der Test Basis – Anforderungsspezifikationen, Architekturverträge, Schnittstelledefinitionen usw. Ein Test Target ist das ingenieurtechnische Gegenstück zu dem, was in der modernen Physik (insbesondere in Bezug auf den quantenmechanischen Sprachgebrauch) als „Observable“ bezeichnet wird: eine genau spezifizierte Eigenschaft des Systems, für die eine Metrik kohärent definiert und anschließend ein Pass/Fail-Kriterium formuliert werden kann. Ohne diesen Ableitungsschritt wird das Testen zu einer willkürlichen Erkundung, und die Ergebnisse sind nicht reproduzierbar.

Abdeckung als Sampling-Problem

Die Theorie der Abdeckung (Coverage) beim Testen spiegelt die Stichprobentheorie (Sampling Theory) in der experimentellen Wissenschaft wider. Der Raum der möglichen Eingaben für jedes nicht-triviale Softwaresystem ist astronomisch groß. Der Zustandsraum eines Systems wächst – bei einem Bottom-up-Ansatz „vom Code aus“ – exponentiell. Die Einbeziehung Dritter in Form der heute populären Machine-Learning-Systeme, wie etwa Agentic LLM-basierte „KI“, verbessert die Situation hinsichtlich möglicher Fehlermodi nicht; im Gegenteil, sie fügt Freiheitsgrade hinzu, die wir nicht unter Kontrolle haben. Ein erschöpfendes Testen im Sinne einer vollständigen Abdeckung – sowohl der Eingaben als auch der Systemzustände, die empirisch relevanten Funktionalitäten entsprechen, einschließlich aller möglichen Grenz-, Sub-Grenz- und Übergrenz-Zustände – ist kombinatorischer Selbstmord.

Während die Automatisierung wiederholte Regressionstests billiger macht und das Testen relativ erleichtert, wenn wir ein gut geschriebenes Testskript für eine Funktionalität haben (Datenparametrisierung), erfordert sie Wartung und Kontrolle über die Übergänge zwischen Umgebungen und Datensätzen. Auch hier senken generative Tools die Kosten für die Erstellung von Skripten und teilweise Mock-Daten radikal, aber nicht unbedingt die Korrektheit der Abdeckung auf funktionaler Ebene (Semantik ist tückisch) und sie erzeugen Mehrarbeit bei der Wartung von Testsuiten und Testdaten. Die Aufgabe des Testanalysten (in Zusammenarbeit mit anderen Projektbeteiligten) besteht daher darin, eine endliche, repräsentative Stichprobe auszuwählen, die eine statistisch zuverlässige Abdeckung des Dateneingaberaums und des Systemzustandsraums bietet, die eng miteinander verknüpft sind.

Die Invariante des Testens

Testen – als Messung – ist invariant gegenüber Methoden, so wie die Gesetze der Physik nicht von der für die Messung gewählten Methode abhängen (obwohl die Art und Weise, wie sie formuliert werden, variieren kann, aber das ist ein Thema für einen anderen Beitrag). Eine Funktion verhält sich entweder gemäß der Spezifikation oder nicht. Eine Sprint-Grenze ändert daran nichts. Ein Architekturmuster ändert daran nichts. Was sich zwischen den Methoden ändert, ist die Kadenz, mit der die Messung durchgeführt wird, und der Umfang der Testbasis, der an jedem Messpunkt verfügbar ist. Dies ist wahrscheinlich jedem offensichtlich, der Erfahrung mit großen Softwareprojekten hat.

Die ingenieurtechnisch-managerielle Konsequenz, die wir hervorheben möchten: Die Kosten für die Behebung von Defekten steigen steil an mit der Distanz zwischen dem Punkt der Einführung und dem Punkt der Entdeckung. Dies ist kein Managementprinzip – es ist eine Folge der Struktur von Software-Artefakten. Der wirtschaftliche Anreiz für die frühzeitige Einbindung eines Testarchitekten und in der Folge eines Testanalysten in das Team ist damit klar gegeben. Man kann sogar versuchen, dies im finanziellen Sinne zu messen, was meiner Erfahrung nach selten geschieht, da die Toleranz gegenüber Fehlern in den letzten zwei Jahrzehnten gestiegen ist, während die Toleranz gegenüber Liefergeschwindigkeit und Kosten gesunken ist. Dennoch ergibt sich der Anreiz für eine frühzeitige Testanalyse unmittelbar aus der skizzierten Struktur.