Wie ein Testprozess den Weg zu Built-in-Quality ebnen kann

Passt ein nach ISO 29119 und ISTQB ausgerichteter Testprozess heutzutage in die agile Arbeitswelt? Ist „Test“ noch das korrekte Wort oder sollte es nicht eher Quality Assurance heißen? Wie kann ein Quality Assurance- und Test-Prozess den Paradigmenwechsel zu Built-in-Quality unterstützen? Wie erleichtert man den Einstieg in kontinuierliche Qualitätssicherung mit schnellen Feedbackzyklen?

Die Situation der DB Netz IT-Projekte 2019 war in vielen Firmen zu finden: Projekte mit einem wasserfallartigen, monolithischen, manuellen Testvorgehen, kaum Testautomatisierung und die ersten motivierten Teams auf dem Weg zu mehr oder minder gut umgesetzten agilen Vorgehensmodellen.

Zu diesem Zeitpunkt begann sich die Aufbruchsstimmung zu einem prozessgesteuerten Unternehmen zu entwickeln, welches sich an agilen Vorgehensweisen wie Scrum und SAFe© ausrichtet. Ein elementarer Bestandteil dieser Transformation nach SAFe© ist das Umdenken zu „Built-in-Quality“, die Erfüllung der Qualitätsstandards in jedem Schritt der gesamten Entwicklung und der Verantwortung jedes Einzelnen im Team, diese Ziele zu erreichen.

Ausgangspunkt Testing Manifesto

Doch wie erreicht man einen solchen Paradigmenwechsel? Es gibt viele Ansätze, die beschreiben, was Testen im agilen Umfeld ausmacht. Eines davon ist das Testing Manifesto (siehe Abbildung 1). Es zeigt auf, dass der klassische Test weiterhin benötigt wird, erweitert durch kontinuierliches Testen, Fehlervermeidung und Teamverantwortung.

Die Akzeptanz für dieses Manifest war von Anfang an vorhanden, doch die Umsetzung unklar. Wie kommt man von nachgelagertem Test zu Shift-Left-Ansätzen und schnellen kontinuierlichen Feedbackzyklen? Für erfahrene Tester ist dieser Sprung einfach, doch in agilen Teams sind alle von diesem Paradigmenwechsel betroffen.
Elementarer Bestandteil der agilen Transformation der DB Netz war daher die Entwicklung eines IT-QA- & Testprozesses, der die Bedarfe der aktuellen und zukünftigen Herausforderungen der IT-Projekte widerspiegelt. Dies beinhaltet:

• Vorgehensmodellunabhängig (für klassische und agile Projekte),
• Individual- & Kaufsoftware-Entwicklung,
• Abbildung aller Teststufen und -arten,
• leicht verständlich,
• Shift-Left-Ansatz (frühzeitige Fehlerfindung),
• konform unter anderem zu ISO 29119, ISO 25010 und CMMi©.

Phase 1: Drei Wände – ein Prozess

Die Entwicklung eines agilen Testprozesses begann in einem Konferenzraum mit drei Testmanagern. Basierend auf ISTQB und ISO 29119 wurde jede einzelne Testaktivität auf eine Karte geschrieben. Am Ende breitete sich dieser Prozess über drei Wände aus.

Die erste Erkenntnis war: Auf dieser Basis können wir die klassischen Testaktivitäten darstellen. Auch im agilen Vorgehen gibt es jeden einzelnen dieser Schritte, allerdings in viel kürzeren Zyklen. Es gibt keine Aktivität, die wegfallen würde. Allerdings war auch deutlich, dass dieser rudimentäre Prozess die geforderten Anforderungen bisher nicht erfüllt.
Deshalb entwickelte sich der Prozess im Laufe eines Jahres weiter (siehe Abbildung 2).

Phase 2 – Neue Stakeholder

Es zeigte sich, dass die Stakeholder des Prozesses nicht ausschließlich Tester sind. Qualitätssicherung liegt in der Verantwortung des ganzen Teams. Ein unterstützender Prozess muss demnach detailliert genug sein, um einem Projektleiter, Product Owner oder Entwickler zu erläutern, was zu tun ist. Zur Erhöhung der Akzeptanz war es wichtig, dass zu jeder Tätigkeit Ziel und Nutzen/Mehrwert deutlich werden (siehe Abbildung 3).

Darüber hinaus wurden Templates für Testkonzepte entwickelt, die als „Schritt für Schritt Anleitung“ zur Entstehung einer zusammenhängenden projektspezifischen Teststrategie führen. Ergänzend entstanden Good-Practice-Seiten zu jeder Testaktivität und ihrer Umsetzung in agilen Vorgehensweisen.

Unterstützend wurde ein Testdatenmanagementkonzept in Zusammenarbeit mit der ASQF-Gruppe Testdatenmanagement entwickelt, welches den Teams detailliert ein systematisches Testdatenmanagement erläutert.

