Die Evolution des Testers im Agilen Umfeld

In der Softwareentwicklung hat sich die agile Methodik als eine der effektivsten Herangehensweisen herausgestellt, um den sich ständig ändernden Anforderungen des Marktes gerecht zu werden. Doch mit dem Übergang zu agilen Arbeitspraktiken verändern sich auch die Rollen und Verantwortlichkeiten der Qualitätssicherung (QA). In diesem Artikel werden wir uns mit diesen Veränderungen auseinandersetzen und zeigen, wie QA weiterhin einen Mehrwert für Projekte bieten kann, wenn das Team agiler wird.

Rollenerkennung

Die häufigsten Merkmale einer agilen Transformation sind die verkürzten Lieferzyklen und der Schwerpunkt auf „Shift Left“, bei dem Testaktivitäten bereits in den frühen Phasen der Softwareentwicklung beginnen. Dies verändert nicht nur den Entwicklungsprozess und die technischen Werkzeuge im Team, sondern auch die Rollenerkennung.

Im klassischen Wasserfall Entwicklungsmodell wurden Tester oft als separate Einheit innerhalb eines Entwicklungsteams betrachtet, die sich ausschließlich auf die Qualitätssicherung konzentrierten. Diese Trennung zwischen Entwicklung und Qualitätssicherung war oft ineffizient und führte zu Silos, bei dem der Tester als Sicherheitsnetz agiert.

In einem agilen Umfeld hat sich jedoch die Arbeitsweise grundlegend geändert. Während die Rolle des Entwicklers eine Transformation durchläuft, gibt es auch Wandel in der Rolle eines Testers.

Agile Tester werden nicht mehr als „Qualitätspolizisten“ angesehen, sondern als integraler Bestandteil des gesamten Entwicklungsprozesses. Sie arbeiten in einem Funktionsübergreifenden Team eng mit Entwicklern, Produktmanagern und anderen Stakeholdern zusammen, um frühzeitig Feedback zu liefern. Es wird mehr Wert auf Pair Testing mit den Entwicklern gelegt. Ein ganzheitlicher Ansatz für die Qualität wird verfolgt, bei dem alle Projektbeteiligten für die Qualität und den Erfolg des Projekts verantwortlich sind.

Trotz dieser Veränderungen können jedoch einige Probleme auftreten. Einige Entwickler mögen keine End-to-End-Tests ihrer Arbeit und verlassen sich weiterhin auf Tester für Testaktivitäten. Die Tester fungieren weiterhin als Gatekeeper für die Qualität.

 

Der Übergang zum Modernen Testen: Wie Tester aufhören können, die Stützräder für Teams zu sein

Um dies zu erreichen, müssen Tester ihre Herangehensweise ändern. Sie müssen sich von einer „tun“- zu einer „Coaching“-Rolle entwickeln. Um dies zu unterstützen, sind einige Änderungen in der Organisationsstruktur erforderlich.

Traditionelles Testen, bei dem Tester als Sicherheitsnetze agieren und Testing von der Implementierung getrennt ist, kann sich negativ auf die Qualität auswirken. Tester können stattdessen als Coaches agieren, in Teams zusammenarbeiten und Veränderungen fördern, um aufzuhören, die Stützräder für Teams zu sein.

Eine Stimme, die diese Veränderungen verkörpert, ist Conor Fitzgerald, der auf Konferenzen über den Übergang vom traditionellen zum modernen Testen spricht. Fitzgerald betont die Bedeutung von Teamarbeit und Zusammenarbeit, um Qualität zu steigern, Verschwendung reduzieren und letztendlich dazu beitragen, dass Teams effektiver arbeiten.

Fitzgerald spricht von den 3Ss und 3Cs, wobei er Tester ermutigt, sich den 3Cs zuzuwenden und sich von den 3Ss zu entfernen.

Die 3Ss sind:

• Safetynet: Leider können Tester als Sicherheitsnetze agieren, indem sie die Ausgabe eines Teams testen, alle Testautomatisierungen pflegen oder über spezialisiertes Projektwissen verfügen. Tester müssen sich dessen bewusst sein und darüber nachdenken, wie diese Aktivitäten teambasiert werden können.
• Solo: Aufbauend auf dem vorherigen Punkt, wenn wir alleine handeln, verschlimmern wir das Problem, ein Sicherheitsnetz zu sein. Zum Beispiel kann es schädlich für das Wachstum des Teams sein, wenn Wissen darüber, wie ein Feature getestet wird, nicht mit dem Team geteilt wird.
• Static: Wir sind in einer Branche, die sich ständig verändert. Daher müssen wir Veränderungen annehmen und uns anpassen.

Die 3Cs sind Coaching,  Collaborate, Change.

Laut Fitzgerald sind Tester oft die Stützräder für das Team:

„Wir müssen immer darüber nachdenken, wann wir die Stützräder entfernen können und sicherstellen, dass das Team vollständig unabhängig sein kann.“

 

Modern Testing Principles

