Leadership im Test: Testen als Team

Manchmal kann es sogar bedeuten, dass es gar keine Tester mehr gibt (dun-dun-duuu), sondern BAs und Entwickler die volle Verantwortung für das Testen übernehmen.

Shift-left ist nicht neu – Testbefürworter predigen das Mantra „früh testen, häufig testen“ seit vielen Jahren. Schon 1993 wurde vorgeschlagen, dass alle Artefakte eines phasenorientierten Prozesses – sowohl Dokumentation als auch Software – getestet werden könnten (und oft sollten).

Shift-Left bedeutet vor allem, die Testüberlegungen früher im Prozess zu berücksichtigen.

Obwohl damals das Wasserfallmodell der dominierende Lebenszyklus war, ist die Anzahl oder die Länge der Phasen nicht entscheidend. Das Grundprinzip lautete, dass die Wissensquellen, die Design und Entwicklung einer Software leiten, kritisch hinterfragt oder getestet werden sollten. 

In einem phasenbasierten Projekt kann dies formale Reviews bedeuten. In agilen Projekten kann der Tester (oder Entwickler oder BA oder Nutzer) Szenarien vorschlagen, die den Autor einer Anforderung oder Story dazu bringen, konkrete Beispiele zu durchdenken und vor dem Schreiben von Code zu besprechen.

Diese wichtigsten Veränderungen bringt das Shift-Left-Prinzip mit sich:

1. Der Behavior Driven Development (BDD)-Ansatz ermöglicht Entwicklern, Nutzern/BAs und Testern, sich gemeinsam zu sogenannten Business-Stories auszutauschen. Test-Driven Development wird von vielen Entwicklern bereits seit 15 oder mehr Jahren genutzt. Heute setzt sich BDD breiter durch, weil es die bessere Zusammenarbeit im agilen Team fördert und BDD-Tools eingeführt wurden, die auch von Entwicklern eingesetzt werden können. Es ist ein leichterer Test-First-Ansatz.
2. Continuous Delivery (CD) gibt es seit 5-10 Jahren und seine Ursprünge liegen in hochautomatisierten Build- und Release-Prozessen, die von großen Onlineunternehmen vorangetrieben wurden. Heute wird CD bei den meisten Unternehmen mit Onlinepräsenz eingesetzt.
3. CD systematisierte und beschleunigte die Release-Prozesse durch Automatisierung. Gleichzeitig wurden die Verzögerungen in Produktion, Deployment und Änderung der Infrastruktur sichtbar, die vorher durch langsame Build-, Test- und Release-Prozesse verdeckt wurden. DevOps ist ein kultureller Mindsetwandel, bei dem Entwickler deutlich enger mit den Betriebsteams zusammenarbeiten. Momentan erscheinen fast täglich neue Tools und Anbieter bewerben DevOps als das „nächste große Ding“. Es ist eine sehr gehypte und dynamische Entwicklung.
4. SMAC, also Social, Mobile, Analytics und Cloud, steht für einen Wandel, wie Unternehmen Geschäfts- und Systemänderungen im Mobilbereich steuern. Experimente im Business – durch produktive Systemänderungen umgesetzt – werden detailliert überwacht. Die so erhobenen „Big Data“ werden verarbeitet und Geschäftsentscheidungen basierend auf der erhaltenen Analyse getroffen.

Regelmäßige Experimente mit Produktionssystemen ermöglichen Innovationen im Business „mit der Geschwindigkeit des Marketings“. Experimentieren bildet den Kern der wohl wichtigsten Trendwende der 2010er Jahre – der Digitalen Transformation.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

Facebook

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Testen als Aktivität, nicht als Rolle

Shift-left verändert die Rolle der Tester. Die durch Shift-left ausgelöste Neuverteilung des Testens zeigt deutlich: Tester sind nicht mehr allein für das Testen verantwortlich – das heißt, Tester „besitzen“ das Testen nicht mehr allein. 

Wenn man darüber nachdenkt, haben sie eigentlich nie wirklich das Testen besessen, aber es gab ein stillschweigendes Verständnis in Projekten, dass egal, was der Rest des Teams, insbesondere die Entwickler, beim Testen tat, die Tester ein Sicherheitsnetz boten. Wenn Entwickler unter Zeitdruck standen und ihre Tests zur Auslieferung reduzierten, sorgten die Tester für das Sicherheitsnetz.

Testen ist jetzt eine Tätigkeit, keine Rolle.

Entwickler übernehmen bessere Testpraktiken und schaffen mehr Transparenz in ihrer Arbeit. Gutes Komponententesten oder Unit-Testing hat spezifische Ziele, die sich beispielsweise von Systemtests deutlich unterscheiden. Daher kann der Umfang (oder die Menge) an Systemtests reduziert werden. 

