Scrum Rocks, Testing Sucks?! Präsentation am Swiss Testing Day 2011 von Adrian Stoll, SwissQ Consulting AG 16.03.2013 (c) SwissQ Consulting AG

1. 10:30 – 11:15
Raum 1
Praxis
Scrum Rocks, Testing Sucks?! (de)
Adrian Stoll
SwissQ Consulting AG
Zeit:
Ort:
Bereich:
Titel:
Referent:

2. Scrum Rocks, Testing Sucks?!
Adrian Stoll, SwissQ Consulting AG
Swiss Testing Day 2011
Zürich, 16. März 2011

3. Thank you for your
involvement
defending the
platform and the
work done.
Feedbacks von Entwicklern an uns Tester
Dawärenwirniedr
aufgekommen.
Toll, was du
alles findest
euer team hat wirklicheinen super job gemacht. die
letztenTagesindwirklichweltmeisterlichverlaufen, an
allenecken.
Eine echte
Unterstützung!
Ohne euch
hätten wir das
kaum
geschafft.
Page 3
du bisch e
riesetestingmaschie
ne, mir si froh
heimer di i säges dir

4. Ziele der Präsentation
 Wie ein Scrum Team von einer dedizierten Person für das Testing
profitiert
 Warum ein EmbeddedScrum Tester besser ist, als die
Testverantwortung auf das ganze Team zu verteilen
 Was trägt ein Tester zu den Scrum Prozessen wie Daily
Scrum, Sprint Planning, Retrospective etc. bei
 ... und vor allem: Finden Sie heraus, weshalb Testing in ScrumSpass
macht, weil man involviert ist und schneller zum Ziel kommt
Page 4

5. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. LessonsLearned
Page 5

6. SCENE
Adrian Stoll
Wirtschaftinformatiker, Tester aus
Leidenschaft, Geek
Senior Consultant, SwissQ Consulting AG
Ihr Referent
Page 6

7. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. LessonsLearned
Page 7

8. Projekterfahrungen: Migipedia
Page 8
 Community Plattform
für Migros-Kunden
 Produktebewertungen
& Kommentare
 Umfragen &
Kampagnen
 Einsatzbeginn 2 Wochen vor Launch als "Retter in der Not"
 Dokumentation von 80 Bugs innert der ersten 2 Tagen
 Begleitung des Projekts bis zum (pünktlichen) Release
 Seither fester Partner als Testing und QA-Verantwortliche

9. Projekterfahrungen: Vanilla
Page 9
 Coupons & Aktionen
 Mobile Payment
 iPhone &AndroidApp
 diverse Schnittstellen
 Auftraggeber: Ringier
 Embedded Tester zum ersten Release
 Verschiedene Applikationen und Plattformen
 Schnittstellen, End-To-End Testing
 Mandat als ProductOwner für die Weiterentwicklung

10. Die Scrum Methodik
Page 10
Image: Liip AG

11. Blick auf die Vorgehensweisen
Page 11
ATST
Konzept Design High Level Test EinführungCode Low Level Test
Wasserfall
ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT
S1 S2 S3 S4 S5 S6 S7 S8
Scrum

12. Scrum Testing im Detail
Page 12
ST/AT ST/AT ST/AT
S3 S4 S5
Scrum
ST/AT ST/AT
S3 S4 S5
ST/AT
Embedded

13. Embedded Scrum Tester
Shared Responsibility:
Everybody tests their own part  Ist (High Level) Test Know-How
vorhanden?
 Ist Testingwirklich unabhängig, objektiv?
 Wie/wer verantwortet Bug-Fixing und
Retests?
Im Scrum Team wird Testing als gemein-
same Verantwortung wahrgenommen. Oft
werden Entwickler für
dasTestingzugeteilt, was einige Risiken mit
sich bringt:
Page 13

14. Embedded Scrum Tester
Ein EmbeddedScrum Testerkann diese
Risikenminimieren:
 Spezial-Wissen vorhanden
 Unabhängig und „objektiv“
 Fehler können umgehend behoben
werden (sehr kurze Feedback-Zyklen)
Shared Responsibility:
Everybody tests their own part
Embedded Acceptance Tester:
Test by an independent specialist
Page 14

15. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. LessonsLearned
Page 15

16. Why traditional Testing sucks
 Frustrierend – Fehler zu finden, die offensichtlich sind
 Undankbar – als Tester ist man bei Entwicklern oft unbeliebt
 Stressig – bei Verzögerungen verkürzt sich meist die Testzeit
 Eintönig – immer wieder dieselben Testfälle, over and overagain
 Isoliert – als Tester kann man selten die Umsetzung beeinflussen
Page 16

17. Why Scrum Testing rocks
 Motivierend – Raschere Testresultate, schnellere Bugfixes
 Dankbar – Entlastung für Entwickler, positives Feedback
 Kontrolliert – eingebetted in Scrum Planung und Zyklus
 Abwechslungsreich – am Puls der (raschen) Weiterentwicklung
 Involviert – Mitreden und Lösungsvorschläge erwünscht
Page 17

18. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. LessonsLearned
Page 18

19. Techniken und Technologien
Grosser Anteil von Exploratory Testing
Page 19

20. Techniken und Technologien
Traditionelle Test-Techniken ja – unbedingt! – aber "Light"
Page 20

