Agile Methoden vs. Testen

Größe: px

Ab Seite anzeigen:

Download "Agile Methoden vs. Testen"

Stephanie Heintze
vor 8 Jahren
Abrufe

1 Agile Methoden vs. Testen cc gmbh Bernhard Moritz CC GmbH

2 TAV 27, AK Testmanagement, Bernhard Moritz Flachstraße Wiesbaden Telefon Telefax TAVTM_moritz_agile_methoden_vs_testen_v03.odp 2

Wiesbaden Telefon 0611 94204-0 Telefax 0611

3 Übersicht Warum befassen wir uns mit Agilen Methoden? Agile School of Software Testing Übersicht über Agile Software-Entwicklung Who is Who in Agile Software Development Extreme Programming Explained Testing Extreme Programming Agile (TDD) vs. Context-Driven TAVTM_moritz_agile_methoden_vs_testen_v03.odp 3

Who is Who in Agile Software Development Extreme Programming Explained

4 Hinweis In diesem Beitrag wurden an Hand von vielen Zitaten versucht, Einblick in die Thematik zu gewinnen. Die Zitate selbst sollen hier mit wenigen Ausnahmen nicht aufgeführt werden, stattdessen werden die Quellen angegeben. Für die Verfügbarkeit von Internetquellen kann hier leider keine Garantie übernommen werden. TAVTM_moritz_agile_methoden_vs_testen_v03.odp 4

Die Zitate selbst sollen hier mit wenigen Ausnahmen nicht aufgeführt werden, stattdessen

5 Warum befassen wir uns mit Agilen Methoden? Auf den vorangegangenen Sitzungen hatten wir uns mit den Schulen des Software- Testens auseinander gesetzt: Ursprünglich waren es mal 4: Analytical School Quality School Standard School Context-Driven School In der letzen Fassung des Beitrags von Brett Pettichord (2007) waren es dann 5, hinzugekommen ist: Agile School Siehe auch: Wie läßt sich eine Schule identifizieren, wie unterscheidet sie sich von anderen? TAVTM_moritz_agile_methoden_vs_testen_v03.odp 5

Analytical School Quality School Standard School Context-Driven School In der letzen Fassung des Beitrags von Brett Pettichord (2007)

6 Agile Testing Aus Brett Pettichord 2007: Agile School Core Beliefs: Software is an ongoing Conversation Testing tells us that a development story is complete Tests must be automated Key Question: Is the Story done? Implications Developers must provide automation frameworks Slow to appreciate value of explorative testing Testing Without Specs Conversion is more important than documentation TAVTM_moritz_agile_methoden_vs_testen_v03.odp 6

Implications Developers must provide automation frameworks Slow to appreciate value of explorative testing

7 Agile Software-Entwicklung Der Begriff der Agilen Software-Entwicklung geht zurück auf ein Manifest, welches im Internet verbreitet wurde: 'We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.' Siehe auch: TAVTM_moritz_agile_methoden_vs_testen_v03.odp 7

Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract

8 Who is Who Agile SW-Development General Testing Extreme Programming (XP) Test-Driven Development (TDD) Feature -Driven Development Scrum Lean Software Development Crystal DSDM Context-Driven School??? Brett Pettichord Cem Kaner James Bach... Agile School??? Brian Marick TAVTM_moritz_agile_methoden_vs_testen_v03.odp 8

Development Crystal DSDM Context-Driven School?

9 Testing Extreme Programming Lisa Crispin und Tip House: Testing Extreme Programming, Liefert eine Beschreibung der Aufgaben eines Testers in einem XP Projekt. Aus Sicht des Testens gibt es nicht viel Neues zu lernen. Da es bei XP keine Hauptrolle für Tester gibt, sammeln die Autoren etwas mühsam die Krümel unter dem Tisch der Protagonisten Programmer, Customer und Coach. Der Tester verkommt dabei stellenweise zum "Projektassistenten" 'Think of having a programmer with a "test focus". By the term Tester, we mean a person who not only develops and runs tests but has quality assurance and development skills as well. Testers also help customers write stories, and they define acceptance tests and take the lead automating them.' 'On an Extreme Programming project a manual test may be worse than no test at all' TAVTM_moritz_agile_methoden_vs_testen_v03.odp 9

