Testsoftware: Was sollte Standard sein – und was individuell?

Standardisierung klingt zunächst nach einem einfachen Ziel: Je mehr Testsysteme nach denselben Regeln funktionieren, desto leichter lassen sie sich entwickeln, betreiben und warten.

In der Praxis liegt die Schwierigkeit an einer anderen Stelle. Elektroniktests entstehen aus konkreten Produkten, Messaufgaben und Produktionsbedingungen. Genau dort gibt es Unterschiede, die technisch sinnvoll und teilweise unvermeidbar sind. Eine gute Teststrategie versucht deshalb nicht, möglichst viel Gleichheit herzustellen. Sie entscheidet bewusst, an welchen Stellen Unterschiede überhaupt einen Wert haben.

Denn Individualität ist dort sinnvoll, wo die Aufgabe individuell ist. An vielen anderen Stellen erzeugt sie vor allem zusätzlichen Aufwand.

Jede Testaufgabe hat ihren eigenen Kern

Ein Steuergerät stellt andere Anforderungen als eine Baugruppe mit Hochfrequenzsignalen. Ein Funktionstest folgt einer anderen Logik als ein einfacher elektrischer Endtest. Prüflinge unterscheiden sich bei Schnittstellen, Messpunkten, Grenzwerten, Kontaktierung und Testtiefe.

Diese Unterschiede gehören zum eigentlichen Engineering. Hier muss eine Testlösung Raum für das konkrete Produkt lassen.

Auch der Testablauf selbst kann sehr spezifisch sein. Welche Messungen notwendig sind, in welcher Reihenfolge sie stattfinden, welche Geräte angesprochen werden und wie auf bestimmte Ergebnisse reagiert wird, ergibt sich aus der jeweiligen Aufgabe.

Wer versucht, diese Ebene zu stark zu vereinheitlichen, verschiebt die Komplexität häufig nur. Dann entstehen Umwege, Sonderregeln und Konstruktionen, mit denen die reale Aufgabe wieder in ein zu enges Schema hineingezwängt wird.

Die interessantere Frage beginnt deshalb eine Ebene darüber.

Wie individuell muss das Drumherum wirklich sein?

Ein Testprogramm benötigt Messgeräte und Grenzwerte. Es erzeugt Ergebnisse. Es braucht Produkt- und Auftragsinformationen, muss Fehler behandeln, Daten speichern und häufig mit übergeordneten Systemen kommunizieren.

Diese Aufgaben wiederholen sich.

Trotzdem werden sie in gewachsenen Testlandschaften häufig immer wieder neu gelöst. Ein Projekt bekommt eine eigene Ergebnisablage, das nächste eine andere Geräteanbindung. Für eine neue Station entsteht eine zusätzliche Schnittstelle. Varianten werden in einem Projekt über Konfigurationsdateien verwaltet, in einem anderen direkt im Programmcode.

Jede einzelne Entscheidung kann für sich plausibel gewesen sein. Über Jahre entsteht daraus jedoch eine Landschaft, in der immer mehr Wissen an einzelne Projekte, Stationen oder Personen gebunden ist.

Das bleibt oft lange beherrschbar. Kritisch wird es meist erst dann, wenn Änderungen mehrere dieser Lösungen gleichzeitig betreffen. Neue Betriebssysteme, geänderte Datenanforderungen, zusätzliche Produktvarianten oder neue Schnittstellen müssen dann an vielen Stellen einzeln nachvollzogen werden.

Aus technischer Freiheit kann so schrittweise ein Wartungsproblem werden.

Genau hier besitzt Standardisierung ihren größten Hebel.

Standardisieren, was sich wiederholt

Besonders geeignet sind Funktionen, die viele Testaufgaben benötigen und deren grundlegendes Problem bereits bekannt ist.

Dazu gehören beispielsweise die Verwaltung von Testprojekten und Varianten, Geräteanbindungen, Benutzer- und Rechtekonzepte, Ergebnisdatenbanken, Traceability, Logging, Schnittstellen zu Produktionssystemen sowie Mechanismen für Verteilung, Replikation und Auswertung.

Auch der Entwicklungsprozess selbst lässt sich vereinheitlichen. Wenn Testprogramme nach einer gemeinsamen Struktur aufgebaut werden, Entwickler dieselben Werkzeuge verwenden und typische Aufgaben über definierte Funktionen lösen, entsteht ein gemeinsames technisches Vokabular.

