Scrum Rocks, Testing Sucks?! (de)

10:30 – 11:15

Raum 1

Praxis

Scrum Rocks, Testing Sucks?! (de)

Adrian Stoll

SwissQ Consulting AG

Zeit:

Ort:

Bereich:

Titel:

Referent:

Scrum Rocks, Testing Sucks?!

Adrian Stoll, SwissQ Consulting AGSwiss Testing Day 2011Zürich, 16. März 2011

Thank you for your involvement defending the platform and the work done.

Feedbacks von Entwicklern an uns Tester

Da wären wir nie drauf gekommen.

Toll, was du alles findest

euer team hat wirklich einen super job gemacht. die letzten Tage sind wirklich weltmeisterlich verlaufen, an allen ecken.

Eine echte Unterstützung! Ohne euch hätten wir das kaum geschafft.

du bisch e riese testing maschiene, mir si froh heimer di i säges dir

Ziele der Präsentation

Wie ein Scrum Team von einer dedizierten Person für das Testing profitiert

Warum ein Embedded Scrum 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 Scrum Spass macht, weil man involviert ist und schneller zum Ziel kommt

Agenda

1. Scrum Testing in der Praxis

2. Warum Testing in Scrum rockt!

3. Scrum Testing im Detail – Techniken und Technologien

4. Lessons Learned

SCENE

Adrian StollWirtschaftinformatiker, Tester aus Leidenschaft, Geek

Senior Consultant, SwissQ Consulting AG

Ihr Referent

Agenda




4. Lessons Learned

Projekterfahrungen: Migipedia

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

Projekterfahrungen: Vanilla

Coupons & Aktionen

Mobile Payment

iPhone & Android App

diverse Schnittstellen

Auftraggeber: Ringier

Embedded Tester zum ersten Release

Verschiedene Applikationen und Plattformen

Schnittstellen, End-To-End Testing

Mandat als Product Owner für die Weiterentwicklung

Die Scrum Methodik

Image: Liip AG

Blick auf die Vorgehensweisen

ATSTKonzept Design High Level Test EinführungCode Low Level Test

Wasserf

all

ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT ST/AT

S1 S2 S3 S4 S5 S6 S7 S8

Scru

m

Scrum Testing im Detail

ST/AT ST/AT ST/AT

S3 S4 S5

Scru

m

ST/AT ST/AT

S3 S4 S5

ST/ATEm

bed

ded

Embedded Scrum Tester

Shared Responsibility:Everybody tests their own part Ist (High Level) Test Know-How

vorhanden?

Ist Testing wirklich 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 das Testing zugeteilt, was einige Risiken mit sich bringt:

Embedded Scrum Tester

Ein Embedded Scrum Tester kann diese Risiken minimieren:

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

Agenda




4. Lessons Learned

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 over again

Isoliert – als Tester kann man selten die Umsetzung beeinflussen

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

Agenda




4. Lessons Learned

Techniken und TechnologienGrosser Anteil von Exploratory Testing

Techniken und TechnologienTraditionelle Test-Techniken ja – unbedingt! – aber "Light"

Techniken und TechnologienEntwicklung und Dokumentation von strukturierten (Regressions-) Testfällen "as you go"

Übersicht Regressions-Testcases Stand per Sprint XX

Techniken und TechnologienEinsatz eines Tools für Anforderungsmanagement, Fehlerverwaltung und Problembehandlung unabdingbar

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


(auch Daily Standup): Was habe ich gestern getestet, was teste ich heute, wo hatte ich Probleme beim Testen?

Daily Scrum

Image: Danny (Danko) Kovatch


Kennenlernen neuer Features vor dem Testing (oder: bereits getestete Features selbst demonstrieren)

Sprint Review / Demo

Die Demo lief diesmal richtig flüssig und wie aus einem Guss. Machte ein super-professionellen Eindruck, weiter so!


Wo waren die Stolpersteine aus Tester-Sicht, was lief besonders gut? Was kann man neu/anders machen?

Scrum Retrospective

Image: IT-Zynergy ApS

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

Agenda




4. Lessons Learned

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

A word on Regression

Explodierende Regressionstests

100

25 25

2550

25

75

25

Klassisch

Scrum

Iter. 1 Iter. 2 Iter. 3 Iter. 4

Test neuer FunktionenTest bestehender Funktionen (Regression)

100

100

R1(TA:100)

R2 (TA: 200)

R1 (TA: 250)

R2 (TA: 650)

100

550

Iter. 1-4

AUTOMATE !

Thank you for your involvement defending the platform and the work done.

Are you ready for the challenge?

Da wären wir nie drauf gekommen.

Toll, was du alles findest

euer team hat wirklich einen super job gemacht. die letzten Tage sind wirklich weltmeisterlich verlaufen, an allen ecken.

Eine echte Unterstützung! Ohne euch hätten wir das kaum geschafft.

du bisch e riese testing maschiene, mir si froh heimer di i säges dir

Kontaktieren Sie mich unter

1

2

3

4

5

6

7

8

SwissQ Consulting AGStadthausquai 158001 Zürich

Tel. +41 (0)43 288 88 40

Fax +41 (0)43 288 88 39

www.SwissQ.it

[email protected]

Twitter: @macstoll

Koordinaten

http://www.SwissQ.it/

mailto:[email protected]

mailto:[email protected]

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!

Stabilisation oder 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

DesignCar

BuildCar

TestCar

DeliverCar

Waterfall:Car



Scrum Rocks, Testing Sucks?! (de)

Technology

Transcript of Scrum Rocks, Testing Sucks?! (de)