Anleitung für professionelles Software-Testmanagement

Viele Unternehmen kämpfen mit fehlerhafter Softwarearchitektur, was überschrittene Budgets oder nicht eingehaltene Projektlaufzeiten nach sich zieht. Ein Testmanagement kann Abhilfe schaffen.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 13 Min.
Von
  • Volker Maiborn
  • Alexander Neumann
Inhaltsverzeichnis

Obwohl Software in zahlreichen unternehmenskritischen Bereichen zu finden ist, kämpfen viele Unternehmen mit fehlerhafter Softwarearchitektur, was überschrittene Budgets oder nicht eingehaltene Projektlaufzeiten nach sich ziehen kann. Ein Testmanagement kann Abhilfe schaffen. Seine Umsetzung in Unternehmen ist aber immer noch vergleichsweise schwierig, weil in IT-Abteilungen oft Unklarheit darüber herrscht, wie sie ein solches wirkungsvoll aufsetzen.

Der Artikel stellt ein Testmanagementmodell über einen exemplarischen Testprozess vor und geht systematisch die einzelnen Prozessschritte durch, angefangen bei der Beauftragung über den Entwurf und das Datenmanagement bis hin zur Durchführung sowie dem Testende. Ein Testmanagement zu installieren ist keine triviale Angelegenheit, und das Testen von Software birgt zahlreiche Stolpersteine.

Prinzipiell lassen sich drei Zielgruppen eines Testmanagements unterscheiden. Zum einen möchte das beauftragende Unternehmen durch ein Testmanagement sicherstellen, dass eine unternehmenskritische Software reibungslos und ausfallfrei läuft. Daneben hat die Entwicklungsabteilung eine funktionsfähige Software auszuliefern. Schließlich haben Unternehmen, die Software entwickeln, ein Interesse daran, da sie mit einem unabhängigen Testbereich die Möglichkeit haben, Synergien im Testmanagement zu nutzen.

Der erste Fehler, den Unternehmen im Testmanagement machen können, ist der vollständige Verzicht auf ein solches. Doch auch Unternehmen, die sich mit dem Thema befassen, lassen nicht selten eine methodische Planung und Durchführung vermissen. In vielen Fällen denkt sich der verantwortliche Projektleiter am Ende des Projekts einige Testfälle aus und begutachtet stichprobenartig, ohne einen systematischen Ansatz, einige Funktionen der Software. Er findet dann meist zu viele Fehler, um sie rechtzeitig zu korrigieren und das Projekt noch innerhalb der geplanten Laufzeit zu realisieren. Obwohl er die Software längst eingeführt haben sollte, sind nun noch Fehleranalysen und -korrekturen durchzuführen, und das mit mehr Aufwand als ursprünglich geplant.

Zudem bleibt meist keine Zeit mehr, die Nachbesserungen erneut zu testen, sodass sich das Risiko ergibt, die Software mit noch bestehenden oder unentdeckten Fehlern einzuführen. Eine andere Beobachtung zeigt, dass Unternehmen nur das Thema Test auf ihre Liste setzen, nicht aber die Korrektur. Eine Verlängerung der Projektlaufzeit, die die Planung von Tests und Korrekturen für das Ende der Entwicklungszeit nach sich ziehen würde, umgeht man, indem man, wie im V-Modell festgelegt, das Testmanagement von Anfang an in den Entwicklungsprozess integriert.

Auch wenn Unternehmen die Bedeutung des Testmanagements erkannt haben, machen sie sich häufig zu spät Gedanken über bereitzustellende Testdaten. Das führt bei der Durchführung dazu, dass man auf keinen Datenbestand zurückgreifen kann. Dadurch stehen für die durchzuführenden Testfälle nicht die richtigen Daten, die während der Projektlaufzeit nicht mehr bereitzustellen sind, zur Verfügung. Während der gesamten Projektphase sind deshalb für das Testdatenmanagement Ressourcen einzuplanen.

