Top Banner
Testing as Exploration aka. Continuous Delivery without Automation Maaret Pyhäjärvi Email: <[email protected]> | Twitter: maaretp Maaret Pyhäjärvi Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en
18
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Testing as Explorationaka. Continuous Delivery without

Automation

Maaret Pyhäjärvi

Email: <[email protected]> | Twitter: maaretp

Maaret Pyhäjärvi

Nimeä | Attribution (Finland)

http://creativecommons.org/licenses/by/1.0/fi/

http://creativecommons.org/licenses/by/1.0/fi/deed.en

Page 2: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

1. LET’S TALK ABOUT

EXPLORATORY TESTING

?

Page 3: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Things Can Look Different from

Different Perspectives

Page 4: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Realizations about Nature of

Testing

20

16

1639

5±24

Page 5: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Exploratory Testing:

Better tests, better testers! • An approach, not a technique

• Find unknown unknowns

• Disciplined

• Test is a performance, not artifact

– Artifacts support human

memory

– Many forms: e.g. checklists and

automation

• Exploratory performance testing,

Exploratory test automation,

Exploratory regression testingTest-related

learning

Design of new

tests

Test executionResult

interpretation

5

Page 6: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Exploratory Testing:

Learning & Modeling

”A day’s work”

Vision (“Sandbox”) Current Charter

Other Charters Details

Bug

Reports

Perception of

quality and

coverage

Quality

ReportDebriefing

Tester

Test

Manager

Past

Results

Obstacles

Outlook

Feelings

?

#

xCharter backlog of the future

testing

Out of

budget

Next in

importance!#, ?, x, +

20:20:60

Session sheets of the past testing

Idea of

exploration

Metrics

summary

Coachin

g

6

Playbooks

Coverage outlines

Page 7: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

2. CONTINUOUS DELIVERY

WITHOUT AUTOMATION

Page 8: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Where

does this

say fast?

Where does

this say

automation

?

Page 9: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

A Bit of Background

• 3 years into a web based (.NET/C#) product

• 1:8 tester:developer ratio

• Missing agile technical practices: test automation non-existent

• Scrum-like monthly releases for first 2 years– Releases late

– Releases not tested well enough

• Negative cycle of failing with estimates eating team morale

• Jira in a central role with estimates and burndown

Page 10: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Going for Continuous Delivery

Page 11: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

The Main Driver for Change:

Testing

Scheduled release

Feature 1

Feature 2

Feature 3

Feature 4

Testing

Feature 1

Feature 2

Feature 3

Feature 4

R1 R2 R3

Done

includes

Tested

Schedule

over

Quality

SCRUM + SCHEDULED DELIVERY with continuous integration

KANBAN + CONTINUOUS DELIVERY

Page 12: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Enablers that Made Timing Just

Right

• Henri Karhatsu and #NoEstimates –

experience report

• Availability of Git in Visual Studio without

plugins

• Problems with schedules in Scrum

• Lean and value delivery focus in Product

Management

Page 13: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Changing How We Managed Our

Work: Setting up Jira Kanban

Removed hour &

story point estimates

Agreed in WIP for

each phase

Agreed on swarming

Updated issue types

Page 14: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Branches and Test

Environments

Feature Test Environment

Feature branches on-demand builds

“Developers think this can be tested”

Development Test

Environment

Integration branch build-on-checkin

“Developers think this can be released”

Acceptance Test

Environment

Master branch with fixes and merges from integration

on-demand builds

“Release next morning”

Page 15: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Continuous Deployment but

Significant Lead Times

Mon Tue Wed Thu Fri Mon Tue Wed Thu Fri

Change to

Master

Integration

to master

Feature to

integration

Developers drive the decision on what

they want feedback on

Page 16: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Exploratory Testing Enables

Continuous Deployment• Every Jira task gets planned for

– Sometimes we go with developer testing only

– Sometimes we test extensively

• Exploratory Planning– No set test cases

– Talking to developers and reflecting to a model of of use created through earlier explorations

– Actionable information first –principle

– Production monitoring is an option for getting information

Page 17: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Changes

• Active discussion about schedules and merging, and needs of testing in the branches

• More pairing for testing the features

• More group work on defining the features

• Introducing Flowdock due to increased need to collaborate; integrating logs, emails

• Focus on getting better (scope of test automation; refactoring; pairing and group work; individuals’ skills)

Page 18: Agile San Diego: Testing as Exploration (Continuous Delivery w/o Automation)

Testers don’t break

your code, they

break your illusions

about the code. -- adapted from James Bach