Tipps für einfache Softwaretests

Kein Wunder, dass das Qualitätsmanagement für viele Softwarehersteller ein Problem von strategischem Ausmaß darstellt. Denn leidet die Qualität der entwickelten Software, können in Folge beispielsweise Service Level Agreements nicht mehr eingehalten werden. Das zieht unzufriedene Kunden nach sich. Was die Arbeit der Entwickler zudem erschwert, ist, dass die Teams oftmals geographisch weit verteilt sind. Nicht selten muss auch Code von Dritten integriert werden. Mit so vielen Variablen ist es für das Management schwer, die Übersicht über das Projekt zu behalten. Das ist jedoch die Voraussetzung, um potentiellen Qualitätsrisiken früh entgegen zu steuern.

Die mangelnde Transparenz erschwert außerdem die Organisation der Zusammenarbeit und macht Prozesse ineffizient. So dauern Qualitäts- und Sicherheitsüberprüfungen in solchen Konstellationen unnötig lange. Das steigert erst recht das Risiko, dass Softwaredefekte innerhalb des Entwicklungsprozesses weiter verschleppt werden oder sich sogar in ausgelieferte Versionen einschleichen. Ein wirkungsvolles Gegenmittel ist das Development Testing. Dieser Ansatz zum Softwaretesten erweitert traditionelle Methoden und unterstützt Unternehmen dabei, die oben beschriebenen Herausforderungen besser zu bewältigen. Die folgenden fünf Tipps helfen auf dem Weg dahin:

1. Einbettung in die Entwicklung: Testen, während der Code kompiliert wird
Tester stehen meist vor einem Dilemma: Traditionelle Ansätze sind zwar effektiv, gleichzeitig jedoch limitiert. Sie setzen häufig erst nach der Entwicklung an, um Funktionalität und Leistung der Software sicherzustellen. Doch Entwickler sind nur schwer dazu zu bewegen, sich nach Abschluss ihrer Programmierarbeit um neu entdeckte Softwarefehler zu kümmern. Auf der anderen Seite akzeptieren sie die Integration neuer Technologien in den Entwicklungsprozess nur, wenn sie ihre Arbeitsabläufe nicht behindern. Ergebnisse von Softwaretests müssen für die Programmierer relevant und gut umsetzbar sein. Andernfalls verlangsamt die Fehlerbeseitigung den gesamten Prozess zu sehr.

Development Testing liefert den Entwicklern eben diese Ergebnisse. Dadurch ergänzt es traditionelle Testverfahren, indem es schwer zu entdeckende kritische Fehler schnell identifiziert. So können sie noch während der Entwicklung behoben werden.

2. Priorisierung des Testaufwandes durch die Entwickler: Fokus auf kritische Anwendungen mit komplexen Code-Strukturen
Entwickler müssen Code-Defekte schnell und einfach verwalten können – besonders, wenn der Code sehr komplex ist. Es ist schließlich wichtig, zunächst die Softwarefehler mit dem größten Schadenspotential auszumerzen. Dementsprechend müssen die gefundenen Fehler priorisiert werden. Im Anschluss sollte den Entwicklern automatisch angezeigt werden, wo innerhalb der verschiedenen Projekt- und Code-Bestandteile sich die Fehler befinden. Das minimiert unnötige Doppelarbeit. Darüber hinaus sollten Informationen auch team- und länderübergreifend geteilt werden können.

3. Automatisiertes Testen und klare Verantwortlichkeiten bei der Softwareentwicklung
Dank Development Testing können Entwickler schwer aufzuspürende kritische Defekte früh entdecken. Dadurch wird die Automatisierung des Testens ungemein vereinfacht. Das reduziert Kosten und Risiken der Entwicklung stark.

So haben viele Unternehmen Development Testing bereits in Nachtläufe integriert: Entwickler reichen ihren Code am Ende des Arbeitstages ein – und erhalten am nächsten Morgen automatisch eine Benachrichtigung über gefundene Probleme. Durch die Automatisierung können weit verteilte Teams mit nur einer Analyse tausende von Defekten beheben und Millionen Codezeilen testen lassen. Parallele und inkrementelle Analyse untersucht umfangreichen Code in Minuten. Zeit spart auch die optionale selektive Analyse: Es werden nur die von den Programmierern geänderten Dateien überprüft, sowie die von den Änderungen beeinflussten Dateien.

4. Aus Fehlern lernen und Muster von defektem Code erkennen
Entwickler sollten sich bei der Fehleranalyse zunächst einen Überblick über die Schwere der Defekte verschaffen, um kritische als Erstes zu beheben. Development Testing liefert deshalb zu jedem entdeckten Fehler eine eindeutige Erklärung. Die Programmierer erhalten so gut umsetzbare Informationen, um – unter Einbeziehung der möglichen Auswirkungen der gefundenen Defekte auf das Gesamtprojekt – bessere Entscheidungen zu treffen. Dadurch reduziert sich das Risiko zeitlicher Verzögerungen und auftretender Qualitätsprobleme für alle Produkte.

Auch die im Development Testing mögliche Simulation von Funktionsaufrufen hilft dabei, das Übel an der Wurzel zu packen: Entwickler können den Ausführungspfad oft tiefverwurzelter „Interprocedural Defects“ nachvollziehen. Dadurch entwickeln sie ein besseres Verständnis für deren Ursache. Mit herkömmlichen Methoden der Qualitätssicherung sind diese Defekte oft kaum zu lokalisieren. Auch andere Fehler wie Speicherverletzungen, Ressource Leaks, Verletzung von Sicherheitsstandards oder unsichere Handhabung von Daten lassen sich mit Development Testing leichter aufspüren und beheben.

Dieser neue Ansatz stellt zudem die Auswirkungen eines gefundenen Defektes auf den gesamten Quellcode visuell dar. Die Entwickler sehen so, ob sich ein gefundener Defekt auch in anderen Projekten und Produkten wiederfindet und wie er sich auf diese auswirkt. Zu guter Letzt wird auch die Verwaltung der Fehler präzise und kontrollierbar. Identische Fehler, die zuvor noch fälschlicherweise mehrfach angezeigt wurden, werden nun nur einmal gemeldet – samt Verweis auf alle unterschiedlichen Lokalisierungen im Quelltext. Die Behebung von Defekten geht dadurch schneller, die Transparenz steigt.

5. Zeitaufwand versus erzielte Qualitätsverbesserungen
Die Darstellung der Fehlerhistorie und des Behebungsstatus auf Programmier- und Projektebene ist ausschlaggebend, um die Entwicklerproduktivität und die erzielten Qualitätssteigerungen bewerten zu können. Development Testing hilft, entscheidende Fragen zu beantworten:

– Welche Defekte wurden behoben und konnten alle kritischen Fehler ausgebessert werden?
– Konnten sämtliche Ausprägungen des Defektes (gemeinsamer Quelltext!) erkannt und gegebenenfalls behoben werden?
– Wie steht es um unsere Defekt- und Qualitätsentwicklung, gefiltert nach Produkt, Release, Checker und Art des Fehlers sowie nach Entwickler über einen bestimmten Zeitraum?

* Der Autor, Chris Adlard, ist Senior Manager Global Communications & Customer Advocacy bei Coverity