Oft missachten Unternehmen die Bedeutung einer Testautomatisierung. Bei ihr unterscheidet man zwischen der codenahen und der GUI-Testautomatisierung. Fehler in Unternehmen sind, entweder keine codenahe durchzuführen oder zu früh mit der GUI-Testautomatisierung zu beginnen. Führt man Erstere nicht durch, ist eine preiswerte Option verschenkt, zeitig die Qualität des Systems festzustellen. Bei einer zu früh eingesetzten GUI-Testautomatisierung tauchen im Laufe des Projekts meist noch viele Änderungen auf, sodass die Kosten durch den hohen Wartungsaufwand schnell in die Höhe gehen können. Deshalb ist eine codenahe Testautomatisierung früh einzusetzen und die für GUIs erst zum Ende eines Projekts durchzuführen. Denn Letztere kann ihr volles Potenzial erst entfalten, wenn sich ein Großteil der bestehenden Funktionen mit einer daraufhin erstellten Automatisierung kostengünstig in Form von Regressionstests prüfen lässt.

Darüber hinaus unterschätzen Unternehmen nicht selten das Know-how, das für strukturiertes Testmanagement von Nöten ist. Hierfür gibt es eine einfache Regel: Entwickler sollten die von ihnen entwickelte Software nicht selbst testen – zumindest nicht das, was über die Modultests der eigenen Codezeilen hinausgeht. Zum einen mag es sein, das ihnen die Kenntniss fehlen, um effektiv zu testen, zum anderen verfügen sie über keinen objektiven Blick auf die eigene Software. Meist erliegen sie der Versuchung, nur die Funktionen zu überprüfen, für die sie das Produkt entwickelt haben – nicht aber zum Beispiel sogenannte Negativfälle, bei denen ein Anwender falsche, nicht nachvollziehbare Eingaben durchführt. Dass Testen die einfachere Aufgabe ist, die ein Entwickler "mit links miterledigt", kann sich als Trugschluss erweisen, denn sowohl die Kodierung als auch das Testen sind komplexe Unterfangen. Die Anforderungen an Tester sind daher genauso hoch wie die an Entwickler.

Im Unternehmen ist deshalb eine von der Entwicklung unabhängige Testabteilung aufzubauen. Dort sollten nur ausgebildete Mitarbeiter sauber ermittelte Testfälle durchführen. Manchmal neigen Tester dazu, intuitiv zu handeln, vor allem wenn man sie interimsweise aus der Fachabteilung rekrutiert hat. Instinktiv versuchen sie, die richtigen Testfälle zu ermitteln, und liegen häufig sogar richtig. Doch jeder Verzicht auf methodisches Vorgehen führt dazu, dass Entwickler Testfälle übergehen oder nicht die richtigen finden. Das Wissen um methodisches Vorgehen sollte man nicht nur intern kommunizieren, sondern auch in internationalen Standards wie denen des International Software Testing Qualifications Board (ISTQB) einbringen. Das Gremium hat zum Ziel, Standards im Testmanagement und Testing zu erforschen und zu operationalisieren.

Beim V-Modell findet der Test parallel zur Entwicklung statt (Abb. 1).

Ein effektives Testmanagement beginnt mit der richtigen Beauftragungsform. Sie bestimmt, wie der für das Projekt verantwortliche Fachbereich die Softwareentwicklung und das Testmanagement organisiert. Dabei ist die Unabhängigkeit der Beauftragung wichtig. Das tritt ein, wenn die verantwortliche Fachabteilung das Testmanagement unabhängig von der Softwareentwicklung einfordert. Ein derartiges Vorgehen stellt sicher, dass das Testmanagement ein eigenes, festes Budget vom Fachbereich und nicht von der Softwareentwicklung zugeteilt bekommt. Sie sorgt dafür, dass die Mittel tatsächlich in vollem Umfang in das Testmanagement fließen, und verhindert, dass die Entwicklung bei Bedarf Teile des Budgets für sich beansprucht. Sie gewährleistet darüber hinaus, dass alle Teststufen sich unabhängig und parallel zur Entwicklung, wie im V-Modell abgebildet, durchlaufen lassen. Eine unabhängige Beauftragung ist die Voraussetzung für die weiteren Schritte des Testmanagements.

Äquivalenzklassen sind Gruppen von Eingaben, bei denen das gleiche Ergebnis zu erwarten ist. Der Einsatz der Methode unterstützt eine strukturierte Testfallermittlung (Abb. 2).