21. Techniken und Technologien
Entwicklung und Dokumentation von strukturierten (Regressions-) Testfällen
"as yougo"
Page 21
Übersicht Regressions-Testcases
Stand per Sprint XX

22. Techniken und Technologien
Einsatz eines Tools für Anforderungsmanagement, Fehlerverwaltung und
Problembehandlung unabdingbar
Page 22

23. Beitrag des Testers in Scrum Prozessen
 Abschätzen der Zeit, welche zum Testen von User Stories benötigt
werden und dafür sorgen, dass diese bei der Aufwandschätzung
berücksichtigt werden
Scrum Planning / Estimation Meeting
Page 23

24. Beitrag des Testers in Scrum Prozessen
 (auch Daily Standup): Was habe ich gestern getestet, was teste ich
heute, wo hatte ich Probleme beim Testen?
Daily Scrum
Image: Danny (Danko) Kovatch
Page 24

25. Beitrag des Testers in Scrum Prozessen
 Kennenlernen neuer Features vor dem Testing
(oder: bereits getestete Features selbst demonstrieren)
Sprint Review / Demo
Page 25
Die Demo liefdiesmalrichtigflüssig und
wieauseinemGuss.Machteein super-
professionellenEindruck, weiter so!

26. Beitrag des Testers in Scrum Prozessen
 Wo waren die Stolpersteine aus Tester-Sicht, was lief besonders
gut? Was kann man neu/anders machen?
ScrumRetrospective
Image: IT-ZynergyApS
Page 26

27. Scrum Testing – Best Practices
 Einsatz eines Tools für Anforderungsmanagement, Fehlerverwaltung
und Problembehandlung mit Workflow
 Anforderungsbasiertes Testing anhand von User Stories
 Der Entwickler schreibt ein "How to test" pro Issue
 Sprint-Planung und Fortschritt stetig überwachen
 Tests möglichst rasch durchführen, Anhäufung von pendenten
Testfällen vermeiden
 Integrationsfördernde Massnahmen zahlen sich aus: Anpassung an
Kleidung, Sprache, Arbeitszeiten, Gewohnheiten des Teams etc.
 Nahe beim Team sein: Physisch präsent oder mithilfe von
elektronischer Kommunikationsmitteln
Page 27

28. Agenda
1. Scrum Testing in der Praxis
2. Warum Testing in Scrum rockt!
3. Scrum Testing im Detail – Techniken und Technologien
4. LessonsLearned
Page 28

29. Scrum Testing – Lessons learned
 Scrum erfordert Disziplin!
 Vorsicht vor "Technical Debts"!
 Dokumentation wird häufig vernachlässigt
 End-to-End Testing sauber planen
 Scrum Testing kann konventionelle Testorganisation nur ergänzen
 Scrum Testing und Remote Testing: Tolle Kombination!
 Continous Improvement
 Regressionstests: Die grösste Herausforderung in Scrum
Page 29

30. A word on Regression
Page 30

31. Explodierende Regressionstests
100
25 25
25
50
25
75
25
Klassisch Scrum
Iter. 1 Iter. 2 Iter. 3 Iter. 4
Test neuer Funktionen
Test bestehender Funktionen (Regression)
100
100
R1
(TA:100)
R2
(TA: 200)
R1 (TA: 250) R2 (TA: 650)
100
550
Iter. 1-4
Page 31

32. Thank you for your
involvement
defending the
platform and the
work done.
Are youreadyfor the challenge?
Dawärenwirniedr
aufgekommen.
Toll, was du
alles findest
euer team hat wirklicheinen super job gemacht. die
letztenTagesindwirklichweltmeisterlichverlaufen, an
allenecken.
Eine echte
Unterstützung!
Ohne euch
hätten wir das
kaum
geschafft.
Page 32
du bisch e
riesetestingmaschie
ne, mir si froh
heimer di i säges dir

33. Page 33
Kontaktieren Sie mich unter
1
2
3
4
5
6
7
8
 SwissQ Consulting AG
Stadthausquai 15
8001 Zürich
 Tel. +41 (0)43 288 88 40
 Fax +41 (0)43 288 88 39
 www.SwissQ.it
 adrian.stoll@swissq.it
 Twitter: @macstoll
Koordinaten

34. Um die Qualität der Konferenz weiter verbessern zu können, sind
wir auf Ihr Feedback angewiesen. Bitte füllen Sie entsprechend
das Feedbackformular aus.
Das Feedbackformular kann am Ende des Tages am Ausgang
abgegeben werden.
Vielen Dank!

35. Stabilisationoder Test Sprint (E2E) einplanen
Vorteile von “Test Sprint”
 Sicherstellen das alle Bestandteile
als ein System zusammenwirken
 End-2-End Performance
sicherstellen
 Möglichkeit zum finalen
Regressionstests
 End-2-End Tests mit Umsystemen
(Wasserfall) durchführen
Risiko: Spät gefundene Fehler
nehmen viel Zeit für die Behebung
in Anspruch.
Sprint 1:
Engine
Sprint 2:
Drive Train
Sprint 3:
Carroserie
Sprint ??:
Test Only
Design Build Test Deliver
Test
Design
Car
Build
Car
Test
Car
Deliver
Car
Waterfall:
Car
Design Build Test Deliver
Design Build Test Deliver
Page 35