Anleitung für professionelles Software-Testmanagement

Know-how  –  Kommentare
Anzeige
aufmacher_ajax.jpg

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.

Anzeige