Zu den ersten Aufgaben nach der Planung gehört der Testentwurf. Da das Testmanagement bei jedem Kunden unterschiedliche Anforderungen vorfindet, sind zunächst die geeigneten Testfallermittlungsmethoden auszuwählen, um idealerweise eine nahezu vollständige Testabdeckung zu erreichen. Anders als beispielsweise in der Physik, die sich mit stetigen Funktionen beschreiben lässt, bewegt man sich im Bereich Software in einer diskreten Welt. Das bedeutet, dass man für eine vollständige Testabdeckung eine gegen unendlich strebende Anzahl an Testfällen benötigen würde. Durch die abzählbare Anzahl an zeitlichen und menschlichen Ressourcen ist es unabdingbar, die Menge an Testfällen auf ein realisierbares Maß zu reduzieren. Selbst scheinbar einfach aussehende Eingabemasken weisen eine gewisse Komplexität auf und enthalten, wie Abbildung 2 zeigt, immer noch eine hohe Anzahl an Eingabekombinationen und somit Testfällen.

Die unterschiedlichsten Testfallermittlungsmethoden lassen sich je nach Projekt von erfahrenen Testmanagern einsetzen (Abb. 3).

Um dennoch eine gute Testabdeckung zu erreichen, greift das Testmanagement auf Methoden zurück, die bei geeigneter Auswahl und intelligenter Kombination zu einem guten Ergebnis kommen. Das erreicht man beispielsweise dadurch, dass man für kritische Teile Softwaremethoden nutzt, die zwar umfangreich sind, dafür eine größere Zahl an Testfällen ermitteln. Durch die Systematik lässt sich eine hohe Testabdeckung erreichen. Für unkritischere Teile greift man hingegen auf weniger komplexe Methoden zurück. Abbildung 3 geht kurz auf die unterschiedlichen Methoden ein, die dem Testmanager zur Verfügung stehen.

Mit der Testfallermittlung spezifiziert man die Testdaten. Die Spezifikation stellt für alle Fälle einen definierten initialen Datenbestand her. Um schließlich zu nachvollziehbaren und reproduzierbaren Testfällen zu gelangen, benötigt man ein strukturiertes Datenmanagement. Es stellt sicher, dass nach jedem Durchlauf, der mit gleichen Werten durchzuführen ist, sich der Initialzustand wieder herstellen lässt. Ausgehend davon ist ein weiterer Testlauf zu starten; zum Beispiel, wenn das Testmanagement bei einem vorhergehenden Durchlauf einen Fehler gefunden hat, den im Anschluss die Entwicklung beseitigt hat. Um nun zu überprüfen, ob die Software nach Beseitigung des konkreten Fehlers tatsächlich verbessert wurde, ist der Initialzustand zu verwenden.

In dem Zusammenhang soll man zwischen Primär- und Sekundärtestdaten unterscheiden. Beide Datentypen sind von Bedeutung, um zu einem reproduzierbaren Ergebnis zu kommen. Das Testdatenmanagement spielt die Primärtestdaten in das System ein und verwaltet sie. Ein systematisches Datenmanagement unterstützt das Testmanagement, indem es die geeigneten Testdaten zur Verfügung stellt, auch wenn durch iterative Ansätze die Komplexität des Systems zunimmt. Den Punkt unterschätzen viele in der Praxis.

Automatisierte Tests können, richtig eingesetzt, den Aufwand reduzieren. Im ersten Schritt entscheidet das Testmanagement darüber, welche konkrete Methode im vorliegenden Fall Sinn macht. Bei der Entwicklung kleinerer Softwarepakete für interne Unternehmensanwendungen, die in der Zukunft keinen großen Änderungen unterworfen sind ,ist keine Testautomatisierung von Nöten.

Neben ihr spielen statische Software-Testverfahren eine wichtige Rolle. Mit ihnen findet man Hinweise auf Schwachstellen im Programmcode. Durch bestimmte Metriken lassen sich komplexe Teile einer Software identifizieren. Wichtig sind die zyklomatische Komplexität, die Halstead-Metrik, die Datenfluss-Anomalie sowie die Kontrollfluss-Anomalie (siehe [anchorlink l1]Glossar[/anchorlink]). Generell sind besonders komplexe Teile der Software mit einer höheren Wahrscheinlichkeit fehlerbehaftet.

Während der Test- und Fehlerkorrekturphase sollten nach und nach immer weniger Fehler in der Software zu finden sein, sodass sich eine Sättigungskurve ergibt (Abb. 4).

