- Advertisement -spot_img
HomeAgilAgiles Entwickeln und Testen - ein Widerspruch?

Agiles Entwickeln und Testen – ein Widerspruch?

- Advertisement -spot_img

Wie agile Arbeitsweisen die Zusammenarbeit effektiver machen

Agiles Entwickeln und Testen – ein Widerspruch?

von Jürgen Beniermann, Erhardt Wunderlich und Elke Mai

Der Artikel wurde auf der Basis eines Vortrages auf dem A4Q World Congress im April 2021 erstellt. Die Autoren hatten die Rollen von Projektleiter, Entwickler und Tester eingenommen und in spielerischer Weise aufgeführt. Aufgrund der besseren Lesbarkeit verzichtet die Reaktion darauf, die Inhalte in durchgehender Rede und Gegenrede zu übernehmen. Stattdessen wird die Vorlage auf feuilletonistische Weise veröffentlicht. Wir hoffen damit die reizvolle Stimmung des Vortrages wiederzugeben.

Es ist ein altes Problem, geradezu digital antik, die Trennung zwischen Test und Entwicklung. Der Tester will kein Entwickler sein. Der Entwickler kein Tester. Ist das wirklich so? Sollten wir die Produktion von guter Software nicht als einheitlichen Prozess sehen? Widerspricht Testen dem agilen Entwickeln, obwohl wir seit geraumer Zeit Methoden wie Continuous Integration, Continuous Delivery, Continuous Testing haben? Diese Fragen treiben Software Tester wie Programmierer seit Jahren um.

Bitte melden Sie sich an oder erstellen Sie ein Konto, um diesen Inhalt weiter zu lesen.

Der Herausgeber des SQ Magazins (die iSQI GmbH) verpflichtet sich, Ihre Privatsphäre zu schützen und zu respektieren. Wir verwenden Ihre persönlichen Daten nur zur Verwaltung Ihres Kontos und zur Bereitstellung der von Ihnen angeforderten Produkte und Dienstleistungen. Von Zeit zu Zeit möchten wir Sie über unsere Produkte und Dienstleistungen sowie andere Inhalte, die für Sie von Interesse sein könnten, informieren.
Sie können diese Benachrichtigungen jederzeit abbestellen. Weitere Informationen zum Abbestellen, zu unseren Datenschutzverfahren und dazu, wie wir Ihre Privatsphäre schützen und respektieren, finden Sie in unserer Datenschutzrichtlinie.

Eine konkrete Situation aus dem Alltag:

Mit rotem Kopf, etwas aufgelöst, kommt Projektleiterin Elke ins Büro. „Der Kunde hat angerufen! Die Software funktioniert nicht. Die ganze Produktion steht still.“ Elke schaut Jürgen an. Jürgen schaut Elke an. Elke: „Jürgen, warum funktioniert das Zeug nicht? Das kann doch nicht so schwer sein: Software starten, drüber gehen, reparieren!“ Jürgen ist seit vielen Jahren Software Tester. Er hat diesen Vorwurf hundertfach gehört, und nimmt ihn sich jedes Mal wieder zu Herzen. Entwickler Erhardt grinst. Elke zu Erhardt: „Du brauchst gar nicht so zu grinsen. Du hast den Mist doch erst zusammengehackt. Wenn du vernünftig programmieren würdest, hätten wir die Probleme gar nicht!“ Nun hat der Entwickler ebenfalls sein Fett abgekriegt. Entwickler und Tester wissen genau, woran es liegt, dass Software doch nicht so läuft, wie sie sollte. Meistens zumindest. Es liegt an schlechten Requirements. Das Briefing ist falsch. Der Kunde bestellt Dinge, die er am Ende nicht haben will. Darüber zu streiten ist müßig. Menschlich! Es gibt Situationen, die wiederkehren. Immer gleich. Kein Streit hilft, kein Vorwurf, kein Plan. Dass etwas schiefgeht, kann bei jedem Projekt passieren. Und dann ist guter Rat teuer. Oder eine andere Arbeitsweise. Agiles Vorgehen kann ein Weg aus dem Dilemma sein. Agil heißt jedoch nicht chaotisch. Es heißt im Team geplant und systematisch vorzugehen und dabei vor allem eines zu tun: Frühzeitig kommunizieren. Big Pictures, also Übersichten, die vom gesamten Team verinnerlicht werden, schwören auf einen gemeinsamen Weg ein. Dass das beim Software Testen funktioniert, ist kein Märchen. Es geht. Zum Beispiel mit agilen Testquadranten.

Agilität in Quadranten

Das Prinzip agiler Testquadranten beruht auf zwei Achsen. Die vertikale Achse zeigt die technischen und die fachlichen Herausforderungen an. Die zweite Achse, die horizontale, zeigt links an, wie das Produkt gebaut wird und rechts, ob das Produkt nach der Herstellung überprüft wird. Kurz: Links liegt der Plan und rechts, ob es geklappt hat. Die Achsen teilen das Bild in vier Quadranten. Oben rechts sind die Tests, die manuell durchgeführt werden. Oben links wird notiert, was vom Kunden gewünscht wird: Dort stehen die Prototypen und die User Stories. Unten links geht es in die Technik. Hier werden zum Beispiel automatisierte Unit Tests dargestellt. Der letzte Bereich unten rechts sind technische Test, die das Produkt bewerten, das wären zum Beispiel Tools wie Performance Testing oder Security Testing.

Soweit die Theorie!

