Softwarequalität Falsches Testen – Teure Fehler

Qualitätssicherung kostet Geld, ebenso aber fehlerhafte Software. Für ein mangelhaftes Produkt können in Extremfällen die Haftungskosten sehr hoch werden. Dennoch ist eine Steigerung der Qualität aufgrund der dabei entstehenden Kosten nicht immer gerechtfertigt. Der Aufwand für die Qualität eines Produktes und die möglichen Kosten für nicht entdeckte Fehler müssen sich die Waage halten. Dies geschieht durch einen gut angepassten Testprozess.

Anbieter zum Thema

MES Electronic Connect GmbH & Co. KG

ISH Ingenieursozietät GmbH

IBR Leiterplatten GmbH & Co. KG

Mixed Mode GmbH

Die Tatsache, dass Software immer umfassender und möglichst effizient geprüft werden muss, dürfte unmittelbar einsichtig sein. Vielen potenziell fehlerhaften Geräten sind wir weitaus stärker ausgeliefert als nur mit der Verschwendung unserer Lebenszeit. Im medizinischen Bereich zum Beispiel sowie bei nahezu allen Transportmitteln kann ein Softwarefehler potentiell tödliche Konsequenzen haben. In anderen Fällen können schwerwiegende finanzielle, logistische und juristische Folgen auftreten, etwa bei Verwaltungs- oder Abrechnungssoftware.

Angesichts dessen ist es nur schwer verständlich, dass es trotz gut eingeführter und bewährter Techniken zur Sicherung von Softwarequalität immer noch Hersteller gibt, die, wenn sie auch nicht ganz darauf verzichten, so doch zumindest so unprofessionell zu Werke gehen, dass regelmäßig mangelhafte Produkte die Folge sind. Softwarequalität ist ein Teil des gesamten Produktqualitätsmanagements. Dies gilt für reine Softwareprodukte ebenso wie für Geräte, bei denen die Software nur einen verhältnismäßig geringen Anteil stellt. Als Hersteller sollte man zwei Dinge stets im Auge behalten: die Ansprüche des Endanwenders sind sehr hoch. Demzufolge ist die Frustrationstoleranz selbst bei kleineren Mängeln niedrig. Zum anderen haben Hersteller in Westeuropa nahezu keine andere Möglichkeit, auf Dauer global konkurrenzfähig zu bleiben, als über eine garantierte und gleichbleibend hohe Produktqualität.

Höhere Komplexität erfordert Umdenken bei Testverfahren

Aufgrund historischer Wurzeln wird gerade im mittelständischen Betrieben der Test nach wie vor am Schluss der Entwicklung durchgeführt. In den letzten Jahren ersetzt Software immer mehr Hardwarefunktionen, wobei der Anteil zunächst gering war und als Bestandteil von Hardwarebausteinen angesehen werden konnte. Die Hauptfunktionalität lag weiterhin bei der Hardware. In diesem Fall genügte der Endtest am Schluss der Hardwareintegration. Mit zunehmender Verlagerung der Funktionen auf die Software erhöht sich ihre Komplexität. Das erfordert zwingend andere Testverfahren, wie auch die Chancen für Fehlfunktionen größer werden. Mit dieser Verschiebung haben aber nicht alle Entwicklungsprozesse in den Firmen Schritt gehalten. Das Resultat: nicht mehr sachgerechte Testverfahren.

Die Komplexität des Testens wird oft unterschätzt, da nicht jeder die Verfahren und die assoziierten Problematiken (u.a auch psychosozialer Natur) des Testens kennt. Daher herrscht oft die Meinung vor, ein am Schluss der Integration durchgeführter Abnahmetest reiche aus. Aber: Wird zu dem Zeitpunkt ein architektonisch tiefliegender Fehler gefunden, können die Auswirkungen fatal sein. Je später im Produktionsprozess Fehler entdeckt werden, um so kostspieliger wird ihre Beseitigung.

