Agile QA 2.0

Agile QA 2.0

@aceconf @mattphilip

Why this talk?

1.  Agile QA 1.0 never made it past “staging”

Why this talk?

1.  Agile QA 1.0 never made it past “staging”

2.  Call-to-action to reinvigorate the state of the practice

Why this talk?

1.  Agile QA 1.0 never made it past “staging”

2.  Call-to-action to reinvigorate the state of the practice

3.  Work together to come up with better ways

So what have

we learned?

-- Barry Boehm (1981)

Eliminate the need for massive

inspection by building quality into the

product in the first place.

-- Edwards Deming (1982)

So what have

we learned?

”

“

Handoffs are waste.

-- Mary Poppendieck (2003)

So what have

we learned?

Move testing to the

front of the

development process

-- Agile Testing (2009)

So what have

we learned?

”

“

Kanban doesn’t mean a return to

waterfall.

-- David Anderson (paraphrase, 2013)

So what have

we learned?

So of course what do our card walls look like?

How did this happen?

We simply repeat the same process that we've always done

QAs aren’t assertive enough to ask for change

We figure that, if we don’t, the QA won't have anything to do (resource efficiency)

#1

#2

#3

But why is this

a problem?

End-‐of-‐cycle testing (mini waterfalls)

#1 Creates too long a feedback loop #2 Virtually ensures that our testing efforts are

misaligned with value  #3 Reinforces gatekeeper role (oppositional) #4 Creates inefficient test suite

But why is this

a problem?

Limits options to checking through GUI

Creates inefficient test suite

Which leads to this

So how do

we remedy

these problems?

Remedies Bring QA Forward #1 Bring QA forward

* QA and devs collaborate to determine the right places to test

Remedies QA and devs collaborate to determine the right place to test

#1 Bring QA forward

Many here

Some here

A few here

Remedies Bring QA Forward #1 Bring QA forward

* QA and devs collaborate to determine the right places to test

* Specify acceptance tests up-front

(Acceptance-Test-Driven Development)

Remedies Acceptance-‐Test-‐Driven Development

DevelopmentIterations

Development Engine

Write Story and Scenarios

Business Showcase

Story Testing

Story Planning Session

BA / QA Signoff on Dev Box

Daily BA/QA demo

Tester

Dev

BA

TesterDev

Tester BADev

Tester BADev

BABusiness

Tester

Start Here

System Testing

Implement Functionality

BABusiness

Implement Automated Acceptance Tests

Dev

End Development Iteration

Start Development Iteration

#1 Bring QA forward

Remedies Bring QA Forward #1 Bring QA forward

* QA and devs collaborate to determine the right places to test

* Testing efforts are aligned with business

needs and risk * Specify acceptance tests up-front

(Acceptance-Test-Driven Development)

Remedies Re-‐start by mapping your done list to the wall #1 Bring QA forward #2 Map done list to the wall

* Simple value-stream * Lets the team take a conscious role in

defining its wall

Remedies Include QA in Work-‐In-‐Progress Limits #1 Bring QA forward #2 Map done list to the wall #3 Include QA in WIP limits

Expand this… … to

include this

* Encourages whole-team approach

Where do our biggest handoffs occur?

Here?

Here?

Other considerations Quality Advocacy Quality Advocacy * Consultative

* Service provider * Enabling and informing (not gatekeeping) * Big picture-oriented * Polyskilled and skill sharer * Courageous

Other considerations Integrated QA: QA is nowhere – and everywhere

Quality Advocacy Integrated QA

* Remove Test/QA as a separate column altogether * QA provides real-time, zero-cycle-time feedback * Decouples what from who,

decreases bottleneck * Commits devs and testers

toward same goal: working, tested software

So do we have a place for

any kind of end-of-cycle testing?

Other considerations Exploratory Testing as First-‐Class Practice Quality Advocacy Integrated QA Exploratory testing

* Not simply “clickin’ around” but highly-skilled discipline

* Anyone with the right skill, independence can do it * Model it on the wall

So what are you

going to do starting Wednesday?

References

§  Alister Scott, http://watirmelon.com/2013/02/28/the-new-qa-the-quality-advocate/

§  Barry Boehm, Software Engineering Economics

§  Martin Fowler, http://martinfowler.com/bliki/TestPyramid.html

§  InfoQ, http://www.infoq.com/articles/David-Anderson-Kanban

§  Deming Institute, http://deming.org/

mphilip@thoughtworks.com

@mattphilip