Tests sind elementarer Bestandteil von IT-Projekten, wobei der Begriff "IT-Projekt" weit gefasst ist. Er umfasst die typische Software-Entwicklung ebenso wie Implementierungen, z.B. die Einführung von Standardsoftware wie SAP, Rollouts, Migrationen sowie Infrastrukturprojekte, wie z.B. den Aufbau von Netzen oder Rechenzentren. Jedes IT- Unternehmen oder jede IT-Abteilung sollte für das Testen eine etablierte Testumgebung und -vorgehensweise haben. Auch wenn sich IT-Projekte in ihrer Ausprägung stark unterscheiden können, so lassen sich die Grundzüge des Testens auf alle anwenden, ggf. sind sie fallweise anzupassen.

In der Realität allerdings wird das Testmanagement meist für jedes Projekt neu aufgesetzt. Entweder, weil das Projekt besonders neuartig bzw. komplex ist oder weil die beteiligten Parteien im Projekt vorher noch nie zusammengearbeitet haben, wie z.B. ein externer IT-Spezialist und die vom Projekt betroffenen Fachabteilungen. In diesen Fällen müssen die Testorganisation und die Abläufe neu gestaltet oder angepasst werden.

Um dieses Problem in den Griff zu bekommen, investieren manche IT-Unternehmen in kostspielige Software zur Überwachung und Verwaltung von Tests. Allerdings schießen sie damit meist über das Ziel hinaus, da diese Werkzeuge selbst sehr komplex sind und häufig nur rudimentär genutzt werden. Andere Testverantwortliche fangen jedesmal von vorne an und erfinden das Rad gewissermaßen neu. Sie improvisieren oder erstellen eine eigene Systematik.

Die Lösung dieses Dilemmas zwischen dem Wunsch nach einem standardisierten Vorgehen und den individuellen Anforderungen eines bestimmten Projekts liegt meiner Meinung nach darin, nur die Grundzüge des Testmanagements festzulegen. Man benötigt Regeln, die helfen, den konkreten Testablauf festzulegen. Dieses Vorgehen gewährleistet einerseits einen verlässlichen Rahmen, der für alle Projekte identisch gilt. Andererseits bietet es die Flexibilität, das Vorgehen beim Testen schnell auf die projektspezifischen Bedürfnisse anzupassen.

Im ersten Teil  dieses Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind.

Der zweite Teil stellt eine einfache, praxiserprobte Lösung für ein Testwerkzeug auf Basis von Microsoft-Excel vor, das in ähnlicher Form bereits in zahlreichen Projekten erfolgreich eingesetzt wurde.

Warum überhaupt testen?

Testen ist ein Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden. Jede Abweichung zwischen dem Ergebnis des Programms und dem laut Spezifikation vorgegebenen korrekten Wert wird als Fehler bezeichnet (Myers; Sandler, 2004). Es gibt zwei Gründe, um nach Fehlern einer Software zu suchen, die analog auch für Tests in anderen IT-Projekten gelten:

1. Qualitätssicherung und Unterstützung der Entwickler

Tests während der Realisierung oder Umsetzung sollen die Anzahl der Fehler möglichst gering halten und dafür sorgen, dass die Entwickler bereits während des Projekts aus erkannten Fehlern lernen können. Testen ist deshalb weit mehr als eine lästige Aufgabe, die man an einen Qualitätsmanager delegieren kann. Im Entwicklungszyklus einer IT-Lösung muss die Qualitätssicherung in den Projektablauf eingebettet sein und darf sich nicht nur auf eine Testphase zum Projektabschluss beschränken.

2. Abnahme der IT-Lösung

Mit der Abnahme bestätigt der Auftraggeber, dass seine Anforderungen erfüllt sind, die in Projektauftrag bzw. Lastenheft oder Kundenspezifikation beschrieben sind. Die Abnahme ist Voraussetzung für den Projektabschluss. Sie hat darüber hinaus rechtliche Auswirkungen, z.B. für Rechnungsstellung oder Gewährleistung. Grundlage der Abnahme ist der Abnahmetest, der überprüft, ob alle Abnahmekriterien erfüllt sind. Wichtig ist, dass die Abnahmekriterien frühzeitig definiert werden und allen Beteiligten bekannt sind.

Bei IT-Projekten verbindet das Testen somit die wertschöpfenden Projektprozesse (d.h. die Erstellung) und die Projektmanagement-Prozesse, z.B. des Qualitätsmanagements und der Abnahme. Zum einen müssen die Testprozesse deshalb in den Plan des jeweiligen Projekts integriert werden, zum anderen muss eine Testorganisation eingerichtet werden, die Test- und Managementprozesse aufeinander abstimmt.

Grundsätze für Software-Tests

Das International Software Testing Qualifications Board benennt sieben Grundsätze für Software-Tests, die sich auch auf andere IT-Projekte übertragen lassen (ISTQB, 2005):

1. Mit Tests können Fehler nachgewiesen werden.
2. Vollständiges Testen ist nicht möglich.
3. Mit dem Testen sollte frühzeitig begonnen werden.
4. Fehler treten in der Regel nicht gleichmäßig verteilt über alle Komponenten auf. Viel wahrscheinlicher ist die Häufung von Fehlern in einzelnen Komponenten. Für das Testen heißt das, dass flexibel auf solche erkannten Häufungen eingegangen werden muss.
5. Wiederholungen der immer gleichen Testfälle führen zu keinen neuen Ergebnissen.
6. Testen ist abhängig vom Umfeld, also z.B. von der spezifischen Architektur, dem Einsatzzweck und der Anwenderzahl.