Das hat Folgen, die weit über eingesparte Entwicklungszeit hinausgehen.

Ein Ingenieur kann sich schneller in ein fremdes Projekt einarbeiten. Änderungen folgen bekannten Mustern. Funktionen, die einmal robust gelöst wurden, müssen nicht mit jedem neuen Prüfplatz erneut entstehen. Verbesserungen an der gemeinsamen Basis können mehreren Systemen zugutekommen.

Aus vielen einzelnen Testlösungen wird schrittweise eine beherrschbare Testlandschaft.

Standardisierung erleichtert auch die Modernisierung

Besonders sichtbar wird dieser Effekt, wenn eine bestehende Testlandschaft weiterentwickelt werden soll.

Solange jedes Projekt seine eigene Datenhaltung, Geräteanbindung oder Ablaufsteuerung mitbringt, muss auch jede Modernisierung an vielen Stellen einzeln ansetzen. Schon vergleichsweise kleine technische Veränderungen können dadurch mehrere Projekte gleichzeitig betreffen.

Eine gemeinsame Plattform verschiebt wiederkehrende Aufgaben in einen stabilen Kern. Testprogramme können dann auf einer gemeinsamen Infrastruktur aufbauen, während ihre produktspezifische Logik erhalten bleibt.

Das ist gerade für bestehende Anlagen relevant. Eine Modernisierung muss dadurch nicht zwangsläufig mit einem vollständigen Austausch verbunden sein. Vorhandene Messgeräte, Adapter und Mechanik können weiter genutzt werden, während Softwarestrukturen schrittweise vereinheitlicht werden.

Bei mehreren Testprojekten oder Stationen kann dieser Übergang Stück für Stück erfolgen. Einzelne Projekte werden migriert, erprobt und anschließend ausgerollt. Die Standardisierung wird damit selbst zu einer Voraussetzung dafür, Veränderungen beherrschbar zu machen.

Standardisierung endet nicht an der Hardware

Gerade bei bestehenden Anlagen entsteht leicht der Eindruck, eine gemeinsame Softwarebasis setze weitgehend identische Hardware voraus.

Für Testsysteme wäre das oft ein unrealistisches Ziel. Messgeräte haben unterschiedliche Lebenszyklen. Adapter sind produktspezifisch. Manche Anlagen verwenden PXI- oder CompactPCI-Systeme, andere klassische Tischgeräte, proprietäre Hardware oder über viele Jahre gewachsene Kombinationen daraus.

Eine tragfähige Standardisierung muss solche Unterschiede aufnehmen können.

Der gemeinsame Nenner liegt deshalb häufig in der Softwarearchitektur: Geräte werden über definierte Schnittstellen eingebunden, Testabläufe folgen derselben Systematik und Ergebnisse landen in gemeinsamen Strukturen. Unterhalb dieser Ebene darf die konkrete technische Umsetzung unterschiedlich bleiben.

So kann eine ältere Anlage mit vorhandenen Messgeräten nach denselben Prinzipien betrieben werden wie ein neu aufgebautes System mit aktueller Hardware.

Der Standard schafft hier gerade dadurch Einheitlichkeit, dass er Unterschiede zulässt.

Auch Prozesse brauchen Spielraum

Ähnliches gilt für Produktionsabläufe.

Ein manueller Prüfplatz funktioniert anders als eine vollautomatische Linie. Ein System erhält seinen Auftrag vielleicht über einen Barcode, ein anderes über ein MES. An einer Station entscheidet ein Bediener über die Variante, an einer anderen kommt diese Information vollständig aus der Produktionssteuerung.

Eine gemeinsame Plattform sollte solche Abläufe nicht künstlich angleichen. Sinnvoller sind wiederverwendbare Bausteine und definierte Schnittstellen, aus denen der konkrete Prozess zusammengesetzt werden kann.

Damit verschiebt sich die Individualisierung an die richtige Stelle: Der Prozess darf individuell sein, seine technischen Grundbausteine bleiben bekannt.

Der entscheidende Unterschied liegt zwischen Konfiguration und Sonderentwicklung

Ein guter Hinweis auf die Qualität eines Standards ist die Frage, wie neue Anforderungen umgesetzt werden.

