Umfeld des Testmanagements

Das Testmanagement hat Schnittstellen zu anderen Prozessen im Unternehmen. Diese sind beim Prozessdesign zu berücksichtigen, um klare Schnittstellen und ein gemeinsames Verständnis der Zuständigkeit zu erreichen.

Entwicklungsmethode

Viele Unternehmen setzten zurecht auf eine Entwicklungsmethode in der Softwareentwicklung. Dabei werden klassische Modelle (Wasserfall, Iterativ, Mischmodelle) oder agile Modelle (beispielsweise SCRUM) eingesetzt. Da die Softwareentwicklung das Testobjekt bestimmt (also die zu testende Software), gibt es ganz natürliche Schnittstellen zwischen Testmanagement und Entwicklung, etwa bei der Übergabe der Software (Dev-to-Test oder Dev-to-Prod). Außerdem greifen sowohl Test als auch Entwicklung auf dieselben Analysedokumente (Fachkonzept, Lastenheft, etc.) zu, um ihre jeweiligen Designaktivitäten durchzuführen. Hieraus ergeben sich natürliche Synergien in der Qualitätssicherung der Eingangsdokumente. Im späteren Testprozess gibt es dann Interaktion bezüglich der Abweichungsverfolgung zwischen Entwicklung und Test.

IT-Betrieb (Service Management)

IT Service Management (ITSM) hat kaum Schnittstellen zum Testmanagement. Jedoch definieren manche ITSM-Methoden die Notwendigkeit die Korrektheit und Funktionsfähigkeit von Änderungen am Produktivsystem nachzuweisen.
Durch die hohe Akzeptanz von durchschnittlichen Betriebsprozessen (sog. best practices) entsteht manchmal der Eindruck, dass ein hohes Maß an Standardisierung allgemein eine gute Idee sei. Wichtig für die Inbetriebnahme der Software ist in der Regel die erklärte Abnahme des Hauptnutzers, sowie der Nachweis der erbrachten Testfälle.

Anforderungsmanagement

Das Anforderungsmanagement konsolidiert die Anforderungen, welche in einem Unternehmen (oder Projekt) anfallen und ist damit die primäre Quelle für Entwicklung und Test. Der Schnittstelle Anforderungsmanagement und Testmanagement kommt eine besondere Bedeutung zu. Man geht teilweise sogar dazu über, die Datenbanken von Anforderungsmanagement und Testmanagement zusammenzuführen. Der Vorschlag zur Toolkonfiguration weiter unten berücksichtigt diese Sichtweise.

Fachliche Einbindung zum Projektstart

Die engsten Verbindungen hat das Testmanagement sicher zum Projektmanagement. Sie werden sehen, dass wir uns auf den Standpunkt stellen, dass Testmanagement eine spezialisierte Version des Projektmanagements ist.
Daher ist es unbedingt erforderlich, dass die jeweilige Projektmanagement-Methode „kompatibel“ zur Testmanagement-Methode ist.
Testmanagement verbindet die produktunabhängige Projektmanagement-Methode mit der produktabhängigen Testmanagement-Methode.
Während pmqs.de davon ausgeht, dass man im Projektmanagement das Projektmanagement nicht mit den Produkterstellungsprozessen vermengen sollte (wie es in sog. Vorgehensmodellen oft getan wird), ist im Testmanagement das Gegenteil der Fall. Daher handelt es sich auch nicht um eine reine Managementmethode, sondern tatsächlich um ein Vorgehensmodell, welches die speziellen Anforderungen des Testens berücksichtigt und das notwendige Spezialwissen einbindet, bzw. voraussetzt.