Die richtige Verteilung der Testziele und das Testen zu deren Erreichung ist der Hauptzweck der Teststrategie. Leider wurden Entwickler bis vor Kurzem nicht wirklich zur Verantwortung gezogen, weshalb sie sich auf späte Systemtests als Ausgleich verlassen haben.

Shift-left macht Entwickler verantwortlicher.

Insgesamt wird die Verantwortung für das Testen neu verteilt, sodass sich die Rolle des Testers verändert. Tester führen möglicherweise weniger taktische Tests durch, aber ihr strategischer Beitrag wächst. Tester könnten die Teststrategie übernehmen, Anforderungen hinterfragen, Stakeholder beraten und eine engere Beziehung zu den Entwicklern aufbauen, um besseres Entwicklertesten und Testautomatisierung zu unterstützen.

Eine neue Rolle

Shift-Left bedeutet, dass immer dann, wenn es möglich ist, Feedback zu geben, das dem Team hilft, Ziele, Anforderungen, Design oder Umsetzung zu verstehen, zu hinterfragen und zu verbessern, dieses Feedback auch gegeben werden sollte. 

Nutzer, Business-Analysten, Entwickler und das gesamte Softwareteam sollten bereit sein, auf diese Weise Feedback auszutauschen. Manchmal gibt es Widerstände, aber das übergeordnete Ziel ist es, ein besseres und informierteres Projekt durchzuführen – das ist alles.

Das einfachste Mittel, dieses Verhalten zusammenzufassen, ist: ‚Frühzeitig einsteigen‘ – so früh wie möglich. Beteilige dich an der Diskussion und arbeite an Ideen und Anforderungen mit, sowie auf jeder Ebene, auf der das Ergebnis einen Einfluss auf den Wert des finalen Projektergebnisses hat. 

Einfach gesagt: Der Tester hinterfragt Wissensquellen, egal ob diese Stakeholder, Benutzer, Entwickler, User Stories, Dokumente oder Präzedenzfälle sind.

Der gängigste Ansatz ist das Hinterfragen durch Beispiele. In allen Phasen können diese Beispiele als Tests betrachtet werden. Sie könnten nach der Verwendung schnell verworfen oder in Testautomatisierung oder manuelle Checks überführt werden. Diese Beispiele könnten einfach dafür genutzt werden, um Denkfehler aufzuzeigen, oder den Entwicklern, beispielsweise, als Ideen oder Ausgangspunkt für Entwicklertests dienen. Sie könnten auch als Coaching-Mittel verwendet werden, um Benutzern oder Entwicklern zu zeigen, wie bessere Tests erstellt werden können.

Stellen Sie sich Ihr Softwareprojekt als Wissenssammlungsprozess vor. Dieses Wissen wird über das Projekt hinweg gesammelt und verändert sich oft im Laufe der Zeit. Das Ziel von Shift-Left ist es, dieses Wissen durch Hinterfragen und Testen möglichst nahe an seiner Quelle abzusichern und nach Möglichkeit dafür zu sorgen, dass es vertrauenswürdig ist, bevor es im Code festgeschrieben wird.

Shift-Left geht über die Test-First-Philosophie hinaus. Agile hat schon immer Zusammenarbeit und schnelles Feedback gefördert – Shift-Left kann als gezielter, schneller Feedback-Ansatz verstanden werden. Wenn Ihr Team einen Shift-Left-Ansatz beim Testen verfolgt, können die richtigen Werkzeuge den entscheidenden Unterschied machen. Schauen Sie sich unsere kuratierte Liste der besten Softwaretest-Tools an, um das Beste für Ihr Team zu finden.

Agile Test-Interventionen

Der Shift-Left-Ansatz ist grundlegend für eine Teststrategie in agilen Projekten. Im agilen Kontext kann Teststrategie als eine Reihe von Test-Interventionen verstanden werden. In jedem Projekt gibt es kritische Momente, in denen es Gelegenheiten gibt, Feedback zu sammeln und zu geben. Der Tester sollte sich auf diese kritischen Momente konzentrieren und dann bereit sein, zu unterstützen.

In Ihren eigenen Projekten müssen Sie kritische Momente erkennen, in denen eine Intervention möglich ist, und die Optionen identifizieren, die Sie beim Testen als Team haben. Soll der Tester zum Beispiel Unit-Tests für Entwickler schreiben, Beispiele liefern, um ihnen den Einstieg zu erleichtern, oder sie coachen, um ihre Testfähigkeiten zu verbessern? Nur Sie und Ihr neues Softwaretest-Team können diese Entscheidung treffen.

Wir werden einen typischen Scrum-Prozess verwenden, um zu demonstrieren, wie Testinterventionen im Scrum-Ansatz verortet werden können. Interventionen finden entweder auf Projekt- (bzw. Release-) Ebene oder auf Sprint-Ebene statt. Das nachfolgende Schaubild zeigt eine Projektübersicht und die fünf wichtigsten Interventionen.