Muss für jede Abweichung die gemeinsame Software verändert werden, wird der Standard schnell selbst zum Engpass. Lassen sich Unterschiede über Projekte, Konfigurationen, Plugins, Schnittstellen oder klar definierte Erweiterungspunkte abbilden, kann die gemeinsame Basis stabil bleiben.

Ein Standard muss nicht jeden zukünftigen Anwendungsfall bereits kennen. Er braucht eine Architektur, in der neue Anwendungsfälle ihren Platz finden können.

Gerade über viele Jahre entscheidet diese Eigenschaft darüber, ob Standardisierung dauerhaft entlastet oder irgendwann selbst eine neue gewachsene Struktur erzeugt.

Was sollte eine Plattform bereits mitbringen?

Damit wird die Frage nach Standardisierung auch zu einer Frage der Plattformwahl.

Je mehr grundlegende Funktionen bereits stabil vorhanden sind, desto weniger Infrastruktur muss im einzelnen Projekt neu entwickelt und später gepflegt werden.

Relevant sind deshalb nicht nur die Möglichkeiten, ein Testprogramm zu schreiben. Ebenso wichtig sind fertige Strukturen für Datenhaltung, Varianten, Geräteintegration, Benutzerverwaltung, Traceability, Entwicklungsworkflow, Verteilung oder Schnittstellen zu anderen Systemen.

Gleichzeitig muss die Plattform genügend Raum für projektspezifische Anforderungen lassen.

Eine gute Auswahlentscheidung betrachtet deshalb beide Seiten: Welche Aufgaben sollen dauerhaft aus den Projekten herausgenommen werden, und an welchen Stellen muss die Lösung offen für individuelle Anforderungen bleiben?

Gerade bei langfristig genutzten Testsystemen ist diese Balance oft wichtiger als die Frage, welche einzelne Funktion kurzfristig schneller umgesetzt werden kann.

Nicht jede Vereinheitlichung lohnt sich

Standardisierung verursacht ebenfalls Aufwand. Gemeinsame Lösungen müssen entwickelt, gepflegt, dokumentiert und über unterschiedliche Anwendungsfälle hinweg stabil gehalten werden.

Deshalb lohnt sich ein Standard vor allem dort, wo Funktionen häufig wiederkehren, mehrere Systeme davon profitieren oder langfristige Abhängigkeiten entstehen.

Eine einmalige Spezialmessung darf speziell bleiben. Ein ungewöhnlicher Adapter muss keinem unternehmensweiten Schema folgen, wenn daraus kein Nutzen entsteht. Eine produktspezifische Berechnung gehört möglicherweise genau in dieses eine Testprojekt.

Anders sieht es bei Funktionen aus, die mit jeder Anlage erneut benötigt werden. Werden Ergebnisverwaltung, Benutzerrechte oder Gerätekommunikation zum fünften Mal individuell entwickelt, ist die entscheidende Frage längst nicht mehr, ob diese Aufgabe lösbar ist. Interessanter ist, warum sie überhaupt noch einmal gelöst werden muss.

Eine einfache Orientierung kann deshalb lauten:

Alles, was bei mehreren Testprojekten erneut entwickelt, gepflegt oder erklärt werden muss, ist ein Kandidat für Standardisierung. Alles, was unmittelbar aus Produkt, Messverfahren oder Produktionsprozess entsteht, braucht bewusst Raum für Individualität.

Ein stabiler Kern mit beweglichen Rändern

Am Ende lässt sich die Grenze zwischen Standard und Individualität weniger über einzelne Technologien ziehen als über ihre Rolle im Gesamtsystem.

Der Standard bildet den stabilen Kern: wiederkehrende Funktionen, gemeinsame Strukturen, definierte Schnittstellen und Werkzeuge, auf die sich Projekte verlassen können.

Die Individualität liegt näher an der konkreten Aufgabe: beim Prüfling, bei Messverfahren, Prozessbesonderheiten und speziellen Anforderungen.

Eine solche Trennung beseitigt Unterschiede nicht. Sie ordnet sie.

Und genau darin liegt der eigentliche Wert einer standardisierten Testplattform: Sie sorgt dafür, dass individuelle Entwicklungsarbeit dort stattfindet, wo sie tatsächlich einen technischen Unterschied macht.