Es gibt zwei Phasen in der Produktion, mit denen die Kosten sprunghaft ansteigen (Bild 1): Sobald der erste Code geschrieben ist, und sobald die Systemintegration so fortgeschritten ist, dass der erste Feldeinsatz bevorsteht. Selbst nach sorgfältigem Testen muss erfahrungsgemäß von Restfehlern ausgegangen werden (Restfehlerrate). Sie liegt durchschnittlich bei ein bis zwei Fehlern pro 1000 Codezeilen, davon können wiederum 3 bis 10% schwerwiegend sein.

Im Avionikbereich, die Software für Flugzeugsteuerung und Flugsicherung herstellt, werden die strengsten Sicherheitsmaßnahmen angewendet. Dennoch gehen Schätzungen von 200 oder mehr verbliebenen, potentiell schwerwiegenden Softwarefehlern in einer Flugzeugsoftware aus. In einem bekannten Fall fiel bei extrem schwerem Wetter mit hohen Rollraten die Software eines Flugzeugs aus. Ursache dafür war, dass die Neigungswinkel vom System als unplausibel eingestuft wurden, was wiederum einen Neustart zur Folge hatte.

Dies zeigt: Nicht die eigentlich richtig arbeitende Software an sich war das Problem, sondern die falsche Einschätzung der Ingenieure. Verbliebene potentielle Restfehler sind weniger Codierungsfehler (wie vertauschte Vorzeichen oder < und >), sondern sie stammen von grundsätzlichen architektonischen Fehlern sowie falschen und nicht genügend durchdachten Annahmen, denen Entscheidungen des Systems zugrundeliegen.

Testverfahren müssen über den kompletten Entwicklungsprozess hinweg genutzen werden

Diese Tatsache impliziert zwei Hauptansätze zur Qualitätssicherung bei Software:

• Vorbeugende Fehlervermeidung,
• Kontrolle auf implementierte Fehler.

Vorbeugende Fehlervermeidung wird in erster Linie während des Designprozesses eingesetzt. Da bis zu diesem Zeitpunkt nur wenig lauffähiger Code existiert, zielen die Maßnahmen auf Reviews von Dokumenten ab (siehe Beiträge „Statische Softwaretests“, InfoClick am Ende de Beitrags). Reviews und Inspektionen zählen, früh genug im Entwicklungsprozess eingesetzt, zu den effektivsten und gleichzeitig kostengünstigsten Maßnahmen zur Vermeidung von Fehlern. Wenn sie gut durchgeführt werden, ist die effektive Kommunikation (darstellbar als ausgetauschte relevante Informationsmenge pro Zeiteinheit) hoch und ersetzt so manches uneffektive Folgemeeting. Nicht genügend effektive Kommunikation — es kann nicht bestritten werden, dass in vielen Firmen ausgiebig gemeetet wird — ist nach wie vor eine Hauptursache für Fehler aller Art in der Softwareentwicklung.

Sobald lauffähiger Code existiert, muss er unter realen Bedingungen ausgeführt werden und dabei Extremsituationen und allen denkbaren Fehlzuständen und -eingaben unterworfen werden. Dies geschieht durch Verfahren zur Kontrolle auf implementierte Fehler (siehe Beitrag

„Dynamische Softwaretests“, InfoClick). Hierbei werden nicht nur Fehler in der Implementierung an sich (wie vertauschte Vorzeichen, fehlende Initialisierung von Variablen etc.) aufgedeckt, sondern die gesamte Systemarchitektur wird unter realen Bedingungen auf Qualitätsmerkmale wie Angemessenheit, Robustheit, Bedienbarkeit und dergleichen überprüft.

Je nach Art der Software können Tests dieser Art langwierig und kostspielig sein - und werden deshalb aus Zeit- und Kostengründen gerne wegoptimiert, wenn sie denn jemals im Projektplan auftauchten. Selbst wenn das der Fall ist, sind nicht selten nur ein oder zwei Tage für höchst komplexe Softwarestücke vorgesehen - definitiv zu wenig.