Story-Herausforderung und Story-Definition sind die Punkte, an denen der Tester eine User Story und die vorgeschlagenen Akzeptanzkriterien für eine Story prüft. Integrationstests überprüfen, ob neue Funktionen korrekt mit anderen Funktionen und dem Gesamtsystem verknüpft sind. System- und User- (Abnahme-) Tests werden entsprechend durchgeführt.

Ein Projekt hat normalerweise mehrere Sprints und die vier Sprint-Interventionen sind im folgenden Diagramm dargestellt. Das tägliche Stand-up-Meeting ist eine Gelegenheit, Fortschritte zu berichten, Bedenken zu äußern, Risiken zu identifizieren oder über Fragen und Antworten zu sprechen, die während des Sprints aufkommen. 

Story-Überarbeitung und Beiträge zum Entwicklertesten sind tägliche Aufgaben, die im Rahmen von Gesprächen mit Benutzern, Analysten und Entwicklern stattfinden. Der Tester integriert Entwickler- und neue Systemtests in eine wachsende Sammlung von automatisierten Tests.

In der nachstehenden Tabelle finden Sie eine tabellarische Zusammenfassung der Eingriffe durch Tester. Ihr Ablauf kann anders aussehen oder auf Scrum mit Abweichungen basieren, aber die Tabelle benennt typische Arten von Eingriffen in einem typischen Scrum-Prozess. Möglicherweise sind bei Ihnen zu unterschiedlichen Zeitpunkten mehr oder weniger Eingriffe aktiv.

Ich empfehle Ihnen, die entscheidenden Momente zu erkennen, Ihren Beitrag vorzuschlagen und diesen mit Ihrem Team abzustimmen. Sie bieten mehr Test-Führung und Anleitung an, statt sich nur für die Übernahme der Testaufgaben zu melden. Dieser Ansatz erleichtert es, Ihren Wert für das Team aufzuzeigen, allerdings benötigt das Team unter Umständen weniger Tester.

Beziehungen zu Entwicklern

In manchen Organisationen ist das Verhältnis zwischen Entwicklern von Misstrauen, Schuldzuweisungen und Gegensätzlichkeit geprägt. Im schlimmsten Fall ist die Beziehung toxisch: Entwickler testen kaum und Tester werden als Dienstleister der Entwickler angesehen. Tester nehmen sogenannte co-abhängige Verhaltensweisen an und sehen sich als Opfer. Genau diese Situation soll mit dem Shift-Left-Ansatz vermieden werden.

Es gibt viele Metaphern, die ein gutes Entwickler-Tester-Verhältnis beschreiben. Wir verwenden die Zusammenarbeit im Stil von Pilot und Navigator, um zu verdeutlichen, wie das Verhältnis zwischen Entwicklern und Testern aussehen kann. Schauen wir uns zunächst eine dysfunktionale Situation an.

Der Navigator steigt nicht ins Flugzeug, sondern winkt dem Piloten beim Start zu. Der Navigator fährt mit dem Bus, getrennt, aber langsam. Schließlich kommt der Navigator am Ziel an, doch nach einiger Zeit stellt sich heraus, dass das Flugzeug in die falsche Richtung geflogen und in einen Berg geprallt ist.

Hätte der Navigator nicht im Flugzeug sein sollen? Stellen Sie sich vor, wie Piloten und Navigatoren in Wirklichkeit zusammenarbeiten.

• Der Pilot kann das Flugzeug ohne Navigator nicht fliegen. Der Navigator kann das Flugzeug nicht fliegen.
• Pilot und Navigator stimmen den Flugplan ab, bevor die Reise beginnt.
• Der Pilot startet und fliegt das Flugzeug.
• Der Navigator verfolgt den Kurs und gleicht ihn mit dem Flugplan oder Zielort ab, wobei er unerwartete Ereignisse – insbesondere das Wetter – berücksichtigt.
• Der Navigator sucht nach Abweichungen, legt einen neuen Kurs fest und informiert den Piloten, der den Flugkurs anpasst.
• Und so weiter.

Das Verhältnis zwischen Pilot und Navigator ist mit dem Verhältnis zwischen Programmierer und Tester vergleichbar. Es macht auch keinen Sinn, Entwickler und Tester in getrennte Teams einzuteilen, die nacheinander arbeiten. Trotzdem haben wir es über rund dreißig Jahre hinweg auf diese Weise gehandhabt – insbesondere in größeren, langfristigen Projekten.

Shift-Left verteilt das Nachdenken über Tests neu und bringt es effektiv nach vorne. Tester sind gleichberechtigte Partner der Entwickler, genauso wie Navigatoren für Piloten:

