5. Why this talk?
1. Agile QA 1.0 never
made it past “staging”
2. Call-to-action to
reinvigorate the state
of the practice
6. 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
8. Eliminate the need for massive
inspection by building quality into the
product in the first place.
-- Edwards Deming (1982)
So what have
we learned?
”
“
19. 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
20. 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
21. But why is this
a problem?
Limits
options to
checking
through
GUI
Creates inefficient test suite
Which
leads to
this
24. Remedies Bring QA Forward
#1 Bring QA forward
* QA and devs collaborate to determine the
right places to test
25. Remedies QA and devs collaborate to determine the
right place to test#1 Bring QA forward
Many
here
Some
here
A few
here
26. 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)
27. Remedies Acceptance-‐Test-‐Driven Development
Development
Iterations
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
28. 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)
29. 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
30. 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
33. Other considerations Quality Advocacy
Quality Advocacy
* Consultative
* Service provider
* Enabling and informing (not gatekeeping)
* Big picture-oriented
* Polyskilled and skill sharer
* Courageous
34. Other considerations Integrated QA:
QA is nowhere – and everywhereQuality 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
35. So do we have a place for
any kind of end-of-cycle testing?
37. 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
38. So what are you
going to do starting Wednesday?
39. 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