Die Modern Testing Principles bestehen aus 7 zentralen Punkten, die 2017 von zwei ehemalige Microsoft-Testveteranen Alan Page und Brent Jensen entwickelt wurden. Diese Regeln oder Ideen helfen agilen Testern, die nächste Stufe zu erklimmen und ihr gesamtes Team dazu zu bringen, sich für Qualität zu begeistern. Sie ermutigen Tester, nicht länger als Sicherheitsnetz für Entwickler zu fungieren, sondern in eine Coaching-Rolle zu schlüpfen, um allen zu helfen, zu lernen, wie man testet und hochwertige Ergebnisse erzielt.

Die sieben Prinzipien von Modern Testing sind:

1. Business First – Our priority is improving the business: Tester konzentrieren sich bei ihren Testaktivitäten stark auf den Kunden, aber sie müssen auch das Unternehmen verstehen und nicht nur darauf hinarbeiten, ein Qualitätsprodukt ohne Bugs zu liefern, sondern auch das richtige Produkt, das der Kunde braucht.
2. Bottlenecks Out – We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system: Dieser Grundsatz besagt, dass QAs nicht nur Prozesse verbessern, sondern auch den Fortschritt des Teams beschleunigen und andere Einschränkungen aus der Gleichung entfernen sollten.
3. Learn & Adopt – We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures: Das Hauptziel besteht darin, die Leute, die den Code schreiben, für dessen Korrektheit verantwortlich zu machen. Tester fungieren in der Regel als Sicherheitsnetz für ihre Kollegen, die sich ausschließlich mit der Entwicklung befassen, und verhindern, dass Fehler, die sonst nicht entdeckt worden wären, den Kunden erreichen. Wenn jemand anderes nach mir testet, muss ich mich nicht selbst um die Validierung meines Codes kümmern.
4. Leadership – We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture: Wir Tester sind nicht nur für die Qualität verantwortlich, aber wir sind dafür zuständig, die Qualitätskultur zu verbessern.
5. Real Quality – We believe that the customer is the only one capable to judge and evaluate the quality of our product: So sehr Tester und Entwickler auch versuchen, sich für den Kunden einzusetzen und Tests über die gesamte Customer Journey hinweg durchzuführen, wir sind NICHT der Kunde. Daher müssen wir Wege finden, um Informationen von ihnen zu erhalten und entsprechend auf Feedback reagieren.
6. Product Hypotheses – We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact: Ohne Daten können wir nur raten. Unsere Aufgabe ist es, dem Kunden einen Mehrwert zu bieten. Die Behebung von Fehlern oder das Hinzufügen von Funktionen, die für den Kunden nicht wichtig sind, ist reine Zeitverschwendung. Daten sind notwendig, um aus „Produktanforderungen“ die tatsächlichen Bedürfnisse der Kunden zu ermitteln. Daten können genutzt werden um die richtige Entscheidung zu treffen.
7. Embrace the Fear – We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist: Einer der umstritteneren Grundsätze. Man sollte darauf hinarbeiten, sich selbst „überflüssig“ zu machen. Wenn das Testen nur von Testern durchgeführt wird, ist es ein Flaschenhals. Wir müssen das gesamte Team dabei unterstützen, bessere Tester zu werden. Deshalb müssen wir andere Teammitglieder aktiv im Testen coachen. Erst muss ein hoher Reifegrad in einem Unternehmen erreicht werden, dann kann es offensichtlich werden, dass keine dedizierten Testspezialisten mehr benötigt werden. Es macht den Tester damit nicht überflüssig sondern schafft nur ein obsoletes Rollenbild ab. Das ist etwas, das man nicht fürchten, sondern als Fortschritt betrachten sollte.

 

Die Rolle des Quality Advocates

In diesem Kontext hat sich eine neue Rolle herausgebildet: die des Quality Advocates. Ein Test Advocate ist mehr als nur ein Tester, in dieser Rolle steht man als Botschafter für Qualität im gesamten Entwicklungsprozess ein. Die Hauptaufgabe eines Quality Advocates besteht darin, sicherzustellen, dass das Team ständig bestrebt ist, hochwertige Software zu liefern, und dass Qualitätsaspekte in allen Phasen des Entwicklungszyklus berücksichtigt werden. Vor allem in Teams, in denen es deutlich mehr Entwickler als Tester gibt, müssen die Tester diese Rolle übernehmen, weil die Anzahl der Funktionen nicht zu bewältigen ist.

 

Erwartungen und Eigenschaften eines Quality Advocates:

• Tester ist nicht mehr allein für die Qualität verantwortlich
• Die Aufgaben beschränken sich nicht auf das Testen
• Eine Qualitätskultur fördern
• Sicherstellung einer angemessenen automatisierten Testabdeckung auf der Unit und Integration Ebene
• Jeder ist für die Qualität verantwortlich

Abschließend möchte ich ein passenden Zitat von Aristoteles hinzufügen, das die Essenz der Qualität und ihres ständigen Strebens einfängt:

“Quality is not an act, it is a habit.”

Qualität ist kein isoliertes Ereignis, das am Ende eines Projekts oder Entwicklungszyklus auftritt. Vielmehr ist es eine kontinuierliche Haltung und ein Verhaltensmuster, das jeden Schritt des Prozesses durchdringt. Tester und Entwicklungsteams sollten sich bemühen, Qualitätsstandards in ihre tägliche Arbeit zu integrieren, indem sie kontinuierlich nach Verbesserungen streben.