Der frühe Vogel fängt den Wurm…über frühzeitiges Implementieren von Testmanagement, bzw Teststrukturen im Programm oder Projekt
Hurra, wir sind ab Beginn dabei! Das Transformationsprogramm wird aufgesetzt und das Testmanagement in diesem Zuge direkt ab Beginn als ein Programmbestandteil etabliert. In diesem Falle als eigenes Projekt innerhalb des Programms.
Dieser Aspekt ist bereits als Erfolg zu werten, wurde das Testen doch lange Zeit im IT- Projektumfeld eher stiefmütterlich behandelt. Dies haben wir bereits in “Verzicht auf professionelles Testen – eine Milchmädchenrechnung” besprochen.
Für ein erfolgreiches Testmanagement ist es wichtig, das Projekt und seinen Aufbau frühzeitig zu verstehen, sowie möglichst viele der relevanten Stakeholder kennenzulernen.
Je größer ein Programm oder ein Projekt ist, umso mehr Beteiligte mit unterschiedlich Anforderungen, Erwartungen und Zielsetzungen gibt es. Unser Kunde bringt verschiedenste Personen und Rollen ein, z.B. als Auftraggeber, Projektmitarbeiter, fachliche und technische Verantwortliche und letztlich die Anwender. Der Softwarehersteller stellt ebenfalls eine Vielzahl von Mitarbeitern, beispielweise Manager, Business Analysten, aber eben auch Entwickler und eigene Tester.
Die Programmstruktur und -größe hat wesentlichen Einfluss auf die Testkonzeptionierung und die sich daraus ergebenden Zuständigkeiten. Die Planung und Organisation beginnt in unserem Falle schon frühzeitig, bevor die eigentliche Testfallerstellung und Durchführung erfolgen kann. Das Testteam kann sich formieren und ist bereits in das Projektgeschehen integriert.
Sobald der Programmplan steht, wird deutlich, welche Wissensträger zur Testunterstützung benötigt werden und vor allem wann. Dies ermöglicht die Identifikation von Überlastungen einzelner Personen, die dann durch die Modifikation der Teilpläne aufgelöst werden können.
Das Testen selbst, ist dem eigentlichen Projektgeschehen immer ein Stück weit nachgelagert, umso wichtiger ist das frühzeitige Einbeziehen des Testteams in die Abläufe, denn es muss zunächst klar sein, was der Scope im Projekt, bzw. im Programm ist, um die erforderlichen Aktivitäten überhaupt planen und vorbereiten zu können:
Verstehe dein Projekt und kenne die beteiligten Personen.
Das beauftragte Bestandsführungssystem wird in unserem Szenario durch einen Anbieter für Standardsoftware bereitgestellt. Der Kunde darf damit eine qualitätsgesicherte Software erwarten. Dies gilt sowohl für die Standardfunktionalitäten, aber auch für die angepassten oder neu entwickelten Bestandteile.
Die Komponenten- und Systemtests erfolgen also bereits herstellerseitig vor der Auslieferung und werden uns durch ein entsprechendes Reporting nachgewiesen.
Wir planen bei unserem Kunden daher im Wesentlichen die Abnahmetests, aber auch die Überprüfung der Systemintegration mit der kundeneigenen Systemlandschaft.
Die grundlegende Fragestellung hierbei lautet:
Arbeitet das System wie angefordert und beschrieben und klappt dies auch noch im Zusammenspiel mit den vorhandenen internen Anwendungen sowie möglicher Drittanbietersoftware?
Wichtig ist das programmübergreifende, gemeinsame Verständnis hinsichtlich der Zielsoftware und eine möglichst genaue Dokumentation der Anforderungen. Auf dieser Basis lassen sich dann die relevanten Testfälle ableiten. Durch das rechtzeitige Einbinden des Testteams im Anforderungsprozess, kann hier bereits eine Qualitätssicherung auf die Beschreibung der User Story und die jeweiligen Akzeptanzkriterien erfolgen.
Es wird also schnell deutlich, dass es durchaus sinnvoll ist, das Testen nicht nur als projektabschließendes, notwendiges Übel zu betrachten, sondern als festen Programmbestandteil einzuplanen.
Ob aber der frühe Vogel auch im Winter die besten Karten hat, das wäre noch zu klären… .
