Aufbau einer Testing-CoP bei einem Luftfahrtunternehmen

Für den Erfolg im digitalen Zeitalter ist es für Unternehmen entscheidend, schnell auf Veränderungen reagieren und innovative Lösungen bereitstellen zu können. Ein großes Luftfahrtunternehmen hat dies erkannt und mit seiner „Digitaleinheit“ eine umfassende Transformation der digitalen Entwicklungslandschaft eingeleitet. Ein zentraler Baustein dieser Transformation war der Aufbau einer Community of Practice (CoP) im Softwaretesten Diese Fallstudie beleuchtet den Prozess der Etablierung dieser CoP, die dabei auftretenden Herausforderungen, die implementierten Lösungen, die erzielten Erfolge sowie die daraus gewonnenen Erkenntnisse.

Konzept der Digitaleinheit

Die Digitaleinheit soll die Entwicklung neuer digitaler Lösungen im Unternehmen vorantreiben. Sie zielt darauf ab, den Ansatz zur digitalen Bereitstellung grundlegend zu ändern: Weg von projektorientierten, siloartigen Teams und hin zu kundenorientierten, End-to-End-fähigen und funktionsübergreifenden ("cross-functional") Teams. Innerhalb dieses Rahmens wird ein skalierbares agiles Entwicklungsmodell eingeführt. In der Digitaleinheit sollen die Produktteams die volle E2E-Verantwortung übernehmen, was eine grundlegende Transformation der Test- und Qualitätssicherungsprozesse erfordert. Die Community of Practice war damit deutlich stärker mandatiert als üblich.

Herausforderungen

Beim Aufbau der CoP und der Transformation des Testings wurden verschiedene Herausforderungen identifiziert:

• Unterschiedlicher Reifegrad: Die Produktbereiche und Entwicklungsteams verfügten über verschiedene Erfahrungsniveaus im Testing. Während einige von Grund auf neu begannen, konnten andere auf etablierte Prozesse und Methoden zurückgreifen. Deshalb war eine flexible Herangehensweise nötig, die auf diese Unterschiede einging.

• Abhängigkeit von bestehenden Prozessen und Infrastrukturen: Die Erhöhung der Geschwindigkeit und das "Shift Left Testing" waren an bestehende Prozesse und Infrastrukturen gebunden. Die vorhandene Infrastruktur (z.B. Testumgebungen) entsprach nicht den Anforderungen.

• Qualitätserwartungen und E2E-Verantwortung: Die Erwartungen an die Qualität sollten aus den Teams selbst kommen. Die Teams mussten die End-to-End-Verantwortung aktiv übernehmen. Qualität sollte von Beginn an integraler Bestandteil aller Disziplinen sein – nicht nur des Testens.

• Abhängigkeiten: Das Testen war eng mit bestehenden Systemen, Prozessen und der allgemeinen Akzeptanz von Qualität in den Teams verknüpft. Auch die Ergebnisse und das Tempo anderer Disziplinen und CoPs wirkten sich aus.

• "50 Shades of E2E": Es gab keine vollständige Dokumentation der Geschäftsprozesse, und die vorhandenen E2E-Tests waren heterogen (Scope, Tiefe, Frameworks).

• Komplexität der Systemlandschaft: Die Systemlandschaft, Testumgebungen und Testdaten waren sehr komplex.

• Anforderungslage bei den Geschäftsprozessen: Die Anforderungen an die Geschäftsprozesse waren oft unklar oder unvollständig.

Aufbau der CoP

Die Community of Practice im Softwaretesting wurde etabliert, um die Transformation im Bereich Testen und Qualitätssicherung zu unterstützen. Ihre Mission umfasste vier Hauptbereiche:

1. Community of Practice: Die Community of Practice wurde als lebendiges, integratives Forum für alle am Softwaretesten Interessierten etabliert – innerhalb und außerhalb der Testeinheit. Sie trifft sich regelmäßig zum fachlichen Austausch.
2. Testing Guideline: Entwicklung einer Strategie, um alle Testaktivitäten auszurichten und ein einheitliches Verständnis der Prinzipien und Ziele der Qualitätssicherung zu etablieren. Die Umsetzung wird durch regelmäßige Assessments unterstützt.
3. E2E-Testing: Aufbau und Überwachung eines E2E-Testteams für Regressionstests von Geschäftsprozessen und übergreifenden Testaktivitäten. Dies beinhaltet die Absicherung kritischer E2E-Geschäftsprozesse und die Bereitstellung von Services für übergreifende Testaktivitäten wie Testumgebungs-, Testdaten-, Testtool-, Strategie, Last- und Performance-Tests, Accessibility-Tests und Security-Tests.
4. Testing Resources: Unterstützung der Produktbereiche bei der Identifikation, Auswahl und dem Onboarding von Testressourcen mit Hilfe der bereits eingespielten Tesabteilung.

Umgesetzte Maßnahmen

Um den Herausforderungen zu begegnen, wurden folgende zentrale Maßnahmen implementiert:

• Kollaborative Erarbeitung einer Testing Guideline: Gemeinsame Entwicklung der Testrichtlinie unter Einbeziehung aller relevanten Stakeholder.