Da es bei XP keine Hauptrolle für Tester gibt, sammeln die Autoren etwas mühsam die Krümel unter dem Tisch der Protagonisten Programmer, Customer und Coach.

10 Testing Extreme Programming Aktivitäten von Testern: Unterstützung der Abstimmung mit dem Kunden zum Thema Qualität Unterstützung bei der Klärung von Fragen zu den Stories Unterstützung bei Aufwandsschätzungen Vertreten der Rechte des Kunden Schutz der Rechte von Entwicklern Unterstützung des Kunden bei der Erstellung von Akzeptanztests Sicherstellen, dass Akzeptanztests die definierten Qualitätskriterien anpeilen Unterstützung des Teams bei der Automation von Akzeptanztests Sicherstellen, dass Testresultate auch berichtet werden Sicherstellen, dass die Akzeptanztests zeitlich mit der Entwicklung Schritt halten Unterstützung der Entwickler beim Entwurf (besser) testbaren Codes 'Keep the team honest' TAVTM_moritz_agile_methoden_vs_testen_v03.odp 10

definierten Qualitätskriterien anpeilen Unterstützung des Teams bei der Automation von Akzeptanztests Sicherstellen, dass Testresultate auch berichtet werden Sicherstellen, dass die

11 TAVTM_moritz_agile_methoden_vs_testen_v03.odp 11 Quellen Kent Beck: Extreme Programming Explained. Embrace Change, Lisa Crispin und Tip House: Testing Extreme Programming, Kaner, Bach, Pettichord: Lessons Learned in Software Testing. A Context-Driven Approach, Brett Pettichord: Four Schools of Software Testing: Agile Manifesto: Interviews: jul02/interviewwithkanerjul02.pdf nov02/pettichord_therationaledge_nov2002.pdf Agile Times (Beiträge von Marick): Blogs:

pdf Agile Manifesto: http://www.agilemanifesto.org/ Interviews: http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/ jul02/interviewwithkanerjul02.pdf http://www.ibm.com/developerworks/rational/library/2833.

12 Resümee Context-Driven vs. Agile School Es gibt zwei Punkte, an denen beide Schulen nicht zu einer gemeinsamen Haltung finden: Test-Automation Jede Aussage, die manuelle und unabhängige Tests verdammt, führt zu einem Widerspruch durch die Context-Driven School. Team-Kooperation Jede Aussage, dass Testen unabhängig nach der Fertigstellung eines Releases stattfinden muss, führt zum Widerspruch durch die Agile School. In beiden Bereichen finden sich aber auch Befürworter für die Methoden der anderen Schule im Zweifelsfall (und wenn es nützlich ist) nennt man es eben nicht mehr Testen, sondern z.b.: "end-of-iteration retrospective" Warum Pettichord aber 2007 eine Abgrenzung der Agile School vornimmt ist nicht klar. TAVTM_moritz_agile_methoden_vs_testen_v03.odp 12

Widerspruch durch die Context-Driven School.

13 Resümee Agile Software-Entwicklung orientiert sich an den Bedürfnissen von Entwicklern und Kunden. Das verbindende zwischen den verschiedenen Ausprägungen ist "Lean Management". Es gibt wenige allgemeine Vorgaben zu Methoden, Prozessen oder Werkzeugen. Ein Kernthema ist Kooperation (Kommunikation) aller Team-Mitarbeiter entsprechend verschwimmen die Grenzen zwischen Requirements Engineering Design, Konstruktion und Test. Jeder Versuch separate Zuständigkeiten zu definieren ist strafbar. In einigen Agilen Vorgehensmodellen gibt es strikte Vorgaben zum Testen, z.b. TDD oder Automation. Dies allein bleibt aber (fast) ohne Einfluß auf die Testmethodik. Ein Öffnung in Richtung unabhängige Test-Teams ist gelegentlich zu beobachten. Die Skills erfahrener Tester werden nicht abgelehnt, allerdings, da es ja kein gesondertes Test-Team mehr gibt, wird Testmanagement überflüssig TAVTM_moritz_agile_methoden_vs_testen_v03.odp 13

Ein Kernthema ist Kooperation (Kommunikation) aller Team-Mitarbeiter entsprechend verschwimmen die Grenzen zwischen Requirements Engineering Design, Konstruktion und Test.

Ähnliche Dokumente

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht