Smart aber clever

IoT als Herausforderung für die Softwareentwicklung

28.09.2016
Von 


Frank Pientka ist Gründungsmitglied der iSAQB und arbeitet als Multi-Cloud-Architekt. Er hat jahrzehntelange Erfahrung in der Modernisierung von Anwendungen und besitzt mehrere AWS-Zertifizierungen.

Ohne Qualität geht nichts

Neben traditionell schon schwer und recht aufwändig zu testenden Qualitätsmerkmalen nach ISO/IEC 25000, kommen noch IoT -spezifische hinzu. Dazu zählen z.B. die Energieeffizienz, Selbstverwaltung, Langlebigkeit, Aktualisierbarkeit, Diagnostizierbarkeit, Robustheit oder Resilienz. Ebenso ist auch die Einhaltung ethischer Werte sowie die Privatsphäre, informationelle Selbstbestimmung und Sicherheit für den langfristigen Erfolg wichtig. Sicherheit und Datenschutz können hierbei nicht inkrementell geliefert werden. Sie müssen von Anfang an eingehalten werden.

Nicht erst seit dem VW-Abgasskandal ist bekannt, dass Vertrauen ein hohes Gut ist und das Nichteinhalten bestimmter Standards enorme wirtschaftliche und gesellschaftliche Folgen haben kann. Deswegen ist ein Value Sensitive Design (VSD) und dessen Überprüfung durch geeignete Review- und Auditprozesse zur analytischen Qualitätssicherung und Einhaltung der Governance-Prozesse für IoT-Produkte eminent wichtig.

Gerade bei der großen Zahl der vernetzten Geräte ist es kaum möglich, dass alle zur gleichen Zeit auf demselben Softwarestand sein können. Das kann daran liegen, dass einige Geräte gar nicht oder über längere Zeit nicht erreichbar waren oder sind. Der angebotene Dienst muss also über eine längere Zeit auch mit älteren Nutzern umgehen können. Das bedeutet, dass Änderungen an der Schnittstelle abwärtskompatibel sein müssen und neue Funktionalitäten am Dienst nur sehr gezielt vorgenommen und abgestimmt werden.

Das Thema Interoperabilität und Kompatibilität hat beim Internet der Dinge eine große Bedeutung. Oft müssen über eine längere Zeit mehrere Versionen eines Dienstes angeboten werden., Deshalb werden auch organisatorische Maßnahmen benötigt, um den Testaufwand für die Kombination unterschiedlicher Dienstversionen miteinander in machbaren Grenzen zu halten. Die Schnittstellenflut sollte außerdem über geeignete Design-Muster wie Adapter, Wrapper oder Broker reduziert werden.

Standardimplementierungen auf OpenSource-Basis sollten immer Vorrang haben gegenüber Eigenimplementierungen, da nicht nur die Interoperabilität verbessert wird, sondern auch von der Reife der Implementierung profitiert wird. Eine stetig steigende Nutzeranzahl stößt oft auch schneller auf unterschiedliche Fehlersituationen. Gerade bei Open-Source wird eine große Anzahl an Tests mitausgeliefert, die dabei helfen, eigene darauf basierende Tests zu schreiben.

"Kannst Du mich verstehen?"

Es gilt, nicht nur die von der Schnittstelle zur Verfügung gestellte Funktionalität, sondern auch die von ihr angebotene Dienstgüte zu testen. Das allein ist für den Testaufbau ein großer Aufwand und eine Herausforderung, da die Voraussetzungen für das Testen der verschiedenen Qualitätsszenarien erst geschaffen werden müssen. Allein schon wegen der Menge und der Vielzahl der Varianten geht es nicht ohne Testplanung und eine automatisierten Bereitstellung und Automatisierung.

Hier helfen Konzepte wie sie von der DevOps, Cloud und leichtgewichtigen Containern zur Verfügung gestellt werden. Sie stellen schnell, wiederholbar und effizient unterschiedliche Umgebungen in großer Anzahl zur Verfügung. Neben bisher schon verwendeten Praktiken wie Mock-Objekte, Stubs oder Testtreiber, wird es auch simulierte Schnittstellen und eine Virtualisierung der angebotenen Dienste geben.

Die Test-Virtualisierung muss jedoch mit einer repräsentativen Auswahl von physikalischen Geräten im Feldtest regelmäßig ergänzt werden. Hier kann Crowdtesting zum Einsatz kommen, um möglichst realistische Testergebnisse mit Beta-Nutzern zu erhalten. Auch hierzu gibt es bereits Cloud-Plattformen im Bereich mobile Anwendungen, um solche Testarten, inklusive Tester und deren Ergebnisse zu organisieren. Diese müssten jedoch noch für die IoT-Spezifika erweitert werden.

Es wird nicht mehr reichen, nur die Schnittstellenbeschreibung zur Verfügung zu stellen. Die Nutzer müssen ihre Annahmen an die Schnittstelle als Consumer-Oriented-Tests beschreiben und dem Dienst-Producer zur Verfügung stellen, damit dieser die Tests im Rahmen seiner kontinuierlichen Integrationsprozesse verwenden kann. Schon die alten Römer wussten: Pacta sunt servanda. Einmal vereinbarte Verträge sind auch dauerhaft einzuhalten.

Nur so können frühzeitig Fehler durch Änderungen in der internen Implementierung getestet werden oder auch mit den unterschiedlichen Qualitätstest-Szenarien nachgestellt und simuliert werden. Die Diagnostizierbarkeit bei IoT-Umgebungen ist dafür eine wichtige Voraussetzung., Da die Geräte aber von keinem Administrator betreut werden, muss die Möglichkeit bestehen, aussagekräftige Diagnoseinformationen bei Fehlern über einen definierten Zeitraum vorzuhalten und automatisiert, oder auf Anfrage, zur Verfügung stellen zu können.

Sind diese Daten zudem maschinell les- und auswertbar, können sie als hervorragende Testdaten automatisiert zur Fehlerbehebung in der Entwicklung als Testtreiber eingespielt und im Rahmen der Integration für Regressionstests verwendet werden. Diese Diagnoseinformationen sollten deshalb, neben einer eindeutigen Eingliederung der Identifikation, auch fachlichen Testkategorien zugeordnet werden, um sie für später wiederverwendbar zu machen. Hier kann es sich lohnen, diese als Basis zu nehmen und daraus auch für neue Funktionen zeitgemäße Testdaten zu generieren oder per Mutationstest Varianten davon zu erstellen.