Ein vollständiger Nachweis an Fehlerfreiheit von Software ist nicht realisierbar. In Abhängigkeit der Schadenswahrscheinlichkeit und -höhe lässt sich ein unterschiedlich hoher ökonomischer Aufwand betreiben, um das Testendekriterium zu erreichen. Das legt man zu Beginn des Testmanagement-Prozesses fest. Dadurch lässt sich sicherstellen, dass alle Vertragsparteien das Testendekriterium einhalten und die Software einen gewissen Qualitätsstandard erreicht, bevor man sie ausliefert. Geeignete Endekriterien sind beispielsweise die Fehlersättigungskurve oder Fehlererwartungsmodelle.

Darüber hinaus stehen dem Testmanagement Modelle zur Verfügung, mit denen sich Fehlererwartungswerte berechnen lassen. Daraus kann man Rückschlüsse auf die erwartete Zahl an Restfehlern ziehen. Stimmt der Wert schließlich mit der Fehlersättigungskurve überein, ist das ein geeignetes Testendekriterium. Falls eine Berechnung der Fehlererwartungswerte nicht möglich ist, kann man alternativ zwischen der Schwere unterschiedlicher Fehler unterscheiden und sie beispielsweise den Kategorien erheblich, dringend, normaler und Schönheitsfehler zuweisen. Ein Endekriterium wäre, dass das Testmanagement beendet ist, sobald keine erheblichen und dringenden Fehler mehr auftreten. Das ist aber kein alleiniges Kriterium, denn es kann sein, dass man nach dem Testen der ersten Hälfte keine schweren Fehler gefunden hat, sie jedoch in der zweiten Hälfte noch bestehen. Deshalb ist es nur im Zusammenhang mit anderen wie einer hundertprozentigen Testdurchführung oder einer hohen Testfallabdeckung einzubringen. Auch Zeit und Geld sind keine empfehlenswerten Endekriterien. Für den Fall, dass das verfügbare Budget aufgebraucht ist und man kurz zuvor einen schwerwiegenden Softwarefehler gefunden hat, ist das Testmanagement noch nicht zu beenden. Grundsätzlich hängt die Wahl des Endekriteriums davon ab, was sich mit dem Fachbereich vereinbaren lässt. Es ist jedoch Aufgabe des Testmanagements, auf Risiken hinzuweisen, die durch das kundenspezifische System entstehen können.

Um den hohen Anforderungen an eine Software in komplexen und unternehmenskritischen Bereichen gerecht zu werden, ist ein Testen in jeder Entwicklungsstufe einer Software nicht mehr wegzudenken. Mit einem strukturierten Test-Management und den richtigen Methoden sowie qualifizierten Testern und Testmanagern sind Unternehmen allerdings den Anforderungen gewachsen.

Volker Maiborn
ist Geschäftsführer von beck et al. projects und verantwortet zusätzlich den Unternehmensbereich "Testmanagement". Maiborn blickt auf 20 Jahre Erfahrung in der IT-Branche zurück und hat als Projektleiter zahlreiche große Industrie- und Handelskunden betreut.

Zyklomatische Komplexität: Nach McCabe misst sie die strukturelle Komplexität eines Quellcodes. Grundlage für die Berechnung der zyklomatischen Zahl ist der Kontrollflussgraph des Programmstücks, dessen Komplexität zu ermitteln ist.

Halstead-Metrik: Auch sie misst die Komplexität eines Programms. Es sind zunächst die Vokabulargröße und die Implementierungslänge zu ermitteln, woraus sich wiederum weitere Kennzahlen wie die Schwierigkeitsstufe für eine Person, ein Programmfragment zu verstehen, kalkulieren lassen.

Datenflussanomalie: Sie untersucht die Verwendung von Daten auf Pfaden durch den Programmcode. Solche Anomalien sind beispielsweise das referenzierende Verwenden einer Variablen ohne vorheriges Initialisieren oder Nichtverwenden eines Wertes einer Variablen.

Kontrollflussanomalie: Mit ihr bezeichnet man Unstimmigkeiten im Ablauf von Programmstücken wie Sprünge aus Schleifen oder mehrere Ausgänge aus einem Programmstück. Die Anomalien müssen keine Fehlerzustände sein, entsprechen aber nicht der strukturierten Programmierung. (ane)