Warum es so viel fehlerhafte Software gibt
Es ist nicht sonderlich schwierig, ein Stück Software zu schreiben, das nahezu fehlerfrei ist. Ein Problem entsteht oft erst, wenn die Software geändert werden soll. Änderungen sind aber bei modernen Softwareprojekten der Normalfall: Häufig verändern sich schon während der Entwicklung die Anforderungen, weil Geschäftsabläufe oder das technische Umfeld sich geändert haben, die Anwender sich Dinge anders überlegt haben oder man Irrtümer bei den ursprünglichen Überlegungen feststellt. Wenn nun die Software entsprechend den neuen Anforderungen geändert wird, geschieht es häufig, dass an ganz unerwarteten Stellen Nebeneffekte auftreten: Die geänderte Stelle funktioniert zwar, aber andere Dinge funktionieren plötzlich nicht mehr. Sie waren in einer Weise von der geänderten Stelle abhängig, die die Entwickler nicht bedacht hatten. Um das zu verhindern, kann man
 

• Abhängigkeiten vermeiden, das gelingt aber niemals vollständig

• nach jeder Änderung testen, ob alles andere noch geht

Das manuelle Testen einer gesamten Anwendung nach dem Ändern einer Kleinigkeit ist aber so mühsam, undankbar und teuer, dass es in den allermeisten Fällen unterbleibt. Es regiert das Prinzip Hoffnung: "Diese kleine Änderung kann eigentlich nichts kaputt gemacht haben." Bei kleinen und unkritischen Softwareprojekten kann dieses Prinzip sogar wirtschaftlich sein: Wenn doch etwas kaputt ging, wird es eben irgendwann gefunden und repariert. Das Prinzip Hoffnung ist aber nicht zu empfehlen für
 

• kritische Projekte, bei denen Fehler schwere Folgen hätten

• große und komplexe Projekte: Hier geschieht es schnell, dass die Reparatur eines Fehlers eine Kette von neuen Problemen auslöst und der Zustand der Software irgendwann nicht mehr beherrschbar ist.
   

Hier benötigt man die Sicherheit, dass die Software funktioniert. Wenn sie es nicht tut, will man das zumindest sehr schnell und ohne viel Aufwand merken.
 

Hoffnung ist gut, Kontrolle ist besser: Automatische Regressionstests
Ein gut geeignetes Instrument der Qualitätssicherung sind so genannte automatische Regressionstests. Diese Tests werden einmal geschrieben und können dann per Knopfdruck beliebig häufig gestartet werden oder auch automatisch laufen, z.B. jede Nacht. Sie testen, ob alle Funktionalitäten der Software noch genauso funktionieren wir anfangs definiert. Jeder Entwickler führt nach Durchführung einer Änderung die Tests aus: Wenn seine Änderung bestehende Funktionalitäten in Mitleidenschaft gezogen hat, wird das sofort sichtbar. Dann kann er das Programm korrigieren, bis wieder alle Tests fehlerfrei durchlaufen. Die Änderung hat bewirkt, dass ein Test fehlschlägt: der Entwickler weiß nun genau, welche Stelle er korrigieren muss

Unit-Tests
Eine Sorte automatischer Regressionstests sind "Unit-Tests", die jeweils eine Unit (ein Programmmodul) testen, meistens geht es hier um Geschäftslogik. Wenn man z.B. eine Funktion testet, die für eine Bestellmenge einen Rabatt berechnet, definiert man alle möglichen Fälle, z.B.:

• die Bestellmenge ist so groß, dass es den maximalen Rabatt gibt

• die Bestellmenge ist so klein, dass es keinen Rabatt gibt

• die Bestellmenge ist 0

• usw.

Für alle Fälle schreibt man einen Test, der prüft, ob die Funktion den richtigen Rabatt ausrechnet.

GUI-Tests
Eine zweite Sorte automatischer Regressionstests sind "GUI-Tests", die das Graphical User Interface (GUI), d.h. die Benutzeroberfläche der Anwendung testen. Diese Tests simulieren einen Benutzer, der sich durch die Anwendung klickt und Eingaben macht. Diese Tests prüfen, ob nach einem Klick das Erwartete geschieht, z.B. sich ein bestimmtes Fenster öffnet und ein bestimmter Wert angezeigt wird. Sie ergänzen die Unit-Tests sinnvoll. Die GUI-Tests werden nach der Entwicklung der Oberfläche geschrieben, können ebenfalls automatisch oder manuell jederzeit gestartet werden.
 

Qualitätssicherung in der Softwareentwicklung bei BITS
Unser Standard
Wir setzen bei den meisten unserer Projekte Unit-Tests und GUI-Tests ein. Das Verfahren hat sich bewährt und gewährleistet (zusammen mit verschiedenen anderen Maßnahmen) eine hohe Qualität unserer Software. Völlig fehlerfrei ist Software trotzdem niemals, da es nahezu unmöglich ist, eine Testabdeckung von 100% zu erreichen, d.h. wirklich jeden existierenden Fall in jeder Kombination mit den Tests zu erfassen, aber die Fehlerquote wird sehr gering, die verbleibenden Fehler werden, wenn sie denn relevant sind bei manuellen Tests gefunden und können schnell beseitigt werden. Unsere weiteren Qualitätssicherungsmaßnahmen sind
 

• Kodierrichtlinien: wir haben auf langjähriger Erfahrung basierende ausführliche Kodierrichtlinien, die z.B. Regeln enthalten zur Programmstruktur, Benennungsschemata, Kommentierstrategien usw. Durch Einhaltung dieser Regeln sichern wir die Qualität und vereinfachen die Wartung von Projekten.

• Pair programming bzw. Code Revision: wichtige Code-Bestandteile werden zu zweit programmiert oder von einer zweiten Person durchgesehen.

• Manuelle gegenseitige Tests: Die Programmierer testen gegenseitig die entwickelten Funktionalitäten, weil man erfahrungsgemäß seine eigenen Fehler schlechter findet als ein anderer das tut.

• Häufige Auslieferungen ("Short Releases") mit Akzeptanztests durch den Kunden: schließlich liefern wir die Software frühzeitig und regelmäßig an Sie aus, sodass Sie die neuen Funktionalitäten selbst ausprobieren können. Auf diese Weise werden aufgedeckt:

  • Probleme, die mit der Systemumgebung zusammenhängen

  • Missverständnisse bei der Definition von Funktionalitäten

  • Optimierungsmöglichkeiten bei der Bedienung

• Schnelle Behandlung von Problemen: Wenn Sie tatsächlich Probleme feststellen, können wir diese auf Basis der Regressionstests und der Short Releases schnell beseitigen.

Sie bestimmen, was Sie benötigen
Das Schreiben der Tests benötigt natürlich Zeit und verursacht Kosten. Nach unserer Erfahrung amortisiert sich das in den meisten Fällen schnell, denn bei einem Verzicht auf die Tests ist die Entwicklung zwar anfänglich günstiger, dafür werden Änderungen schnell unverhältnismäßig teuer (oder wahlweise: die Qualität der Software nimmt ab).