• Aufbau eines dezidierten E2E-Testteams: Schaffung eines zentralen Teams zur Migration, Erweiterung und Durchführung von E2E-Tests.

• Zentralisierte Bereitstellung von Test-Ressourcen: Anbindung der Produktteams an die erfahrene, interne Testeinheit für eine bedarfsgerechte Unterstützung.

• Fokussierung auf Qualitätsverantwortung: Aktive Einbindung der Stakeholder und Etablierung von Qualitäts-Assessments in den Teams.

• Einführung von Regel-Austauschformaten: Etablierung regelmäßiger CoP-Meetings und Assessments zur Förderung des Wissensaustauschs.

Ergebnisse und Erfolge

Durch die konsequente Umsetzung der Maßnahmen konnten folgende nachhaltige Erfolge erzielt werden:

• Etabliertes gemeinsames Qualitätsverständnis: Die Guideline sorgte für eine einheitliche Ausrichtung und ein klares Verständnis der Testziele in allen Teams.

• Nachweisbar verbesserte E2E-Qualität: Kritische Geschäftsprozesse wurden zuverlässig abgesichert, was die Stabilität im Live-Betrieb deutlich erhöhte.

• Effiziente und skalierbare Ressourcen-Versorgung: Die Produktteams konnten schnell und bedarfsgerecht mit qualifizierten Testexperten versorgt werden.

• Gelebte End-to-End-Verantwortung: Die Teams übernahmen spürbar mehr Verantwortung für die gesamte Produktqualität.

• Etablierte Kultur der kontinuierlichen Verbesserung: Der regelmäßige Austausch etablierte einen nachhaltigen Prozess zur stetigen Optimierung im Bereich Testing und QA.

Lessons Learned

Aus dem Projekt konnten wichtige Lehren gezogen werden:

• Kein grünes Feld: Die Teams starteten auf sehr unterschiedlichem Niveau. Die Implementierung musste auf diese Unterschiede eingehen und verschiedene Geschwindigkeiten zulassen. Bestehende Prozesse und Infrastrukturen (z.B. Testumgebungen) waren nicht für Digitaleinheit ausgelegt und banden die Geschwindigkeit.

• Testen ist nur so gut wie der allgemeine Entwicklungsprozess: Die Erwartungen an die Qualität sollten aus den Teams selbst kommen. Sie müssen die End-to-End-Verantwortung aktiv übernehmen. Qualität sollte von Beginn an in alle Disziplinen integriert sein.

• Testen ist keine Insel: Es gibt viele Abhängigkeiten zu bestehenden Systemen und Prozessen, zur allgemeinen Akzeptanz von Qualität und Testen in den Produktbereichen und Entwicklungsteams sowie zu den Ergebnissen und der Geschwindigkeit anderer Disziplinen und CoPs.

• Kommunikation ist entscheidend ("Talk, talk, talk"): Regelmäßiger Austausch und Abstimmung mit Stakeholdern außerhalb der CoP (z.B. andere CoPs, Team-Leads, Organisationen außerhalb der Digitaleinheit) sind essenziell, um die Verantwortung für die E2E-Produktqualität (insbesondere nicht-funktionale Anforderungen) zu fördern.

• Eine agile Transformation ist kein Selbstläufer: Es gibt unterschiedliche Reifegrade im Testen in Teams, und die E2E-Verantwortung muss wirklich gelebt und übernommen werden. Die "bestehende" Welt ist nicht die "alte" Welt, und die Wiese ist nicht nur grün (Legacy-Systeme).

• Transformation vom Test Manager zum Facilitator: Die Rolle des Test Managers hat sich gewandelt.

• Komplexität der Systemlandschaft: Die Komplexität der Systemlandschaft, Testumgebungen und Testdaten bleibt eine Herausforderung.

• Unterstützung durch hohe Management Attention: Die Unterstützung durch das Management ist entscheidend für den Erfolg.

Der Aufbau der Community of Practice im Rahmen der Digitaleinheit eines großen Luftfahrtunternehmens ist ein herausragendes Beispiel dafür, wie Unternehmen auf die Herausforderungen der digitalen Transformation reagieren können.

Durch die Etablierung einer lebendigen CoP, die Entwicklung einer gemeinsamen Testing Guideline, den Aufbau eines E2E-Testteams und die effiziente Nutzung von Testressourcen konnte die Qualitätssicherung maßgeblich verbessert und die E2E-Verantwortung in den Produktteams gestärkt werden.

Die gewonnenen Erkenntnisse, insbesondere die Bedeutung von Kommunikation, die Berücksichtigung unterschiedlicher Reifegrade und die Notwendigkeit einer starken Management-Unterstützung, sind wertvolle Lehren für ähnliche Transformationsprojekte.

Die Fallstudie zeigt, dass der Erfolg in der agilen Welt nicht nur von technologischen Innovationen abhängt, sondern maßgeblich von der Fähigkeit, Wissen zu teilen, Prozesse anzupassen und eine Kultur der kontinuierlichen Verbesserung zu etablieren.

Sie interessieren sich für agile Transformation oder den Aufbau einer Community of Practice im Bereich Software-Qualitätssicherung? Kontaktieren Sie uns gerne für einen persönlichen Austausch oder weiterführende Informationen!