Aufwand und Kosten müssen je Projekt abgewogen werden

Testen sollte also ein wohldefinierter Prozess sein, der parallel zur Entwicklung läuft und sie in den einzelnen Projektphasen begleitet. Dies zeigt Bild 2: Am Übergang einer Projektphase zur nächsten verifizieren Reviews die Ergebnisse der abgeschlossenen Projektphase gegenüber der vorangegangenen, ob das Produkt richtig gebaut wird. Beispielsweise wird aus einem rein funktionalen Systementwurf (noch ohne technische Aspekte) in der anschließenden Phase ein technischer Systementwurf gemacht. Beim Abschluss dieser Phase sollte bereits ein ausreichendes Testverfahren eingeplant sein, um zu verifizieren, ob der funktionale Systementwurf korrekt und vollständig in den technischen Systementwurf umgesetzt wurde.

Ist das Projekt soweit gediehen, dass lauffähiger Code vorliegt und er schrittweise zu Teilsystemen und schließlich zum Gesamtsystem integriert werden kann, sollten die Ergebnisse der Codeintegration anhand der entsprechenden Designdokumente validiert werden: Zunächst sollte der Code auf Klassen- und Funktionsebene dynamisch getestet werden, wobei den Tests die Definition der Klasseninterfaces zugrundegelegt werden.

Im nächsten Schritt werden die Klassen zu Modulen zusammengefasst, die sich durch ihre Funktionalität definieren und die in einer Modul- oder Komponentenspezifikation festgelegt wurde. Auf dieser Ebene wird der Schwerpunkt des Tests darauf gelegt, ob das Modul die Aufgabe richtig löst, Grenzwerte einhält, bei Fehleingaben richtig reagiert. Wie es das im einzelnen macht, wurde zuvor im Klassen- (oder Unit-)Test überprüft.

So verschiebt sich bei zunehmender Integration der Module über Teilsysteme hinweg bis zum Gesamtsystem der Blickpunkt der Tests immer mehr auf die Prüfung der Zusammenarbeit der Einheiten untereinander. Im letzten Schritt, dem Abnahmetest, werden die ursprünglich festgelegten Eigenschaften des Produktes als Testziel verwendet.

Es ist klar, dass dieses Vorgehen einiges an Investition verlangt. Wo an Personalkosten nicht (mehr) eingespart werden kann, fallen besonders als überflüssig betrachtete Prüfprozesse dem Rotstift zum Opfer oder werden zusammengelegt, was bei hoher Softwarekomplexität nicht ratsam ist.

Es ist aber auch nicht sinnvoll, exzessiv viele Prüfschritte einzuführen (Bild 3). Die ihnen verbundenen Kosten werden ab einem gewissen Aufwand nicht mehr durch einen Gewinn an reduzierten Fehlerkosten aufgefangen: die Zahl an gefundenen Fehlern nimmt mit gesteigertem Aufwand nicht linear zu, sondern die Kurve flacht sich ab, ebenso die der potentiellen Fehlerkosten.

Optimal ist es daher, einen vertretbaren Grad an Durchtestung und verbleibendem Fehlerrisiko zu erreichen. Dieser Bereich ist in der Praxis schwer zu ermitteln und verlangt eine produktspezifische Risikokostenanalyse. Die Testkosten wiederum hängen sehr stark von der Test-Infrastruktur und dem verfügbaren Wissen um Testprozesse ab. Daneben spielen Kriterien wie Testbarkeit aufgrund der Art des Entwicklungsprozesses, Automatisierbarkeit, Reife der Software eine ausschlaggebende Rolle. Es kann durchaus sinnvoll sein, die Etablierung und Durchführung eines Testprozesses oder Teilen davon als Expertenleistung von außen einzukaufen.

*Dr. rer. nat. Richard H. Kölbl ist für die Firma Mixed Mode tätig. Seine Schwerpunkte sind die Etablierung, Durchführung und Verwaltung von Software-Testprozessen. Kontakt: rko@mixed-mode.de

(ID:253129)