Jedes Testhandbuch und jeder Leitfaden für das Testen von Software enthalten den Satz: Es kann gar nicht genug getestet werden. Leider ist dies ein schlechter Ratgeber in einer Situation, in der Kosten und Zeit die zentrale Rolle bei der Erstellung und beim Unterhalt von Softwaresystemen spielen. Deshalb empfiehlt sich ein pragmatisches Vorgehen, das sechs wichtige Instrumente beinhaltet: Entwicklungsrichtlinien zur Fehlervermeidung, die unterschätzten Reviews, eine Änderung der Unit-Test-Praxis, der kluge Einsatz automatisierter Test-Tools, der Ausbau von Tracing und Logging und die vollständig getrennte Prüfung der Datenqualität.
Richtlinien zur Fehlervermeidung: Jede Individualentwicklung sollte auf Richtlinien zur Vermeidung von Softwarefehlern beruhen. Eine wesentliche Voraussetzung ist das Vorhandensein und die Anwendung so genannter Code-Conventions. Dabei schadet es überhaupt nicht, diese Richtlinien für ein Unternehmen in Zusammenarbeit mit dem Fachpersonal festzulegen. Der Aufwand hält sich in Grenzen, die disziplinierte Umsetzung ist dann jedoch wesentlich einfacher. "Design for Performance" und "Defensive Programming" sind Prinzipien, die in solche Unternehmensrichtlinien gehören.
Reviews: Reviews und im Speziellen Peer Reviews und formale Reviews sind das beste Mittel, um Fehler zu finden. In Kombination mit einer klugen Auswahl kritischer Module, Klassen, Komponenten oder Services sind sie ein wirkungsvolles Mittel, um die Qualität eines Systems zu verbessern. Allerdings setzen sie ein bestimmtes Betriebsklima voraus, welches gegenseitige Anschuldigungen und Besserwisserei vermeidet, dafür die gegenseitige Akzeptanz fördert.
Unit-Tests: Die heutige Praxis des Unit-Tests dient lediglich dazu, den Normalfall zu testen. Dieselbe Person, die den Code produziert, erzeugt auch die Unit-Tests. Dieser Zustand muss verändert werden. Die Unit-Tests einer Klasse sollten gerade nicht von derjenigen Person entwickelt werden, die die Klasse realisiert. Denn wer testet sich schon gern selbst? Zudem sind Unit-Tests dann sinnvoll, wenn sie so aufgebaut sind, dass sie im Rahmen der nachfolgenden System- und Integrationstests weiterverwendet werden können. Sie sollten also auf jeden Fall von außen ansteuerbar sein.
Automatisierte Test-Tools: Der Einsatz automatisierter Test-Tools, die über die reine Testverwaltung hinausgehen, ist in der Individualentwicklung nur bei großen Systemen zu evaluieren. Die Verwendung von GUI-Testern ist selten für Unternehmensanwendungen sinnvoll, da die Erstellung guter Testskripts genauso komplex ist wie die Entwicklung des GUI. Gute systemübergreifende End-to-End-Test-Suiten sind noch in den Kinderschuhen und werden sich erst im Laufe der nächsten Jahre in der Individualentwicklung durchsetzen. Auch unterschätzen nach wie vor viele Unternehmen die Problematik der Bereitstellung und Reproduktion realitätsnaher Testdaten.
Tracing und Logging: Die durchschnittliche Lebenszeit einer Anwendung in einem Unternehmen liegt bei zwölf bis 15 Jahren. Während dieser Zeit verändert sich das Umfeld der Anwendung stark. Der Betrieb und Unterhalt von Programmen und im Speziellen die Fehlersuche werden kräftig vereinfacht, wenn Tracing- und Logging-Fähigkeiten zur Verfügung stehen und die Software diese Mechanismen auch zulässt. So sollten beispielsweise Tracing- und Logging-Levels zur Laufzeit geändert werden können. Davon sind die meisten Individualsysteme weit entfernt. Der zusätzliche Aufwand zur Entwicklungszeit hält sich jedoch in Grenzen, sofern ein unternehmensweites Konzept zur Verfügung steht.
Getrennte Prüfung: Die durchschnittliche Lebenszeit von Daten in einem Unternehmen beträgt 20 bis 30 Jahre. Daten leben also im Schnitt bedeutend länger als Anwendungen. Schon allein aus diesem Grunde sollte die Qualität von Daten getrennt von der Qualität der Anwendungen geprüft werden. Mehr und mehr Unternehmen realisieren im Rahmen von IT-Governance-Projekten nicht nur Sicherheits- und Projekt-Management-Richtlinien, sondern auch Policies zur Umsetzung von Data-Quality-Management (DQM).
