07. März 2019
„Wir sind fast fertig. Wir müssen es nur noch testen.“
Diesen Satz, den man häufiger in Projekten hört als einem lieb sein kann, lässt im Allgemeinen Schlimmes erahnen. Noch immer ist es so, dass in vielen Projekten das Thema Testing keinen besonders hohen Stellenwert hat. Und auch kein direkter Bezug zur Entwicklung der Software selber hergestellt wird. Im Gegenteil. Von vielen Bereichen innerhalb eines Projektes wird dieser Teil der Qualitätssicherung als Störung oder gar als Behinderung empfunden. Ganz so, als ob es die Schuld eines Testers sei, einen Fehler in der entwickelten Software zu finden.
Testing ist für viele Projekte immer noch etwas, was man „halt machen muss“ und wird nicht in seiner wichtigsten Funktion wahrgenommen. Testing ist die Sensorik innerhalb eines Projekts. Lediglich anhand der Daten, die sich aus den erstellten Testergebnissen ergeben, ist es einer Projektleitung möglich nachzuvollziehen, in welchem Zustand sich die zu erstellende Software tatsächlich befindet. Ob sie auch tatsächlich innerhalb der definierten Parameter arbeitet und die gewünschten Funktionalitäten zu Verfügung stellt. Und je genauer und definierter diese Daten sind, desto konkretere Schlussfolgerungen lassen sich daraus ziehen.
Und das kann auch nur dann gewährleistet werden, wenn das Testing in den Prozess integriert worden ist, die gelieferten Daten ausgewertet werden und entsprechend der gewonnenen Erkenntnisse gehandelt wird. – Man sich also der Bedeutung des Testings bewusst ist und seine Möglichkeiten nutzt.
Testing besteht nicht nur aus dem reinen Durchführen von Tests (worunter meistens ein wenig exploratives Testing verstanden wird). Es handelt sich natürlich auch um die Erstellung und Vorbereitung der Testfälle, das Bereitstellen der Testdaten, die Dokumentation der Ergebnisse zum Zwecke der Historisierung, das Erstellen der Fehler und die Rückverfolgbarkeit zu den Anforderungen, usw.
All diese Dinge sind notwendig, um die Übersicht innerhalb eines Projekts zu erhalten und Schlussfolgerungen ziehen zu können. Als Beispiel kann ein standardisierter Regressionstest dienen, der nach jeder Lieferung einer neuen Version der Software auf einer Testumgebung durchgeführt wird. Dieser Regressionstest kann natürlich nur dann korrekte und für die Projektleitung verwertbare Ergebnisse liefern, wenn sichergestellt ist, dass die durchgeführten Testfälle die entwickelten Funktionalitäten in genügendem Maße (Positiv- und Negativtestfälle) abdecken, die Testdaten standardisiert und für jeden Testlauf wiederherstellbar sind, die Testumgebung stabil ist und der Produktivumgebung entspricht und dass es einen Prozess zur Sicherung der Qualität bestehender und neuerstellter Testfälle gibt. Ohne diese konkreten Vorgaben ist eine seriöse Einschätzung von Risiken der Produktivsetzung neuentwickelter Software durch die Projektleitung oder den Fachbereich nicht möglich. Jede Live-Setzung eines Softwareprodukts würde zu einem unkalkulierbaren Risiko.
Es wäre aber weit gefehlt anzunehmen, dass wirkliches Qualitätsmanagement nur durch Testing zu erreichen ist. Testing ist, wie gesagt, die Sensorik innerhalb eines Projekts und kann Schwachstellen aufzeigen. Aber sie ist nicht der einzige Baustein. Und sie kann ihre Aufgabe auch nur im Verbund und als Teil eines übergreifenden Qualitätsmanagements erfüllen.
Haben Sie Fragen zu dem Thema oder sind Sie an einer Unterstützung in diesem Bereich interessiert?
