Ein Kunde aus der Prozessautomatisierung hatte eine Produktfamilie von smarten Sensoren entwickelt. Die Geräte unterschieden sich in ihrem physikalischen Messprinzip, ihrem unterstützten Feldbus und – aufgrund ihrer Hardwareausstattung – in Funktionsumfang und Leistungsfähigkeit. Insgesamt existierten bereits über 60 Gerätevarianten und jedes Jahr kamen weitere hinzu. Die Entwicklung der Gerätefamilie schritt zügig voran, da der Kunde auf eine ausgereifte Produktplattform in Verbindung mit modellgetriebener Softwareentwicklung zurückgreifen konnte. Problem war, dass die Umsetzung von automatisierten Systemtests mit diesem Tempo nicht mithalten konnten und so die Releases der Geräte stark verzögert wurden.
Eine Analyse zeigte, dass der Kunde für die Entwicklung der Firmware ein Plattform-Team gebildet hatte, das den Geräteteams wiederverwendbare Softwarekomponenten bereitstellte. Dagegen wurden die Tests von jedem Geräteteam selbst entwickelt, was dazu führte, dass Tests häufig von einem anderen Gerät übernommen und dann unabhängig weiterentwickelt wurden. Zu Beginn waren Tests meist noch generisch, jedoch musste mit der Zeit auf immer mehr subtile Unterschiede Rücksicht genommen werden, so dass der Testcode auseinander lief und dessen Wartung mit Weiterentwicklung aller Gerätevarianten einen hohen Aufwand erzeugte.
Der Kern der Lösung bestand darin eine Produkttestplattform analog zur Produktplattform aufzubauen und es damit zu ermöglichen, die gleichen Testfälle gegen alle Gerätevarianten auszuführen. Dabei war eine zusätzliche Herausforderung, dass die Tests nicht nur die oben beschriebenen Freiheitsgrade besitzen, sondern auch noch in unterschiedlichen Testumgebungen ausführbar sein müssen.
Die Softwarearchitektur der Produkttestplattform folgte den Prinzipien der generische Testautomatisierungsarchitektur des ISTQB. Die darin enthaltene Testadaptierungsschicht, wurde für jedes „Device Under Test“ (DUT) und jede Testumgebung geeignet reimplementiert, wobei die jeweiligen Spezifika jeweils separat in Modulen gekapselt wurden. Den Prinzipien des Domain-Driven-Designs folgend, wurden die Schnittstellen von DUT und Testumgebung an einer „gemeinsamen Sprache“ ausgerichtet, die alle Testfälle verwenden, wenn sie mit einer Testumgebung bzw. einem Gerät interagieren möchten. Idealerweise sind Testfälle dann DUT-transparent und adressieren nur den fachlichen Prozess in der Domäne. Die Domänenkommandos der Testumgebung werden dann im Testumgebungs- bzw. DUT-Adapter spezifisch umgesetzt.
Ausgehend von den vorhandenen Testimplementierungen wurden die DUT-Spezifika aus den Testfällen – Gerät für Gerät – herausrefaktorisiert. Dabei wurde häufig Dependency-Injection eingesetzt, um spezifisches Verhalten aus der der Testumgebung in die Testtreiber zu bekommen. Nach drei Jahren waren alle Systemtests auf die Produkttestplattform umgestellt und es gab über tausend geräteunabhängige Testfälle. Eine neue Gerätevariante konnte innerhalb von wenigen Wochen eingebunden werden und besaß dann schon eine Testabdeckung von über 80%. Testanpassungen, aufgrund von aus der Produktplattform kommenden Änderungen der Geräteschnittstellen, konnten innerhalb weniger Tage nachgezogen werden.