Testautomatisierung für Embedded Software
13.05.2015, 12:54 Uhr
Wozu ist das gut?
In der agilen Softwareentwicklung gehören das kontinuierliche Integrieren, Bauen von lauffähiger Software und automatisierte Testen zum Stand der Technik. In der Embedded-Entwicklung steigt bei gleichem Vorgehen die Komplexität.
Nicht nur die Software an sich, sondern auch Software und Elektronik müssen integriert werden. Und dies auf unterschiedlichen Ebenen, von einzelnen Software-Modulen bis zum gesamten System. Testautomatisierung im Software-Hardware-Umfeld ist komplex, kostet Aufwand und Geld. Killer-Argumente gegen die Testautomatisierung lauten: ?das rechnet sich nicht? oder ?der Nutzen kann nicht dargestellt werden?. Diesen kritischen Stimmen zum Trotz führt meiner Meinung nach im Software-/ Hardware-Umfeld kein Weg daran vorbei. Im Rahmen mehrerer Roundtable-Veranstaltungen ?Innovations-Check by Zühlke? haben sich die Argumente pro Testautomatisierung verdichtet: Juristisch belastbar: Testautomatisierung entspricht dem ?Stand der Technik?. Dieser Begriff ist juristisch besetzt und besagt, dass das Vorgehen herangezogen werden kann, um die Gründlichkeit einer Leistungserbringung nachzuweisen. In Schadensfällen und bei juristischen Auseinandersetzungen ist es erforderlich, ein Vorgehen nach dem Stand der Technik nachzuweisen, um nicht in Regress genommen zu werden. Planbar: Für Projektleiter und Business-Owner, also den wirtschaftlich Verantwortlichen des Projektes, wird das Projekt planbar. In einem eingeschwungenen Prozess ist klar, wie lange ein Testzyklus dauert, um einen Softwarestand von ?eingecheckt? nach ?auslieferbar? zu überführen. Werden Tests nicht regelmässig und standardisiert durchgeführt, so ist unklar, wie lange die Test- und Fehlerbehebungsphase am Ende eines Entwicklungsabschnitts dauert. Transparent: Entwickler können ruhiger schlafen und jeder weiss, woran er ist. Diese von Entwicklungsteams geäusserten Argumente werden umso deutlicher, wenn man die oft eingesetzten grossen Displays (z.B. Fernseher) kennt, auf denen der Fortschritt eines Softwareprojekts in Ampelnotation (rot, gelb, grün) dargestellt wird. An jedem Morgen weiss das Team Bescheid, wie der Stand der Entwicklung ist. Bewertung wird objektiv: Objektivität erhält Einzug in die Entwicklung. Akzeptanz und Abnahmen werden ebenso messbar wie Qualität. Dies schafft ein Klima des Vertrauens. Qualität wird unabhängig von einzelnen Köpfen: Testautomatisierung ist unabhängig von der Verfügbarkeit von einzelnen Mitarbeitern. Gerade bei Krankheitsfällen kommt es bei halbautomatischen und nicht standardisierten Tests immer wieder zu Problemen. IT wird effektiv genutzt: Es ist effektiv, vorhandene Rechenleistung von PCs oder anderen Computern ausserhalb der Arbeitszeiten zu nutzen. Mit Testautomatisierung werden Rechner von Entwicklern während der Arbeitszeit ent- und in Ruhezeiten belastet. Software und Elektronik rücken näher zusammen: Die Entwicklung von Software und Elektronik wird durch die frühe und kontinuierliche Integration besser ineinander verzahnt und so aufeinander abgestimmt. Die Wahrscheinlichkeit, dass in Tests auf Systemebene etwas grundlegend scheitert, wird reduziert. Elektronik wird getestet: Auch die Elektronik wird getestet, und zwar ab Projektbeginn. Der Testplatz der Software wird zum Dauerprüfstand für die Hardware. Fehler können nachvollzogen werden: Gerade für nicht reproduzierbare Fehler wird eine elementare Analysemöglichkeit geschaffen. Aufgrund der Verfügbarkeit der Test-Historie ist es möglich, Testergebnisse in der Vergangenheit anzusehen, Verbindungen zwischen Testläufen herzustellen und so Fehlersituationen nachzuvollziehen, die ohne Testautomatisierung nicht nachvollziehbar erscheinen. Fazit: Die positiven Argumente wiegen stark. Letztendlich geht es ?nur? darum, wie Testautomatisierung aufgesetzt wird, nicht ob.