Lineares Abarbeiten von starren Entwicklungsprozessen oder das Wasserfallmodell sind von gestern. Scrum und „Behaviour Driven Developement“ (BDD) bringen frischen Wind in Unternehmen und sind für Viele weit mehr als kryptische Abkürzungen und Begriffe. Oder doch nicht? Beim Agile Testing Day stand alles unter dem Motto: schnelles Feedback, aber wie? Wie können Testverfahren so in den Entwicklungsprozess integriert werden, dass Fehler schnell entdeckt werden können?

Viele Methoden der agilen Software-Entwicklung befinden sich noch in den Kinderschuhen – Fragen und Probleme kommen erst mit der Zeit auf. Wie gestaltet sich die konkrete Umsetzung, vor allem in einem Team von vielen Leuten mit ganz unterschiedlichen Erfahrungen und Vorstellungen? In den Talks von Frank Düsterbeck (HEC GmbH), Carlos Barragan (NovaTec Consulting GmbH), Ina Einemann (HEC GmbH), Kay Grebenstein (Saxonia Systems AG), Christian Wende und Mirko Seifert (beide DevBoost GmbH) wurde die bessere Integration von Testverfahren in die Software-Entwicklung lebhaft diskutiert. Wann sollte getestet werden? Braucht man überhaupt einen Testmanager? Welche Voraussetzungen müssen in einem Team geschaffen werden, um Ziele zu erreichen?

„Testen ist keine Phase“

Frank Düsterbeck verdeutlichte in seinem Vortrag zu Testverfahren in Scrum, warum es wichtig ist, Testverfahren eben nicht als separates Modul in der Projektplanung zu sehen, sondern in den Prozess zu integrieren. Sie sollen parallel zu allen anderen Prozessen der Softwareentwicklung laufen, um Fehler möglichst schnell zu entdecken. Denn welcher Entwickler kennt das nicht: Fixt man nachträglich an der einen Stelle etwas, geht am anderen Ende wieder etwas schief. Und auch wenn der Kunde erst mal mit der ausgelieferten Software zufrieden ist, die sogenannte externe Qualität also stimmt, so muss das nicht heißen, dass auch die interne Qualität auf der Entwicklungsseite in Ordnung ist.

In einem idealen Team funktioniert die Qualitätssicherung also auf allen Ebenen: „Wenn ich mein Scrum Team aufgebaut habe, dann machen die alles“, so Düsterbeck.

Auch Carlos Barragan zeigte schnelle Testverfahren. Als erfolgsversprechenden Ansatz stellte er das Bean-Testing vor. Dieses ist zum Testen von Java-EE-Anwendungen von Nutzen, da es zeitaufwändige Testverfahren überflüssig macht. Dass es sich dabei um ein Open-Source-Projekt handelt, macht die Sache von Seiten der Entwickler besonders spannend. Barragan demonstrierte live, dass Bean-Tests eben nicht laufen, in Fällen, in denen ein Unit-Test aber beispielsweise läuft. Das Warum liegt laut Carlos Barragan auf der Hand: Probleme, die man nur mit bestimmten Tests erkennen kann, können durch das Bean-Testing in nur einem Schritt gefunden werden. Das zeitaufwändige Durchlaufen vieler Tests hintereinander wird damit also obsolet.

Step by Step

In seinem Vortrag schlug Carlos Barragan den selben Ton an, wie auch Frank Düsterbeck: Software sollte nicht erst seitenlang dokumentiert werden, um dann den Wald vor lauter Bäumen nicht mehr zu sehen und nicht zu erkennen, was jetzt zu tun bzw. zu testen ist. Dadurch, dass man nicht versucht, das große Ganze zu übereilen, sondern Schritt für Schritt in sich funktionierende Pakete schnürt, kann die Komplexität heutiger Software- und Systemlandschaften und der starke Anstieg der Anforderungsdynamik bezwungen werden.

Auch im Vortrag von Ina Einemann stand alles unter dem Motto: Wie kann Kommunikation verbessert und „Behaviour Driven Development (BDD)“ als agile Methode umgesetzt werden? In einer lebhaften Darstellung aller möglichen Akteure bei der Umsetzung von BDD stellte sie die Probleme und die Hürden bei der Umsetzung dieser agilen Methode vor. Wie überzeuge ich mein Team? Was muss ich bei der Einführung von BDD in bestehende Projekte beachten?

Das geht nicht von heute auf morgen! Damit knüpfte sie an die Vorredner an: Agiles Testen ist in seiner Umsetzung nicht so trivial, wie es auf den ersten Blick vermutet werden könnte, sondern erfordert ein Umdenken im gesamten Projektteam. Auch Christian Wende und Mirko Seifert (DevBoost GmbH) zeigten in ihrer Session die Herausforderungen einer nahtlosen Integration der Qualitätssicherung auf.

Wer ist für die Qualität verantwortlich?

Mit den Worten von Kay Grebenstein soll die Botschaft des Tages zusammengefasst werden: „Wer ist für die Qualität verantwortlich? Wir alle!“ Er schlug vor, nicht mehr von klassischen Testmanagern zu sprechen, die eine Einheit außerhalb des Teams bilden, sondern vom Tester als Teil des Teams. Natürlich ist jeder Spezialist in seinem Gebiet. Ganz im Sinne von Agile sind aber alle Teammitglieder verantwortlich für den Erfolg einer Software – egal, ob sie sich PO, Entwickler, Scrum Master oder eben Tester nennen. Eigentlich ganz einfach, oder?