Software-Qualität verbessern Die fünf Gebote der Embedded-Software-Entwicklung

Neue Werkzeuge, Designmuster und Entwicklungsparadigmen versprechen eine Qualitätssteigerung, ohne Entwicklungsdauer und -aufwand zu erhöhen. Doch es kann niemals ein Patentrezept geben, das die Qualität verbessert und dabei nichts kostet. Es gibt jedoch fünf Grundsätze, die dabei helfen können, die Qualität von Software zu verbessern.

Viele Anwender haben die Erfahrung gemacht, die neuesten Versionen von Anwendungssoftware besser erst dann zu nutzen, wenn die unvermeidlichen Service-Packs und Patches veröffentlicht wurden. Selbst Apple ist vor fehlerhaften Veröffentlichungen nicht gefeit – iOS 8 war von so vielen Fehlern geprägt, dass viele Kunden ihre Unzufriedenheit sogar öffentlich bekundeten. Aufgrund der so entstandenen enormen negativen Aufmerksamkeit berichtete sogar die New York Times ausführlich über einige der Probleme in einem Blog-Beitrag.

Obwohl sich jeder über die »Software Quality Gap« (Software-Qualitätslücke) im Klaren ist, die zwischen der V1.0 und der stabilen Version V1.n besteht, wurden bislang leider recht wenige Fortschritte erzielt, dieses generelle Problem zu lösen. Um Entwicklungsteams zu helfen, die Qualitätslücke zu schließen, werden in diesem Artikel fünf universell anwendbare Ideen erörtert:

  • Codeabdeckungsanalyse (Code Coverage Analysis) zur Messung der Testvollständigkeit nutzen,
  • Testabdeckung (Test Coverage) durch Unit-Tests erhöhen, 
  • Tests vereinfachen und Testergebnisse einfach verständlich machen,
  • automatisiertes, paralleles und änderungsbasiertes Testen implementieren und
  • kontinuierliches Umgestalten (Refactoring) des Codes, um dessen Wartungsfreundlichkeit zu erhöhen.

Code- und Testabdeckung

Die Code-Coverage-Analyse stellt die jeweiligen Anteile des Quellcodes der Anwendung heraus, die von einem Satz von Testfällen ausgeführt wurden. Eine solche Analyse ist der beste Weg, um die Vollständigkeit der Testaktivitäten zu messen. Ohne die Codeabdeckung zu messen, würde man sozusagen »blind« testen.

Wichtig ist es, zu verstehen, dass das Erreichen einer hundertprozentigen Codeabdeckung nicht zwingend beweist, dass eine Anwendung perfekt ist, allerdings ist es eine kritische Komponente bei der Entwicklung von hochwertiger Software. Fakt ist, dass alle mit der Entwicklung sicherheitskritischer Software assoziierten Standards die Code-Coverage als Teil des Entwicklungsprozesses vorschreiben. Die Luftfahrt nutzt DO-178B/C, die Automobilbranche hat die ISO 26262, die IEC 61508 gilt für die industrielle Automatisierung, FDA- und IEC-62304-Standards gelten für medizinische Geräte, und der CENELEC-Standard wird in der Bahntechnik eingesetzt.

Beginnt man mit der Messung der Testabdeckung, wird schnell deutlich, dass die existierenden Tests signifikant weniger als 100% Coverage bieten. Diese Abdeckungslücke (Coverage Gap) beruht darauf, dass die Tester sich auf Nennanwendungsfälle und nicht auf Fehlerfälle oder Grenzbedingungen konzentrieren. Der offensichtliche Weg, die Coverage-Gap zu schließen, besteht darin, zusätzliche funktionale Tests hinzuzufügen. Erfahrungsgemäß ist es allerdings sehr wahrscheinlich, dass 20% bis 30% des Anwendungscodes innerhalb einer Produktionsumgebung mit funktionalen Tests sehr kompliziert zu testen sind, da es nicht einfach ist, die zum Triggern der Fehlerbehandlung benötigten Fehler einzufügen (Bild 1).