QA in an Agile World Presentation for Agile & Beyond 2015

1. QA in an Agile World
Tom Churchwell
TChurchwell@GMail.com

2. Agenda
2
● Role Setup (5 Minutes)
● Exercise 1 (2 Minutes)
● Agile QA In 3 Easy Steps (20 Minutes)
● Exercise 2 (15 Minutes)
● Q&A/Retro (5 Minutes)

3. Role Setup
3
● Product Owner
● Architect
● QA
● Everyone Else is Developers

4. Exercise 1
4
Stand Up
Stretch your arms above your head
Fold your arms
Are you left arm over right or right arm over
left?

5. Exercise 1
5
Stretch your arms above your head
Fold your arms the opposite way
1. Could you do it?
2. Is it comfortable?
Change is uncomfortable. Be compassionate.

6. Team/Organization Prerequisites
1. Teamful Practices
a. Customer is the locus of concern
b. Teams Survive Beyond Projects
c. Self-Organizing, Autonomous, Craftspeople
d. Coordination, Communication, Collaboration
i. Co-Located - High Trust
2. Craftsmanship/Continuous Improvement Practices
a. Retro’s
b. Exploratory Testing
c. Code Kata’s/WISE/Lunch’N’Learns/etc...

7. Getting To Agile QA in 3 Easy Steps
1. Establish Quality Standards and a Definition of
Done
a. DOD for each phase of delivery
i. Story Done
ii. DEV Done
iii.Quality (Not Necessarily QA) Verified
b. Empower Team Ownership of Quality
c. Move Escalations/Discovered Defect to the top
of the Queue

8. Getting To Agile QA in 3 Easy Steps
2. Gather Metrics and make them prominent
a. Code Quality
b. Delivery Velocity
c. Defects
d. Performance
e. Others….
Not A Bludgeon!
Make it easy for people to do the right things

9. Getting To Agile QA in 3 Easy Steps
3. Automate Everything
a. Testing
i. All Possible Layers
b. Builds
c. Releases

10. What Is Different?
10
● Big Definition Up Front vs Emergent Design
● Adaption vs Prediction
● Short vs Long Iterations
● Short vs Long Customer Feedback Loops
● Working Software Baked In vs Tested In
● Whole Team Quality Ownership vs QA
● Automated vs Manual (Test, Build, Release)

11. BDUF - Big Definition Up
Front
11

12. Adaption vs Prediction
12
● Tradition tries to understand how things will work and
defines architecture up front
● Tradition makes change hard to accommodate.
● Agile embraces emergent design and adapts as a system
evolves.
● Agile embraces change.

13. Last Responsible Moment
13

14. Long vs Short Iterations &
Customer Feedback Loops
14
● Agile anticipates releases to PROD more and more
often…sometimes even multiple times a day
● Testing starts earlier, happens more often and relies almost
entirely on automation to include build automation
● Agile wants feedback weekly at the BV Demo

15. Otto The Autopilot
15

16. Working Software & Quality Ownership
16
● Tradition uses QA to verify functionality after development
● Traditional relies on QA to test and verify and “Own”
quality and as a result hands responsibility for quality
over to QA
● Test Drive
● Automate Testing
● Verify working software during and after development
● Bake Quality In

17. Bake Quality In…
We Cannot Improve Our
Recipe’s By Eating More
Cookies…
We Must Bake, Rather Than Try
To Test Quality In!

18. Testing Pyramid

19. 19
Agile Does Not Move At Manual Testing
Speed

20. Automation (Test, Build, Release)
20
● Is anyone still testing manually?
● The slow manual testing practices of traditional QA will not
be sufficient to meet the new pace of iterative development
● If a full manual testing cycle is more than a week, then a
new testing cycle is needed as soon as the last deployment is
complete

21. Getting To Agile QA in 3 Easy Steps
Culture of Quality
Organic Not Mechanical
Team Confidence is the Goal
Swagger is Good!
1. Establish Quality Standards and a Definition of
Done
2. Track and Make Metrics Prominent
3. Automate Everything

22. Team Confidence
22
● Confidence in the codebase is the key to:
● Generating
momentum
● Having choices
● Velocity
● Autonomy
● Adaptability
● Competitive
advantage
● And the inherent
propensity for
innovation and
luck

23. Traditional Team Ownership of Quality
● Historically QA has been:
◦ An event that occurs after development is done
⚫ Point in time validation rather than an ongoing standard for
quality
⚫ Verification before production launch
◦ Held by QA
⚫ Not part of “Definition of Done” for the team
⚫ Not part of what every member of the team was committed
to uphold.
◦ Part of a rigid sequential process
⚫ At the end of development
⚫ An event rather than an ongoing concern

24. Whole Team Ownership
● Quality as a fundamental ongoing concern for the
team
◦ Not just at the end of a release
◦ Meeting quality standards has become a part of the
“Definition of Done” for the whole team
● An Integrated Team Focus
◦ Teams take ownership
⚫ Definition of Done
⚫ Quality Standards
⚫ Level of quality being produced every day
● Business Verification
◦ Weekly verification demo
◦ Product Owner Drives the Demo

25. Exercise 2
25
Review Designs for Feasibility (2 Min)
Iteratively:
1. Estimate Production (1 Min)
2. Develop/Quality Check Plane(s) (4 Min)
3. Retro & Metrics ( 2 Min)
2 Iterations
Report outs

26. Exercise 2 Success Criteria
26
● 1 Plane must gently fly 18 feet
● Plane must have a 5 point star on the
underside of each of the wings
● Plane cannot have any markings on the
topside of the wings
● Team must capture:
◦ Estimated Production vs Actual Production
◦ Defects Found (Pre-Dev, Dev, Testing)

27. Questions
● Did you feel constrained to use a design
from the packet?
● Did the team own quality or did the QA
role?
● Did you capture accurate metrics?
● Did you make more than one plane? (Over-
achievers)