Werden die Testkoordinatoren (fachliche Themenspezialisten im Test) von Anfang an eingebunden, dann verstehen sie ihr Testobjekt besser, da sie bei dessen Konzeption und Entstehung beteiligt sind. Sie unterstützen die anderen Stakeholder zu testbaren Anforderungen zu kommen. Damit leisten sie einen wichtigen Betrag zur Fehlervermeidung.
Kenner des CMMI-Standards [CMMI]wissen warum: Dort wird zwischen „Validation“ und „Verification“. Während sich Validierung darum kümmert, dass die richtige Lösung gebaut wurde, kümmert sich Verifikation darum, dass die Lösung richtig gebaut wurde.
Wird das Testmanagement und die Testspezialisten früh in das Projekt eingebunden, dann schauen weitere Personen auf das Thema Validierung. Wird der Testkoordinator spät eingebunden, dann kann er nur gegen möglicherweise falsche Anforderungen testen.
Die Vermeidung von Abweichungen (Softwarefehler) ist das Hauptziel der Testmanagement- Einbindung (etwa durch Tester mit einer Doppelausbildung als Businessanalyst und Testanalyst) in dieser Phase. Je später ein Fehler gefunden wird, umso teurer wird er. Das ist inzwischen eine Binsenweisheit – trotzdem werden Tester oft viel zu spät in die Projekte eingebunden.
Sind die Tester in der Anforderungsphase eines Projekts beteiligt lernen sie außerdem aus erster Hand, welches die wichtigsten und kritischsten Anforderungen aus Kundensicht sind. Dies gibt wertvolle Hinweise auf eine spätere Priorisierung und Abarbeitungsreihenfolge der Testfälle. Weniger wichtige Bereiche werden nicht über-testet und sehr wichtige Bereiche nicht unter-testet.
In einigen Unternehmen werden Tester nur als Empfänger von Anforderungen gesehen. Damit können sie zwar eine Verifikation des Produkts durchführen – der Gedanke der Validierung fällt aber unter den Tisch. Werden Tester erst eingebunden, wenn die Anforderungen schon fertig sind, ist es oft schon zu spät: Die Entwicklung hat mit dem Design (bzw. schlimmer schon mit der Umsetzung) begonnen, bevor sichtbar wird, das einzelne Anforderungen ungenau, unvollständig oder missverständlich sind. Änderungsanforderungen (Change Requests), welche viel später gestellt werden erzeugen hohe Mehrkosten. Bereits (falsch) erstellte Artefakte (Designs, Code, Testfälle, Testdaten, etc.) müssen nachträglich geändert werden. (Im Übrigen sind Dokumentationen, Testfälle, Testdaten, usw. oft Artefakte, welche nicht die die Änderungskosten hineingerechnet werden, so dass diese dann oft künstlich verbilligt werden. Dies tritt insbesondere dann auf, wenn Teile der Testleistung nicht vom Projekt, sondern quasi zusätzlich über „eh da“ Kosten durch den Auftraggeber erbracht werden.)
Es gibt Untersuchungen (Software Reliability: Achievement and Assessment, 1987) die belegen, dass eine Abweichung, die erst im Systemtest gefunden wird den fünfzigfachen Aufwand einer Abweichung erzeugt, die durch das frühe Einbinden des Testteams vermieden worden wäre – und dies beinhaltet nur „Fehler“ und nicht die zusätzlichen Kosten durch vermeidbare Änderungsanforderungen.

Organisatorische Einbindung zum Projektstart

Die frühe Einbindung des Testmanager unterstützt die Projektplanung und die Projektinitialisierung auf Testseite. Dies ist insbesondere dann relevant, wenn große Teile der Testaufgabe durch den Auftraggeber durchgeführt werden und damit nicht direkt der Steuerung des Projektmanagers unterstehen.
Die mangelnde Steuerbarkeit des Tests führt häufig zu erhöhten Risiken bezogen auf das Projektziel. Tests werden zu spät eingeplant, bzw. am Anfang nur ungenügend durchgeführt. Dies führt zwangsläufig zu Problemen bei der Abnahme (oder schlimmer zu Problemen nach Produktivnahme). Ein Testmanager kann direkt mit dem Auftraggeber eine Teststrategie (Ergebnistyp Testkonzept) entwickeln und damit früh transparent machen, wenn im Testumfeld etwa schiefläuft.

Einbindung des Testmanagements in die Projektplanung und in das Änderungsmanagement

Ein weiterer (Teil-)Aspekt ist das Änderungsmanagement im Projekt. Während Änderungsanforderungen (Change Requests) gerade in komplexen Projekten oft von x Stakeholdern abgezeichnet werden müssen, wird das Testteam oft nicht an dem Prozess beteiligt.

Das kann folgende fatale Effekte haben:
• Änderungen gehen am Testteam vorbei. Genehmigte Änderungen führen zu Abweichungsmeldungen („Fehler“), während dem Testzeitraum und führen als false-positives zu Zeit- und Arbeitsaufwand.
• Es gibt keine Testfälle für die Änderungen. Die neue (oftmals wichtige Funktionalität – sonst wäre der CR nicht genehmigt worden) wird nicht getestet und versagt bei der Produktivschaltung.
• Der zusätzliche Zeitaufwand für den Test des nachträglich geänderten Produkts wird nicht in der Projektplanung berücksichtigt. Dies führt zu ungeplanten Projektverzögerungen, an denen das Testteam „schuld“ ist.
• Die Kostenbilanz der genehmigten Änderungsanforderungen ist ungenau, da Testkosten (Testvorbereitung und Testdurchführung) nicht berücksichtigt werden. Wie beim zusätzlichen Zeitaufwand werden dann die Mehrkosten auch einer Fehlplanung im Testteam zugeschrieben.
Daher lautet die klare Botschaft an der Stelle. Das Testmanagement ist Stakeholder im Änderungsmanagementprozess.