Forum Testmanagement:19.06.2008

__NOTOC__

==Testen bei agiler Software-Entwicklung==

Das "Forum Testmanagement" ist eine gemeinsame Initiative der Fachgruppe BW-Test im ASQF und der GI/ACM-Regionalgruppe Stuttgart/Böblingen.

Das Forum dient dem Erfahrungsaustausch zwischen Praktikern und interessierten Einsteigern zum Thema "Testmanagement". Jede Veranstaltung steht unter einem Schwerpunktthema. Den Anfang machen kurze Vorträge oder Diskussionsbeiträge. Den Rest des Abends nutzen wir zur vertiefenden Diskussion. Die Ergebnisse werden dokumentiert und im Wiki von BW-Test zur Verfügung gestellt.

Das nächste Treffen am 19. Juni 2008 steht unter dem Thema "Testen bei agiler Software-Entwicklung".

==Veranstaltungsdaten==

Datum: Donnerstag, den 19. Juni 2008

Beginn: 18:00 Uhr

Ort: Logica, Zettachring 4, Stuttgart (Fasanenhof) - [http://www.logica.com/germany-Logica/350236051 Anfahrtsbeschreibung]
Übersicht: [http://maps.google.de/maps?f=q&hl=de&geocode=&q=Zettachring+4,+Stuttgart&sll=48.726702,9.139396&sspn=0.006419,0.009398&ie=UTF8&ll=48.709587,9.170129&spn=0.003211,0.006738&t=h&z=18&iwloc=addr Google Maps]

Wir bitten für unsere Planung um eine kurze formlose Anmeldung. Bitte melden Sie sich bis zum 17. Juni per [mailto:bwtest.asqf@gmail.com?subject=Anmeldung_Forum_Testmanagement_19_06_2008 E-Mail] an. Die Teilnahme ist kostenlos. Eine Anmeldebestätigung wird nicht versandt.

==Agenda==

Das Treffen dient dem offenen Austausch zum Thema "Testen bei agiler Software-Entwicklung". Die ursprünglich für diesen Termin geplante Vorstellung von Projekterfahrungen aus der agilen Entwicklung ist auf den Herbst verschoben. Voraussichtlicher Termin: [[Forum Testmanagement:16.10.2008|16. Oktober 2008]].

18:00 - Begrüßung und Überblick über den Abend (Tanja Tremmel und Andreas Birk)

18:15 - Einführender Vortrag: "Was heißt hier agil? - Ein Briefing zur agilen Software-Entwicklung" (Andreas Birk, Software.Process.Management)

18:30 - Konferenzbericht "Testing & Finance 2008" mit drei Vorträgen zum Testen bei agiler Software-Entwicklung (Tanja Tremmel, Logica)

18:45 - Offene Diskussion zum Thema: Fragen, Eindrücke und Erfahrungen zum Testen bei agiler Software-Entwicklung

20:15 - Ende

anschließend Gelegenheit zur Fortsetzung der Gespräche im Hotel Restaurant Fora

==Zusammenfassung==

Agile Methoden sind in der Software-Entwicklung weit verbreitet. Viele Unternehmen verfolgen den Trend aufmerksam und prüfen den Einsatz der Verfahren. Während kleinere Entwicklungsvorhaben oft spontan Vorteile in der agilen Entwicklung sehen, begegnen größere Software-Projekte den neuen Vorgehensweisen mit einiger Skepsis. Insbesondere das Zusammenspiel zwischen Entwicklung und umfangreichen System- und Abnahmetests wirft Fragen auf. Das Forum Testmanagement der ASQF-Regionalgruppe BW-Test untersuchte diese Fragen in einer Diskussionrunde zum Thema "Testen bei agiler Software-Entwicklung" am 19. Juli 2008 in Stuttgart.

Einleitend gab Andreas Birk (Software.Process.Management) einen kurzen Überblick über agile Entwicklung und die Herausforderungen für das Testen. Danach berichtete Tanja Tremmel (Logica) von einer Konferenz mit Beiträgen zum agilen Testen und stellte die dort vertretenen Positionen und die berichteten Erfahrungen vor. Anschließend diskutierten die Teilnehmer in offener Runde und sprachen über ihre Erfahrungen aus agilen Projekten. Sie beschlossen, das Thema in Oktober-Veranstaltung des Forums Testmanagement (16. Oktober in Stuttgart) wieder aufzugreifen und zu vertiefen.

In der Diskussionsrunde wurde klar, dass Agile Methoden dem entwicklungsnahen Modultest einen hohen Stellenwert zukommen lassen und ihn gegenüber der traditionellen Entwicklung maßgeblich stärken. Die höheren Teststufen--vor allem Integrations-, System- und Abnahmetest--werden aber noch vielfach vernachlässigt. Oft stehen sie in einem Spannungsfeld zu den Entwicklungstätigkeiten. Die Diskussionsteilnehmer sammelten eine Reihe von Maßnahmen und Erfahrungen, wie man diesem Spannungsfeld begegnen und es abschwächen kann.

===Vortrag Andreas Birk===

Eine kurze Einführung in agile Software-Entwicklung präsentierte Andreas Birk. Er erläuterte das "Agile Manifesto", das die Leitgedanken der agilen Entwicklung zusammenfasst. Als Beispiel für das Vorgehen bei der agilen Entwicklung wählte er die Methode SCRUM, die heute wohl am häufigsten angewendet wird. Dabei erstellt das Projektteam die Software in inkrementellen Zyklen. Ein solcher Zyklus wird "Sprint" genannt und dauert typischerweise 30 Tage.

Zu Beginn eines SCRUM-Projektes definieren und priorisieren Auftraggeber und Entwickler die Anforderungen und stellen sie in ein sogenanntes "Product Backlog" ein. Daraus entnimmt das Projektteam die Anforderungen für ein Sprint und leitet daraus "Backlog Tasks" ab, also die Arbeitsaufgaben. Dabei werden auch die Tester zum ersten mal tätig. Gemeinsam mit den Entwicklern detaillieren und ergänzen sie die Anforderungen und Aufgaben.

Innerhalb eines Sprints spielen Tests eine große Rolle: Jede Entwicklungsaufgabe soll damit beginnen, dass der Entwickler die Tests für die zu neu zu erstellende Funktionalität definiert und dann erste mit der Programmierung beginnt ("Test-Driven Development"). Ein neues Modul muss erst die Entwicklertests durchlaufen (Unit-Tests), bevor es in das Software-System eingefügt wird. Die Zwischenstände des Systems werden mitunter täglich erstellt und automatisierten Tests unterzogen ("Continuous Build and Test"). Durch all diese Vorkehrungen scheint das Testen in die agile Software-Entwicklung umfassend und reibungsfrei eingebettet zu sein.--Gibt es dann überhaupt Herausforderungen für das Testen?

Die besonderen Herausforderungen für das Testen in der agilen Entwicklung liegen im Bereich des System- und Abnahmetests. Die in den agilen Methoden besonders betonten und unterstützten Testschritte spielen sich vorwiegend auf der Modul- und Entwickler-Ebene ab. Für den Systemtest ist es mitunter sehr schwierig, mit der agilen Entwicklung von neuen Funktionen Schritt zu halten. Meist kann der System- und Abnahmetest nur den Software-Stand des letzten abgeschlossenen Inkrements sinnvoll prüfen und hinkt somit immer einen Sprint-Iterationszyklus hinterher. Gefragt sind Erfahrungen und neue Methoden für das Testmanagement, so dass die höheren Teststufen besser in den aktuellen Sprint integriert werden können.

===Vortrag Tanja Tremmel===

Tanja Tremmel berichtet über drei Vorträge zum agilen Testen, die bei der Konferenz "Testing und Finance 2008" in Frankfurt präsentiert wurden.

Der erste Vortrag (Panchal, Garg und Kocher) analysierte, wodurch sich Testen in agiler Entwicklung von anderen Entwicklungsansätzen unterscheidet. Agile Entwicklung brächte einen anderen Stil des Testens mit sich. Ein zentraler Unterschied sei das Timeboxing für das Testen innerhalb einer Interation durch die strikten Zeit- und Aufwandsvorgaben für die Tests.

Bezüglich des Timeboxings warf der zweite Vortrag (Kain und Kramp) die Frage auf, ob alle definierten Tests in einer Iteration immer komplett durchgeführt werden müssten? Insbesondere in späteren Iterationen, in denen die Funktionalität der entwickelten Software umfangreich ist, wächst auch der Testaufwand stark an. Daher sei Testautomatisierung in der agilen Entwicklung essentiell.

Auch der dritte Vortrag (Böll) betrachtete Auswirkungen des Timeboxings. Die Entwickler können innerhalb einer Iteration die Features und Entwicklungsaufgaben kurzfristig umplanen. Die aktuelle Planung muss eng mit den Testern abgestimmt werden, was im Projektalltag oft Schwierigkeiten bereitet. Böll berichtete, von einem Projekt, in dem diese Schwierigkeiten mit speziellen Featurelisten und Einbeziehung der Entwickler in die Tests gemeistert wurden.

===Diskussion===

Im Mittelpunkt der Diskussionsrunde standen die höheren Teststufen Integrations-, System- und Abnahmetest. Die Teilnehmer stimmten darin überein, dass es bei diesen Tests schwierig ist, die Belange der Tests genügend gut mit den Entwicklungsaktivitäten im Einklang zu bringen. Die niedrige Teststufe der Entwickler-basierten Modultests ist dagegen bei den Agilen Methoden sehr ausgeprägt und in der Regel weitaus effektiver als bei den traditionellen, nichtagilen Entwicklungsverfahren.

Ein großer Vorteil der agilen Entwicklung--zum Beipiel nach der SCRUM-Methode--liegt darin, dass alle Projektbeteiligten durch die Sprints in den gleichen Arbeitsrhythmus eingeordnet sind. Auch sind der aktuelle Kontext der Tätigkeiten und die aktuellen Prioritäten für alle Mitarbeiter klar und transparent. Das hilft letztlich bei der Koordination der Aufgaben.

An Grenzen stößt diese Form der Koordination allerdings bei Aufgaben, die sich nicht direkt in den aktuellen Tätigkeitskontext einordnen lassen. Das ist insbesondere bei der Erstellung von Testinfrastrukturen für die höheren Teststufen wie Systemtest der Fall. Beispielsweise müssen lange vor den eigentlichen Tests Testfälle definiert, Testtreiber entwickelt und Testdaten beschafft werden. Dadurch beschäftigen sich Entwickler und Systemtester zum gleichen Zeitpunkt mitunter mit sehr unterschiedlichen Aufgaben. Auf diese Situation sind die typischen Koordinationsverfahren der Agilen Methoden nicht ausgelegt und es entsteht ein Spannungsfeld zwischen Entwicklung und Systemtest.

Das Spannungsfeld wir noch verstärkt, da die Tester neben dem Aufbau der Testvorbereitungen auch die aktuellen Trends in der Entwicklung eng mitverfolgen müssen. Denn Änderungen in der Entwicklung wirken sich auch auf die künftigen Tests aus. Ein weiteres Spannungsfeld tritt schließlich ein, wenn die Systemtests durchgeführt werden müssen: Die Entwickler wenden sich dann bereits den nächsten Themen zu und beginnen einen neuen Iterationszyklus. Die Systemtester beschäftigen sich allerdings noch mit den Themen der vorangegangenen Iteration und benötigen mitunter die Unterstützung der Entwickler zur Fehleranalyse und -behebung.

In der Diskussion wurde klar, dass es für die bessere Abstimmung zwischen agiler Entwicklung und den zugehörigen Aufgaben der höheren Teststufen noch kaum effektive Lösungen gibt. Allerdings wurde eine Reihe von Maßnahmen identifiziert, die die Schwierigkeiten zumindest abschwächen und begrenzen können. Zentral ist, dass das Test-Team nicht vom Entwicklungsteam abgeschottet sein darf. Es muss alle wesentlichen Entscheidungen mitbekommen und schnell umsetzen können. Das Testteam muss auch bei der Zielfestlegung für die Iterationen mitwirken.

Ein Diskussionsteilnehmer empfahl einen Rollenschlüssel für die Teamzusammensetzung bei agiler Entwicklung: Bei kleineren Vorhaben sollten mindestens ein Architekt, zwei Entwickler und zwei Tester vorgesehen sein. Für größere Aufgaben muss das Team entsprechend größer sein oder in separate Gruppen von Entwicklern und Testern aufgeteilt werden, die aber eng zusammen arbeiten müssen. Die Tester könnten die Entwickler bereits bei der Erstellung der Modultests unterstützen. Die Benennung spezieller Tester sei wichtig, weil die Entwickler oft nicht auf die wirklich relevanten Systemtestfälle kämen.

Ein weiterer Diskussionsbeitrag bezog sich darauf, wie getrennte Entwickler- und Testerteams in den höheren Teststufen synchronisiert werden können. In den frühen Iterationen könne das Testteam sich zunächst auf exploratives Testen und das Design von Tests parallel zur Entwicklung konzentrieren. Die eigentlichen Tests sollten dann etwa einen halben Sprint-Zyklus hinter der Entwicklung her laufen. Ferner müssten zum Abschluss der Entwicklung, in ein oder zwei Stabilisierungsiterationen, die Systemtests im Mittelpunkt stehen.

Im abschließenden Ausblick äußerten die Diskussionsteilnehmer die Hoffnung, dass die Vorteile der Agilen Methoden bald noch besser auch für die höheren Teststufen genutzt werden können. Dazu müssten die Belange und Probleme des Systemtests in der agilen Entwicklung noch stärker betont werden. Das Forum Testmanagement soll ich deshalb bei seiner Veranstaltung am 16. Oktober 2008 wieder dem Erfahrungsaustausch zum Testen bei agiler Entwicklung widmen.


==Links==

* [[Forum Testmanagement|Homepage des "Forum Testmanagement"]]
* [http://www.gi-ev.de/regionalgruppen/stuttgart/ Homepage der ACM/GI-Regionalgruppe Stuttgart/Böblingen]
* [http://www.asqf.de Homepage der ASQF]