Ein Kunde der Automatisierungstechnik hatte einen smarten Sensor entwickelt, der mit knapp 1000 Konfigurationsparametern einiges an Funktionalität mitbrachte. Der Sensor konnte Standalone oder im Verbund mit anderen Knoten an einem Systembus betrieben werden. Die Entwicklung des Kunden führte Unittests auf Klassenebene der Firmware, sowie manuelle Handtests des Standalonebetriebs durch. Die Integrationsingenieure führten manuelle Gesamtsystemtests an ihrem Arbeitsplatz und in einer produktionsnahen Testanlage durch, bei denen sie auch die Netzwerkfunktionalitäten überprüften.
Das Produkt verkaufte sich gut, jedoch dauerte ein Release sehr lange und es tauchten immer wieder schwer zu reproduzierende Probleme beim Einsatz im Verbundbetrieb des Geräts auf. Die anschließende Fehlersuche war meistens sehr aufwändig und belegte viele Ressourcen der Entwicklung. Bei der gemeinsamen Analyse stellte sich heraus, dass die große Anzahl von Testfällen schon kaum für einen einzigen Release-Kandidaten im Standalonebetrieb durchgeführt werden konnte. Regressionstests waren kaum möglich. Die Tests des Verbundbetriebs mussten sich zwangsläufig auf Gutfälle beschränken, da viele Fehlerszenarien kaum manuell herstellbar waren.
Der Kunde entschied sich mit awinia die Lücken in der Testpyramide zu füllen und die manuellen Tests durch automatisierte System- bzw. Systemintegrationstests zu ersetzen bzw. zu ergänzen. Dazu wurden mehrere Testumgebungen definiert:
- Simulation: In dieser Umgebung wurde die Firmware des Geräts in einer PC-Simulation getestet, wobei die gesamte Peripherie ebenfalls simuliert wurde.
- Local: Hier wurde das reale Gerät lokal an einen PC angeschlossen und getestet, wobei die gesamte Peripherie simuliert wurde.
- Standalone: In dieser Testumgebung wurde das reale Gerät auf einem Brett montiert und alle Schnittstellen mit steuerbaren Controllern verbunden.
- Systembus: In der umfangreichsten Testumgebung wurden mehrere reale Geräte mit teils realer Peripherie und mehreren steuerbare Controllern über den Systembus verbunden.
Mit den unterschiedlichen Testumgebungen war es möglich Systemtests als Teil des CI-Builds der Entwicklung durchzuführen. Dadurch entstand eine große Testbreite mit schnellem Feedback für die Entwickler. Weiter konnten nun auch reproduzierbar komplexe Szenarien von Geräten im Verbund produktionsnah und mit Fehlerfällen getestet werden. Dadurch entstand eine große Testtiefe.
Der Clou bestand nun darin, Testfälle derart zu implementieren, dass sie möglichst gegen alle Testumgebungen ausgeführt werden konnten. Dazu wurde als Tool pytest gewählt und damit eine Architektur umgesetzt, die den Prinzipien der generische Testautomatisierungsarchitektur des ISTQB folgt. Die darin enthaltene Testadaptierungsschicht, wurde für jede Testumgebung geeignet reimplementiert.
Mit der Simulationsumgebung konnten Tests nun sehr einfach – von der Testabteilung oder der Entwicklung – umgesetzt werden, so dass schnell viele neue Tests entstanden, die zu einer breiten Abdeckung führten. Viele Fehler wurden nun schon direkt beim Regressionstests im CI-Build von der Entwicklung selbst gefunden. Die mobilen Testaufbauten machten die Fehleranalyse deutlich effizienter. Innerhalb von 2 Jahren waren 70% der manuellen Tests automatisiert, wobei die Testtiefe deutlich zugenommen hatte.
In der Systembus-Testumgebung war es nun auch möglich komplexere Fehlerszenarien reproduzierbar zu testen, die z.B. durch Rekonfiguration, Ausfall oder Reboot eines Knoten entstanden. Dies ersparte der Entwicklung, Testabteilung und den Integrationsingenieuren teils wochenlange Fehlersuche und Analyse in der Testanlage. Die Testumgebung konnte weiter dazu genutzt werden Performance- und Lasttests durchzuführen.
Durch Einführung der Testautomatisierung konnte die Qualität des Produkt deutlich gesteigert und seine Releasefrequenz fast verdoppelt werden.