Phase 3 – Quality Assurance ≠ Test

Während der ersten Reviews mit den Stakeholdern kam die Frage auf: „Ist Test nicht das, was am Ende geschieht?“ Es wurde deutlich, dass ein Umdenken nicht möglich ist, wenn wir an alten Begrifflichkeiten festhalten.

Test ist eine korrektive Aktivität. Sie überprüft das Produkt, um Fehler zu entdecken. Im klassischen V-Modell ist dies eine Tätigkeit, die oft zu spät im Entwicklungszyklus erfolgt. In agilen Vorgehensweisen wird kontinuierlich und hochgradig automatisiert getestet. Allerdings ist es auch hier eine korrektive Tätigkeit, denn der Fehler ist bereits geschehen (siehe Abbildung 4).

Zur Fehlervermeidung müssen Prozesse und Methoden kontinuierlich verbessert und Qualitätsstandards geschaffen werden. Ziel des neuen Prozesses muss es daher sein, das kontinuierliche Verbessern der Testaktivitäten zu unterstützen. Am Ende eines jeden Product Increments beziehungsweise Releases wird im Rahmen von SAFe© oder Scrum eine Retrospektive durchgeführt. Ein Event, bei dem es darum geht, aus der Vergangenheit zu lernen und sich zu verbessern. Ein passender Ort, an dem auch die erfolgten Testaktivitäten reflektiert werden können, um so das Vorgehen optimieren zu können. Das optimierte Testvorgehen wiederum ist im Testkonzept festzuhalten.

In der Vergangenheit war es oft der Fall, dass bei Projektbeginn ein Testkonzept geschrieben wurde und es bei Projektende verstaubt in der untersten Schublade lag. Oft wird hinterfragt, ob im agilen Vorgehen überhaupt noch ein Testkonzept benötigt wird. Es muss einen Ort geben, wo das Qualitätssicherungsvorgehen dokumentiert ist, wo jedes Teammitglied Zugriff hat, denn nur dann kann es auch gelebt werden. Ein Testkonzept darf kein starres Dokument sein, es muss sich ebenso wie das Team kontinuierlich weiterentwickeln und an neue Gegebenheiten angepasst werden. Hier wird die Basis für einen Quality Assurance-Ansatz geschaffen.

Phase 4 – Test ist mehr als Systemtest

Auch die klassischen Test-Rollen tragen dazu bei, dass die Verantwortung für Testaktivitäten ausschließlich bei diesen gesehen wird, beispielsweise Testmanager oder Testdesigner.

Schaut man sich jedoch die Testaktivitäten in DevOps an (siehe Abbildung 5), stellt man fest, dass permanent getestet wird. Test ist Aufgabe des gesamten Teams, doch oft haben die betroffenen Personen nicht das notwendige Wissen, um systematisch testen zu können. Im agilen Vorgehen ist es die Aufgabe derjenigen mit Test-Know-how, dafür Sorge zu tragen, dass das Team gecoacht wird, sich selbst helfen zu können. Die Rollen Testmanager, Testdesigner und Tester sind überholt, vielmehr sollten sie Quality Coach, Quality Engineer und Quality Specialist heißen.

Der Prozess muss in der Lage sein, die verschiedenen Teststufen und -arten innerhalb DevOps zu integrieren. Dabei kam die Erkenntnis, dass alle Testaktivitäten in jeder Teststufe vorkommen, nur unterschiedlich ausgeprägt. Der Prozess wies bereits alle notwendigen Inhalte auf. Es fehlte allein die Möglichkeit einer iterativen Ausführung (siehe Abbildung 2).

Dabei löste sich auch das Problem der Darstellung der Testarten nach ISO 25010 (bspw. Last- & Performanz, Security), denn auch hier finden sich dieselben Testaktivitäten wieder. Durch eine Erweiterung der Beschreibung und der Verwendung der neuen Rollenbezeichnungen wurde der entstehende Prozess in die Lage versetzt, für jede Teststufe und -art nutzbar zu sein. So muss beispielsweise ein Quality Engineer in der Teststufe Unittest niemand mit Test-Know-how sein. Diese Rolle kann auch ein Entwickler einnehmen, unterstützt durch einen Quality Coach.

Phase 5 – Infrastruktur muss gepflegt werden

Entscheidend im agilen Test ist ein hoher Grad an Testautomatisierung. Hierzu wird ein Framework benötigt, welches unterschiedliche Testautomatisierung in den verschiedenen Teststufen/-arten ermöglicht. Ebenfalls werden Testdaten und Umgebungen für die Testausführung benötigt. All diese Tools bergen in sich Fehlerquellen, wenn sie nicht kontinuierlich gewartet und weiterentwickelt werden. Auch dies ist ein Bestandteil von Quality Assurance, ebenso wie gepflegte Testfälle und automatisierte Testskripte (Regression).

