Get in touch


We use HubSpot CRM to process and manage contact and information requests. Please accept the "Functional Cookies" and reload the page to load the contact form.

Insights / Blog / Agilität & Organisation

Testet Ihr Team noch nach dem Wasserfallprinzip oder schon agil?

31. August 2021

Software testen? Ist doch immer das Gleiche! Wenn Ihr Team nur vom Ziel ausgeht („Das beste System für den Kunden entwickeln“), trifft dies vielleicht zu. Aber haben Sie dieses Ziel wirklich auch in jedem Kontext erreicht? Sicher nicht. Das Vorgehen kann einen Unterschied ausmachen. In der agilen Softwareentwicklung ist es machbar, frühes Feedback zum Produkt und zu den Prozessen zu bekommen. Möglich macht das der inkrementelle und iterative Ansatz.

Viele Teams entwickeln zwar ihre Software mittels agiler Vorgehensmodelle, doch der Testprozess unterscheidet sich in der letzten Konsequenz kaum vom traditionellen Procedere. In der agilen Softwareentwicklung verändert sich jedoch das Testen von Grund auf: Softwaretester:innen können von Beginn an im Software-entwicklungsprozess mitwirken. So kann ein Entwicklungsteam die folgenden fünf agilen Testwerte nutzen, um gemeinsam ein Produkt zu entwickeln, das der Kunde lieben wird.

1. Phase vs. Aktivität

In der traditionellen Softwareentwicklung ist das Testen in der Regel eine Phase, die Tester:innen nach der Implementierung ausführen. Dies hat unter anderem oft den Nachteil, dass Engpässe entstehen.

In der agilen Softwareentwicklung wird empfohlen, Softwaretesten als eine Aktivität zu betrachten. Diese startet nicht erst nach der Implementierung, sondern gleich zu Beginn des Softwareentwicklungsprozesses – angefangen bei den Anforderungen, im agilen Kontext den User Stories. Diese sind ein Modell der realen Welt und können:

  • die reale Welt richtig abbilden,

  • von der realen Welt abweichen,

  • oder unklar definiert sein.

Aufgabe des agilen Teams ist es, abweichende und unklare Anforderungen zu identifizieren, bevor es die User Stories umsetzt. Des Weiteren gibt es viele Aktivitäten, die Tester:innen vor der Implementierung ausführen können, wie beispielsweise:

  • Vorbereitung der Testautomatisierung

  • Testdatenvorbereitung

  • Abweichung und Unklarheiten in den Anforderungen identifizieren

  • Identifizieren und Analysieren von Risiken

  • Implementierung der Mocks

  • Abstimmung mit anderen Teams bei Abhängigkeiten

  • Testentwürfe – Bspw. Charter für das explorative Testen schreiben

2. Fehlerfinden vs. Fehlervermeiden

Softwaretester:innen fokussieren sich im traditionellen Umfeld in der Regel darauf, Fehler zu finden. Im Gegensatz dazu wird beim agilen Ansatz empfohlen, die Fehlervermeidung zu priorisieren. Berücksichtigt man diesen Fokus, ist es empfehlenswert als Team mit den Anforderungen zu starten. Weichen die Anforderungen bereits gänzlich von der realen Welt ab, zieht sich dieser Fehler durch den ganzen Softwareentwicklungsprozess.

3. Checken vs. Testen

Bei der phasenorientierten Softwareentwicklung erhalten Tester:innen fest definierte Anforderungen. Hieraus leiten sie Testfälle ab, aus denen sich konkrete Handlungs-anweisungen ergeben. Nachfolgend haken Tester:innen diese Schritte listenartig ab und dokumentieren so ihre Testergebnisse.

Hauptbestandteil des agilen Softwaretestens ist es, das Produkt zu erforschen und Experimente auszuführen, um Annahmen zu bestätigen oder auch zu widerlegen. Die gesammelten Informationen dienen allen am Softwareentwicklungsprozess beteiligten Personen als Entscheidungsgrundlage. Ratsam ist es im agilen Softwaretesten den überwiegenden Anteil des Checkens mittels einer Testautomatisierung abzudecken. Warum? Die dadurch gewonnene Zeit gibt dem Team die Möglichkeit, sich auf die komplexeren Aspekte des Softwaretestens zu fokussieren.

Jakob Jaworski

AOE Academy Trainer für Software Testing / AOE
Unser Tipp: Don`t be a checker – be a tester!

4. Das System brechen vs. das beste System entwickeln

In herkömmlichen Entwicklungsprojekten implementieren die Entwickler:innen das System – und die Softwaretester:innen versuchen dies im Nachgang dann zu „brechen“. Dies führt oft dazu, dass Tester:innen und Entwickler:innen eher gegeneinander als miteinander arbeiten. Kritische Fehler in einer Software zu finden ist essenziell. Dies impliziert jedoch nicht, dass der Kunde die Software auch gerne nutzen wird. Eine Software, die beispielsweise nicht auf die Bedürfnisse des Kunden eingeht, werden auch Nutzer:innen in der Regel nicht annehmen und nur ungern verwenden.

Ein agiles Team sollte den Fokus darauf haben, ein Produkt zu entwickeln, dass Nutzer:innen lieben. Dies impliziert natürlich, kritische Fehler zu finden. Doch der Fokus liegt darauf, die Software hinsichtlich des Mehrwerts für Nutzer:innen zu hinterfragen. Im agilen Kontext hat dieser Gedankenwechsel einen großen Einfluss auf die Zusammenarbeit innerhalb des Teams und den produzierten Output. Dieser Punkt führt uns auch zum letzten Wert des agilen Testens.

5. Softwaretester:innen sind verantwortlich für die Qualität vs. das Team ist verantwortlich für die Qualität

Wie in dem Abschnitt „Phase vs. Aktivität“ erwähnt, führt das Softwaretesten im traditionellen Softwareentwicklungsprozess oft zu einem Engpass. Einer der Gründe ist, dass die oder der Softwaretester:in alleine für die Qualität verantwortlich ist.

In der agilen Softwareentwicklung sollte das ganze Team verantwortlich für die Qualität sein. Dafür muss jedes Teammitglied das Ziel verfolgen, das beste System für den Nutzer:innen zu entwickeln. Dieser Ansatz vermeidet Engpässe und führt dazu, dass sich alle Teammitglieder mit dem Produkt identifizieren.

Karen Greaves & Samantha Laing

Agile Coaches
Wenn ein Team glaubt, agil zu sein, aber nichts an der Art und Weise, wie es testet, geändert hat, dann gibt es noch viel zu lernen.

Fazit

Agiles Testing ist der zeitgemäße Weg, um in der modernen Softwareentwicklung schnellere und bessere Ergebnisse zu erzielen. Als Teil des Entwicklungsteams bei der agilen Software-Entwicklung bringen Tester ihr Spezialwissen von Anbeginn an direkt in den Entwicklungsprozess ein. Somit wird die klassische Trennung zwischen Testern und Entwicklern aufgelöst.

Dieser Artikel erschien zuerst auf "entwickler.de". Wir freuen uns über Ihr Feedback und das Teilen des Artikels.

Originalbeitrag auf entwickler.de