• Tester und Entwickler sammeln gemeinsam Informationen zu Anforderungen.
• Typischerweise hinterfragen Tester Anforderungen durch Beispiele (potenzielle oder tatsächliche Testideen).
• Der Entwickler denkt über die Umsetzung nach und nutzt Beispiele, um seiner Konzeption eine Richtung zu geben.
• Tester, Entwickler, Stakeholder, Nutzer und Analysten einigen sich auf ein gemeinsames Verständnis einer vertrauenswürdigen Anforderung.
• Der Tester steht im ständigen Austausch mit dem Entwickler, diskutiert Änderungen der Anforderungen, Fehler-Risiken und wie Tests zeigen können, dass Funktionen funktionieren oder Fehler aufdecken.
• Der Tester prüft, wie sich das bearbeitete Feature sowohl technisch als auch in Bezug auf die Nutzerreise integriert und wie Integration getestet werden kann.
• Der Tester blickt über das unmittelbare Feature hinaus, an dem der Entwickler arbeitet, um zukünftige Herausforderungen, Risiken, Änderungen und Unsicherheiten zu identifizieren.
• Und so weiter.

Die beschriebene ideale Entwickler-Tester-Beziehung entsteht nicht automatisch. Das Team muss sie gemeinsam erarbeiten. Sie können jede der obigen Aktivitäten als Intervention betrachten, doch Interventionen sind für die Beteiligten nicht immer angenehm. Geben Sie diesem Ansatz die besten Erfolgsaussichten, indem Sie jede Eingriffsart schon zu Beginn – sobald klar ist, dass Sie eng zusammenarbeiten werden – mit Ihren Partnern besprechen.

Interventionen sind wie gute User Stories – sie dienen als Auslöser für Gespräche.

Jede Art von Eingriff benötigt das Einverständnis beider Seiten, dass sie sinnvoll ist. Damit alle sich wohlfühlen, muss gegenseitiges Vertrauen bestehen, dass es einen guten Grund gibt, Fragen zu stellen, Themen zu benennen und Anforderungen oder Verständnis in Stand-up-Meetings, Planungssitzungen oder Retrospektiven zu hinterfragen.

Herausforderungen verteilter und ausgelagerter Teams

In den obigen Diskussionen wurde stillschweigend angenommen, dass alle im gleichen Team arbeiten und am selben Ort sind. Wenn die Arbeitslast des Softwaretest-Teams ausgelagert und/oder ins Ausland verlagert wird, kommen mehrere negative Faktoren ins Spiel. Die Tabelle zeigt drei typische Faktoren, die zu berücksichtigen sind.

Einige Unternehmen verstärken bestehende Softwaretest-Teams, um Fähigkeiten für größere Projekte aufzubauen, oder beauftragen spezialisierte Testdienstleister, anstatt sich auf Auftragnehmer oder interne Anwender für das Testen zu verlassen. In anderen Situationen kann die gesamte Entwicklung und/oder das Testen an Lieferanten abgegeben werden. In allen Fällen muss das Kundenunternehmen seine Lieferanten steuern. Das bedeutet nicht, dass ein einschränkender Vertrag mit drastischen Strafklauseln ausreicht.

Wenn etwas schiefgeht, wollen Sie schnelle Reaktionen und Zusammenarbeit von Ihrem Lieferanten; Sie wollen nicht, dass dieser sich hinter juristischen Klauseln im Vertrag versteckt.

Die Geheimnisse des Erfolgs sind:

• Wenn Sie Ihren Lieferanten nicht steuern, steuert er Sie (wenn Sie keine vollständigen Partner sind und dem Lieferanten die Formulierung der Bedingungen überlassen, hält der Lieferant alle Karten in der Hand).
• Das Ziel ist, eine gute Arbeitsbeziehung zu definieren. Diese muss auf allen Ebenen etabliert werden – zwischen Stakeholder, Manager und Praktiker.
• Verträge sollten so formuliert sein, dass alle Verantwortlichkeiten auf beiden Seiten benannt werden, mit geeigneten Maßnahmen, Schwellenwerten, Zwischenzahlungen und Abnahmekriterien, um gutes Verhalten (auf beiden Seiten der Vereinbarung) zu fördern.
• Vereinbarungen sollten Offenheit und die gemeinsame Zielsetzung für Projekterfolg fördern.

Denkanstöße

Abschließend noch einige Fragen, die zum Nachdenken anregen sollen. 

Welche Beziehung haben Sie als Tester zu Ihren Entwicklern? Oder, wenn Sie als Entwickler dies lesen: Wie ist Ihr Verhältnis zu den Testern? Fragen Sie vielleicht Ihre Kollegen aus Entwicklung oder Test, wie sie Ihre Beziehung beschreiben würden. Vergleichen Sie die Meinungen!

Damit Softwaretest-Teams produktiv sind, müssen sie kommunizieren und zusammenarbeiten.