Phase 6 – Letzte Ecken & Kanten

Im Rahmen der Finalisierung des Prozesses wurden unterschiedliche Szenarien prozessual durchlaufen (Iterative Testansätze, Wasserfall, Kaufsoftware-Test, Test in Kleinstprojekten). In Reviews waren mehr als 100 Personen verschiedener Rollen beteiligt, um den universellen Einsatz des Prozesses innerhalb der DB Netz für alle Stakeholder zu ermöglichen. Darüber hinaus wurde der Prozess als Pilot in den Projekten verprobt und die Erfahrungen, Wünsche und Ideen zur Optimierung des Testprozesses genutzt.

Es entstand ein umfangreicher Prozess, der Ende-zu-Ende die aktuellen Qualitätssicherungs- und Testmaßnahmen beinhaltet, dabei ISO-Normen und ISTQB berücksichtigt und als Basis für automatisierte, kontinuierliche Qualitätssicherung dienen kann (siehe Abbildung 6).

Ein Prozess lernt laufen

Um die Akzeptanz des Prozesses zu erhöhen und die Stakeholder auf dem Weg der Operationalisierung zu begleiten, ist es hilfreich, die Prozesse direkt in die tägliche Arbeit zu integrieren.
Im Rahmen der SAFe©-Transformation und hin zu schnellen iterativen Zyklen ist die Einführung einer CI/CD-Pipelinelösung unabdingbar. Oft werden diese als Deployment-Pipelines genutzt, obwohl sich im Namen bereits der Begriff CI (Continuous Integration) versteckt. Kontinuierliche Integration bedeutet allerdings auch kontinuierliches Testen.

Parallel zur Entstehung des IT-QA- & Testprozesses wurde die Modular Quality Assurance Pipeline (MoQ-AP) konzipiert (siehe Abbildung 7). Eine zentral entwickelte, standardisierte und modulare CI/CD-Pipelinelösung mit dem Fokus auf Quality Assurance und Testing. Die Pipelinemodule basieren auf GitLab-CI-Skripten. Die MoQ-AP wird kontinuierlich weiterentwickelt und soll zukünftig große Teile des IT-QA- & Testprozesses automatisch abbilden.

Bei der Umsetzung der MoQ-AP liegt der Fokus auf den Bedarfen unserer Stakeholder. Dabei werden Compliance- und Security-Anforderungen bereits integriert.

Das Themenfeld CI/CD ist für viele IT-Projekte eine neue Erfahrung. Während der Entwicklung des IT-QA- & Testprozesses wurde darauf geachtet, den Nutzen jeder einzelnen Aktivität zu erläutern. Dieselbe Herausforderung existiert bei der Einführung der MoQ-AP. Um die Stakeholder zu integrieren, wird nicht nur auf eine umfangreiche Dokumentation gesetzt, sondern auf lauffähige Demo-Pipelines mit exemplarischen Implementierungen jeder Funktion.

Um den Anforderungen an Ende-zu-Ende-Qualitätssicherung inkl. aller Teststufen und -arten gerecht zu werden, verfügt sie unter anderem über:

• Zusammenspiel aller Arten von Qualitätssicherung,
• automatisiertes Teststufenkonzept,
• parallele und sequenzielle Testausführung,
• dynamische Testumgebungen,
• kontinuierlicher Last- und Performanztest inkl. Performanztrendanalyse
• u.v.m.

Fazit - Ein Prozess ist ein Stück Papier

Der IT-QA- & Testprozess ist ein Teil der großen Prozesslandkarte der DB Netz und muss sich nahtlos darin einbetten. Am Ende ist jeder Prozess aber nur ein Stück Papier. Wird er nicht gelebt und in die tägliche Arbeit integriert, wird kein Mehrwert geschaffen. Dabei ist es wichtig, jeden mitzunehmen, unabhängig von der Wissensstufe.

Zu beachten ist, dass ein solcher vorgehensmodellunabhängiger Prozess niemals alle Bedürfnisse jedes Projekts erfüllen wird. Es muss immer möglich sein, Aktivitäten auf die Bedarfe anpassen zu können (Tayloring) und das unter Berücksichtigung von Konzern- und Strategievorgaben.

Das Fazit nach der Entstehung des Prozesses ist, dass die Reise noch lange nicht zu Ende ist. Ein Prozess ist nie so gut, dass er nicht kontinuierlich weiterentwickelt werden muss. Neue Projekte, ihre Anforderungen und Herausforderungen werden den Prozess weiterentwickeln, beispielsweise durch die Digitale Schiene Deutschland. Parallel dazu wird sich auch die MoQ-AP neuen Herausforderungen stellen. Die agile Transformation und die Digitalisierung im Rahmen der Konzernstrategie „Starke Schiene“ werden hier maßgeblich unterstützt.

Die Autoren