BPUG Seminar 2014 Rik Marselis - effectief testen in agile

24
. PLANET AGILE 17E BPUG SEMINAR Effectief testen in Agile projecten Rik Marselis (Sogeti)

description

The yearly seminar of the Best Practice User Group in the Netherlands this year has the theme "Agile". My contribution is an interactive session where the participants can vote for a number of subjects to create the backlog of the session. This slide-deck contains all slides that I prepared, I guess I only used half of them, the rest everybody can see here at slideshare. The slides are mainly in english but also partly in dutch. At the end I refer to the book "TMap NEXT in Scrum", to the book "the PointZERO vision" and to the whitepaper "Integrate test activities in Agile projects".

Transcript of BPUG Seminar 2014 Rik Marselis - effectief testen in agile

Page 1: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

.

PLANET AGILE 17E BPUG SEMINAR

Effectief testen in Agile projecten

Rik Marselis (Sogeti)

Page 2: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Effectief testen in Agile projecten

2

Rik Marselis Management Consultant Quality & Testing bij

Ruim 30 jaar IT ervaring, ruim 15 jaar kwaliteit & testen

Adviseur, procesverbeteraar & coach bij vele organisaties Prince2 Practitioner, CMMI en CISA

Docent voor diverse trainingen, bijv. Agile testen TMap, TPI en ISTQB geaccrediteerd

Research Auteur div. boeken en artikelen Fellow van SogetiLabs, Spreker op div. conferenties

Voorzitter (vereniging voor testers, 1600 leden)

@rikmarselis

Page 3: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Agile is always “QD”

Agile = Quality Development

Agile = Quick Development

Agile = Quick & Dirty

Agile = Quite a Disaster

What is your QD ???

Page 4: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Dit zegt de Scrum guide over kwaliteitszorg:

4

Agile is always “QD”

Page 5: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Kies de BACKLOG-ITEMS voor deze timebox:

•  Risico-gebaseerd werken (wat is risk poker?) •  Onafhankelijk testen (aparte test-sprints?) •  De bekende testactiviteiten (passen die in Scrum?) •  Quality Gates in Scrum (is dat tegenstrijdig?) •  Moet al het testwerk in de sprint gebeuren (ketentesten?) •  Rol van de tester (is een specialist nodig?) •  A sustainable pace (kun je voortdurend sprinten?) •  Exploratory testing (moet je altijd vooraf testgevallen maken?) •  Testautomatisering (waarom kan het niet handmatig?) •  Focus niet op tijd en kosten (maar op kwaliteit en risico!)

5

Effectief testen in Agile projecten

Page 6: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Een Agile team bestaat uit ‘developers’

Dus gespecialiseerde testers zijn niet meer nodig?

Wat vind jij?

6

Development team

Scrum master

Product Owner

teammem-ber

Scrum guide: •  Development teams are cross-functional,

with all of the skills necessary

•  No sub-teams regardless of domains like business analysis or testing

Testen een van de skills

De rol van de tester

Page 7: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Niet apart testen!!

Development

Testing

Aparte test-sprints?

Scrum guide: No sub-teams

Page 8: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Focus niet op tijd en kosten, maar op kwaliteit en risico

This should be no surprise

in an agile context, but

often still is!!

Page 9: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Overview testing activities in

scrum

Evaluate backlog items and communicate obscurities with product owner

Determine product risk of each backlog item and record it on the (story) card (input for planning poker, assigning story points)

Focus niet op tijd en kosten, maar op kwaliteit en risico

Page 10: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl 10

Testactiviteiten in Scrum

Bron: TMap NEXT in Scrum

Page 11: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl 11

Conclusion: You can’t sprint all the time Agile principle: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (prevent having a team-burnout; implement the Agile principles in a proper way!)

How long does the 100 meter sprint take? 100 meter sprint +10 seconds

How long does it take to sprint a marathon? 42 kilometer sprinting +70 minutes

What is the world record for a marathon? Marathon record +120 minutes

About sprinting

Page 12: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl 12

Demand

Supply

Welke testsoorten in de sprint?

bijv. ketentest

Page 13: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Meerdere Agile-teams brengen deel-producten bijeen die samen met bestaande systemen de procesketen ondersteunen.

13

Ketentesten

Systeem 1

Bedrijfsproces (van klant tot klant)

Systeem 2

Systeem 3

Systeem 4

Systeem 5

Bestaand ongewijz.

Bestaand ongewijz. Scope