Blickt man auf das Bild, könnte man meinen, dass Technik und Testen die größeren Schwierigkeiten machen. Dass jedoch oft gerade fachliche Bereiche, also die Bereiche oben links, wo es um Kunden und Absprachen geht, viel haariger sind, wurde (und wird) unterschätzt. Der Kunde bestellt eine kleine App zum schnellen Einscannen von Dokumenten und ausgeliefert wird der „Mercedes unter den Scan–Apps“! Mit Funktionen, die gar nicht gebraucht werden. Da geht es vor allem um Kommunikation – bzw. um Kommunikation, die nicht funktioniert. Wie beim Spiel „Stille Post“ verändert sich Bestellung von Besprechung zu Besprechung. Sehr oft passiert auch etwas Magisches. Der Kunde bestellt den Mercedes, braucht aber nur einen Kleinwagen. Und das erkennt er erst, wenn er den Mercedes fährt. Deshalb sind User Stories und eine schnelle Auslieferung von Prototypen so wichtig. So kann der Kunde gezielt steuern und umgekehrt, der Kunde vernünftig beraten werden.

Das Stichwort ist Test Driven Development

Mit dieser Methode werden Fehler so früh abgefangen, dass Zeit für wichtigere Dinge frei wird. Testen wird in verschiedene Stufen aufgeteilt und so der beste Test zur richtigen Zeit angesetzt. Je nachdem, was man testen möchte, wie genau man das testen möchte oder wie viel Zeit man zum Testen hat, gibt es verschiedene Methoden. Manche Methoden werden vom Tester genutzt, andere vom Entwickler. Agile Testquadranten helfen dem Team, sich besser zu organisieren. Schlicht gesagt haben alle im Team ihren eigenen Bereich. Die Projektleiterin Elke macht die fachlichen Absprachen (links oben). Entwickler Erhardt sieht seine Aufgaben eher links unten und Tester Jürgen konzentriert sich auf oben links. Was dann noch fehlt, ist Teamarbeit – und zusätzliche Unterstützung. Denn im Bereich unten rechts, wo beispielsweise Performance Testing eingesetzt werden muss, da ist das Team ziemlich blank. Für alles, was im Team nicht abgedeckt werden kann, wird Hilfe von außen dazu geholt. Durch das strukturierte Arbeiten entwickelt sich – fast von allein – ein Testprozess, der sich in unterschiedlichen Projekten immer wieder bewährt.

Was läuft im Vergleich zu vorher anders?

Die Reviews auf die User Stories zeigen schnell, ob sich das Team verzettelt hat. Sogar Entwickler Erhardt ist davon beeindruckt: „Das hilft nicht nur manuell bei den User Stories. Wir haben auch für alles andere Werkzeuge gefunden, die uns viel Arbeit abnehmen. Da sehen wir gleich, ob in unseren Modellen oder im Code etwas nicht passt.“ Wo früher wenige Tests verwendet wurden, setzt die Truppe heute eine Palette unterschiedlicher Testverfahren ein. Viele der Tests werden speziell programmiert und Entwickler Erhardt muss sich anschließend um nichts mehr kümmern. Viele Schritte laufen automatisch. So wird eine große Zahl Fehler gefunden. Die gewonnene Zeit kann zum Beispiel in erfahrungsbasierte Verfahren, die qualitativ wertvoller sind, investiert werden. Die Aufgaben für Tester und für Entwickler können variabler verteilt werden. Wo der Tester Zeit gewinnt, profitiert der Entwickler. Der Austausch von Wissen hilft beim Programmieren. So gibt es Fehler, die erfahrungsgemäß auftauchen und die der Entwickler beim Aufbau der Software einkalkulieren kann. Er achtet darauf, ob diese Fehler im laufenden Projekt passieren können – und baut vor. Durch die Sammlung von Methoden und die Dokumentation erfolgreicher Testdurchgänge zeigen sich die Stärken unterschiedlicher Tests. So können Anweisungs- und Entscheidungstests oder modifizierte Bedingungs- /Entscheidungstest viel gezielter eingesetzt werden.

Schön und Gut!

Im eigenen Team flutscht alles nun geschmeidig. Die Arbeit ist effizient, der Kunde ist zufrieden, die Arbeit macht Spaß. Wenn es bloß noch eine Medizin gäbe, die man anderen Teams verabreicht, damit auch sie das agile Mindset aktivieren. Naja! Man könnte sagen, so etwas gibt es schon. Es sind zwar keine Pillen, dafür ein Ausbildungsplan. Agiles Arbeiten sowie agiles Testen kann man lernen. Die Kooperation aus German Testing Board und der Alliance For Qualification zum Beispiel bietet einen Lehrplan an, der nicht mehr nur Anweisungen für Tester enthält, sondern nun den gesamten Prozess für Software und alle Beteiligten mit einschließt. In Theorie und Praxis, mit Anleitungen, Übungen und sogar Code wird geschrieben. Und wer den Sack zumachen will, schließt das Lehrprogramm mit einem Zertifikat Testing Foundations for Developers ab.

Das Bürotelefon klingelt!

Der Projektleiterin Elke hebt ab: “Guten Tag Herr Meyer. Wie geht es Ihnen? Okay! Das Programm läuft? Sie verlängern den Vertrag bis Ende 2025? Das geht!” Alles wird gut!

[/content_control]
Artikel teilen
- Advertisement -Certified DevOps Portfolio
Neueste Artikel
Weitere interessante Artikel
- Advertisement -spot_img