In modernen IT-Projekten sind agile Methoden der Softwareentwicklung, wie Scrum, XP oder Kanban „State of the art“.
Das Aufsetzen eines agilen Projekts in einer ansonsten traditionellen (Wasserfall) Systemlandschaft ist dabei deutlich anspruchsvoller als das Implementieren dieses Projekt in einem bereits agilen Umfeld. Am einfachsten zu etablieren ist der agile Ansatz in Projekten die quasi „Stand-alone“ sind, die also keinerlei oder kaum Abhängigkeiten zu anderen Systemen sowohl technisch/ fachlich als auch terminlich haben.
Wir wollen hier an einem aktuellen Beispiel aus der Praxis von Spirit-Testing aufzeigen, wie agiles Testen in einem behördlichen Scrum-Großprojekt, in einer weitestgehend von nicht agilen Projekten und Systemen geprägten Landschaft, sicher etabliert werden konnte.
Agile Softwareentwicklung erfordert eine andere Herangehensweise an das Testen als das traditionelle Wasserfallmodell, wo man eine möglichst hohe Unabhängigkeit des Testteams von der Entwicklungsmannschaft anstrebt.
Nach der Lehre spricht man im agilen Umfeld von einer Auflösung der klassischen Testrollen, wie des Testmanagers des Testanalysten und des Testers. In einem so großen (umfangreichen) Projekt, wie es die Spirit-Testing gerade unterstützt ist diese Auflösung der Testrollen in gewissen Teilen so nicht mehr sinnvoll und auch nicht mehr möglich. Der Grund dafür ist die schiere Größe des Projekts und die Abhängigkeiten zu anderen Partnersystemen.
In diesem Behördenprojekt wird für die Kunden eine neue online Plattform entwickelt, in der sich die User für verschiedene Dienste und Leistungen an- und abmelden und spezielle Leistungen beantragen können. Um das gewährleisten zu können muss dieses Portal auf verschiedene Partnersysteme zugreifen können. Diese Partnersysteme werden fast ausschließlich in einem nicht agilen Umfeld entwickelt.
Aufgrund dieser hohen Anzahl von Abhängigkeiten zu Wasserfall-Projekten ergeben sich besondere, für agile Projekte untypische Herausforderung in der Release- und Schnittstellenplanung.
Das Projekt besteht aus knapp 120Mitarbeitern. Davon arbeiten ca. 60 in 6 verschiedenen Entwicklungsteams. Alleine daraus ergeben sich etliche Abhängigkeiten zwischen den Teams, die sich in den allermeisten Fällen von den Teams selbst aufgelöst werden können. Das ist bei den Abhängigkeiten zu den anderen Partnersystemen jedoch nicht mehr möglich.
Deswegen hat sich die Installation eines von den Entwicklungsteams gelöstes, übergeordnetes Testteam sehr bewährt. Dieses besteht aus:
Der Testmanager ist für die projektweiten Methoden und Standards verantwortlich, die er u.a. im (Master-) Testkonzept festgelegt und für jedes Release neu bewertet werden. Ebenso ist der Testmanager für die Festlegung und Durchführung nicht funktionaler Testansätze, wie Last- und Performance Tests verantwortlich. Nicht zuletzt bildet er die Schnittstelle zu den Management Ebenen, wie Release Management, Projektleitung und Betrieb ab.
Der technische Testmanager ist ein Testspezialist mit viel Testerfahrung im agilen Umfeld, auch in der methodischen Testableitung. Er ist verantwortlich für die Bestimmung der operativen Teststrategien, insbesondere in der Testautomatisierung. Der techn. Testmanager ist auch für die Bereitstellung aller notwendigen Umgebungen und Berechtigungen verantwortlich.
Der Testdatenmanager stellt die für alle Entwicklungsteams relevanten Testdaten die von anderen, meist nicht agilen, Partnersystemen abhängig sind zur Verfügung. Dazu steht er mit diesen in ständigen Kontakt um immer über die neuesten Entwicklungen innerhalb dieser Systeme informiert zu sein. Darüber hinaus stellt er auch sicher, dass alle notwendigen Testdaten für die eigenen Umgebungen zum richtigen Zeitpunkt zur Verfügung stehen.
Der Fehlermanager ist für die Prozesse und das Reporting im Bereich Defectmanagement verantwortlich. Er stellt sicher, dass die Ausgangskriterien hinsichtlich Fehleraufkommen eingehalten werden. Darüber hinaus achtet er darauf dass Bugs innerhalb der Teams, sinnvoll priorisiert abgearbeitet werden, was er stets in Abstimmung mit den Produktverantwortlichen (PO) macht
Die Größe der Umgebungslandschaft innerhalb des Projekts ist enorm: 18 Teamumgebungen, 3 Nightlies, 3 Integrations, 3 Stables und einer Demo- Umgebung. Dazu kommen noch zwei höhere, integrative Testumgebungen die technisch gesehen möglichst nah an der Produktionsumgebung sind.
Diese ganzen Umgebungen können nicht ausschließlich von den Entwicklungsteams aus testtechnisch koordiniert werden. Das übergeordnete Testteam betreut die Regressions- und Release Tests sowie die Testsuiten auf den zwei höheren Umgebungen. Unterstützt werden sie dabei noch von einem weiteren Querschnittsteam, dem BU-Team (Betriebsunterstützung). Dieses Team kümmert sich um die technischen Belange aller Umgebungen. So ist die Verantwortung für die Betriebsbereitschaft der Umgebungen auch aus den Entwicklungsteams herausgenommen.
Als Fazit können wir hier festhalten, das in einem besonders großen Projekt mit vielen Schnittstellen, die nach der klassischen Methode entwickeln, ist es nicht mehr möglich beispielsweise Scrum nach der reinen Lehre umzusetzen. Es braucht hier Anpassungen, wie das Implementieren gewisser Querschnitt-Teams.
Die Teamarbeit steht im Vordergrund. Es ist den SPIRIT-Indianern ein großes anliegen Ihre Erfahrungen und Kenntnisse in die Sprint Teams einer agilen Entwicklung einzubringen. Selbstverantwortlich, nachhaltig und gemeinschaftlich werden Lösungen im Bereich der Testfallermittlung, Testdurchführung und Testautomatisierung umgesetzt. Wir verbinden die Standards der ISTQB® mit den agilen Anforderungen moderner IT-Entwicklung.
Gerne stellen wir Ihnen auch unser Konzept zur Einführung einer automatisierten Teststrategie in einem Präsentationstermin vor.
Schicken Sie uns einfach eine Anfrage, wir freuen uns darauf Sie weiterführend beraten zu können.