keten test

Page 14: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl 14

The demand side often uses a phased approach The supply side often uses an agile approach Good supervision, using quality gates, can glue them together in a pragmatic manner

Demand

Supply

Supervision

Quality Gates & Agile

Page 15: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl 15

Collaboration at handover of artifacts (quality gates) Collaboration of all parties involved

for example: don’t forget the maintenance people

A quality gate is not a point in the process where everything comes to a stand-still, on the contrary: it must be a smooth handover based on previously agreed and monitored criteria

Definition of “Done”

Quality Gates in Scrum? Collaborate:handover based on criteria

Page 16: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

The handovers in Agile are accomplished by teamwork and common ownership.

Is is no longer a mere transfer of documents or deliverables. It is common responsibility.

Doing Agile well will ensure that nothing gets ‘lost in translation’

Quality Gates in Scrum? Collaborate:handover based on criteria

Quality Gate? Definition of Done!

Page 17: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

From a test perspective, a DoD contains:

• The criteria that have to be met in a sprint with regard to the defects procedure

• A specification of the test intensity that is to be used while creating the test cases, based on the established product risk

• The agreements made concerning the test process • The agreements made concerning the test results • The test levels that have been included in the sprint.

In general, one can say: Do not allow anything that is not completely ready into the sprint, and do not allow anything that is not quite done to escape. A sprint can only be classified as done if the testing has also been done.

17

Testen en Definition of Done

Source: Integrate Test Activities in Agile Projects

Page 18: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Twee risk-poker-rondes vooraf aan planning poker 1.  Faalkans 2.  Schade

18

Riskpoker

Page 19: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Testzwaarte hangt af van productrisico

19

Riskpoker

Scrum master

Product owner

Agile Team

2 2

1

Discussie

Als PR medewerker wil ik een twitter koppeling

zodat ik snel kan informeren

3

Page 20: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Resultaat op story-card als input voor planningpoker

20

Sprint goals

Kenmerk/ testvorm

Schade Faal-kans

Risico- klasse

US 1 Regressie 3 3 9

US 2 Functionaliteit 2 2 4 Beveiliging 3 2 6

Feature 1 Regressie 2 1 2 Overall Performance 2 1 2 US 3 Gebr.vr.heid 1 1 1

US 4 Functionaliteit 2 2 4 Geschiktheid 2 2 4

.. .. .. .. ..

Riskpoker

Storycard - risico - omvang

Page 21: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Twee soorten testautomatisering

Regressietesten: Elke sprint testen of de deliverables van de vorige sprints nog werken Dit kun je handmatig niet bijbenen !!!

21

Testautomatisering: een “must”

Acceptance Test Driven Development: Specificaties worden geschreven als automatisch uitvoerbare tests Dus zodra de software wordt opgeleverd kun je onmiddellijk de test

runnen en vaststellen of de software voldoet aan de specificaties

Testtooling is meer dan geautomatiseerd uitvoeren van tests: -  Bevindingenbeheer (in ieder geval wat na de sprint open staat) -  Testdatamanagement (elke sprint weer de juiste data nodig) -  Genereren testgevallen (want te weinig tijd om het handmatig te doen) -  En meer …

Page 22: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Met andere woorden: elke vorm van testen waarbij de tester zijn testen ontwerpt tijdens de testuitvoering en de informatie die wordt verkregen tijdens het testen wordt gebruikt om nieuwe en betere testgevallen te ontwerpen [Bach, 2002]

Past dit binnen Agile?

Het SIMULTAAN leren, ontwerpen en uitvoeren van tests

Exploratory Testing binnen Agile

Page 23: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Binnen Agile kunnen specificaties wijzigen –  Bij minder risicovolle

delen daarom minder tijd steken in vooraf opstellen testgevallen

Structuur aan te brengen door strategieafwegingen, testcharters en testsessies

M.a.w. Verkom “waste”

Risicovolle delen vergen een gedegen voorbereiding

“Testbasis” te verkrijgen door ‘pairen’ of team aanspreken op opleveren minimale testbasis (=documentatie)

M.a.w. Wees grondig in aantonen

werkende software

Exploratory Testing binnen Agile

Page 24: BPUG Seminar 2014 Rik Marselis - effectief testen in agile

www.bpug.nl

Meer weten? De boeken: www.ict-books.com

Retrospective [email protected] www.PointZERO.info

www.TMap.net www.Sogeti.nl

Vragen? Opmerkingen?