The document discusses the drawbacks of dedicated QA roles in agile environments, emphasizing that such roles can create inefficiencies and hinder innovation. It advocates for a model where developers take on testing responsibilities, enhancing speed and quality of delivery. Additionally, it suggests various strategies to maintain quality without traditional testing methods, such as code reviews and automated testing.

1. SO WE’RE GOING “NO QAS” –
HOW DO WE GET THE DEVS TO DO ENOUGH
TESTING?
Steve Wells
steve.wells@marks-and-spencer.com
July 2017

2. BACKGROUND
2

3. AGILE CAMBRIDGE 2016 - “DON’T GO
CHASING WATERFALLS”
3
• Scrum has only 3 roles, PO, SM and developers
• No BA, no QA, no DBA, no other (dedicated) roles – only “T-shaped
people”
• These other roles are common in scrum teams, particularly (manual) QA
• They cause a waterfall…

4. AGILE CAMBRIDGE 2016 - “DON’T GO
CHASING WATERFALLS”
4
PO
Dev
QA

5. WHY IS THIS SO BAD? (JUST BECAUSE IT
ISN’T “SCRUM”)
5
Silos
Efficiency
Over-the-wall Thinking
Undue power
of sign-off
Unnecessary delays
(while bugs are triaged)
Stifles Innovation
Just not agile!
Risk
Blocks improvement
Not failing early

6. Is this the real resource
requirement, every
hour, of every day of
every sprint?
33%
17%
50%
EFFICIENCY?
6
• Is this really how the work is split
every hour of every day of every
sprint?

7. AGILE CAMBRIDGE 2016 - “DON’T GO
CHASING WATERFALLS”
7
• Do certain people really have a “testing gene” that makes them better at
testing than developers?
• If testers find a bug that customers will never find, do we care? Particularly if
that delays release and stops us getting early feedback?
• Are a couple of QAs going to find (actual, customer impacting) bugs as
quickly as (say) hundreds on a beta program?
• Are dedicated testers going to be able to understand the complexities of the
codebase, and the best way to use testing frameworks?

8. AGILE CAMBRIDGE 2016 - “DON’T GO
CHASING WATERFALLS”
8
• Spotify DIBBs (Data-Insight-Belief-Bet) philosophy -
https://www.infoq.com/news/2016/07/spotify-good-at-failing
speed of iteration
beats
quality of iteration

9. AGILE CAMBRIDGE 2016 - “DON’T GO
CHASING WATERFALLS”
9
• Case study based on 3 teams in Sky
• Not having dedicated QAs increased speed of delivery and improved
quality (fewer bugs/rollbacks, improved customer reviews)
• Bugs spotted earlier, so faster fail

10. SO I GAVE THIS TALK…
10

11. HOW DO WE GET THE DEVS TO DO
ENOUGH TESTING?
11

12. WHAT IS “ENOUGH” TESTING? WHAT ARE WE
TRYING TO ACHIEVE?
12
Deliver the
most value
Stability
“Zero” (acceptable
level of) defects
Quickest possible
feedback Speed of delivery
and rollback
Maintainability
Quality Security

13. WHAT IS “ENOUGH” TESTING? HOW DO WE
ACHIEVE IT?
13
• Many other strategies to improve quality apart from testing…
• Code reviews, walkthroughs
• Design patterns, include proved code
• Pair programming
• Coding standards, linting, etc
• Beta groups
• A/B and multivariate testing

14. 14
Full team
responsibility

15. 15

16. Empowered Team
Team Success and Failure
Motivated Team
Quality Baked In
Data and Visibility

17. 17
A model for
high-performing
teams
Simon Powers

18. 18
Support what they build

19. 19
Stop all “over the wall thinking”

20. 20
Don’t recruit to roles

21. RECRUITING TO ROLES
21
• Who would test your app the most realistically?
a) Something with expert knowledge of app testing theory?
b) Someone with initimate knowledge of your products and how the app is
used in the real world?

22. 22
Automate
everything

23. TESTING AUTOMATION – REVERSE THE
CONE!
23
Manual
Automated
Measure: coverage, areas
of failure, time to run etc,
etc.

24. TESTING AUTOMATION – “SHIFT LEFT”
24
development test
development and test

25. 25
• Aside: An example of where manual testing is damaging -
https://www.linkedin.com/pulse/manual-testing-always-necessary-fact-
sometimes-bit-dangerous-wells
Confi
g
Objec
t
Endpoint 1
Endpoint 2

26. 26
YES, BUT SOMETIMES, YOU
STILL NEED MANUAL
TESTING…

27. 27
YES, BUT SOMETIMES, YOU
STILL NEED MANUAL
TESTING…

28. 28
YES, BUT SOMETIMES, YOU
STILL NEED MANUAL
TESTING…

29. 29
Play the “shiny new stuff’
card

30. 30
• Team of 8 with 1 tester
• Replace tester with dev
• We get nearly a whole extra person
• We only have to do 1/8 of the testing
each
DO THE MATHS

31. 31
Make it
competitive

32. 32
Cross-

33. THINGS TO AVOID
33
• Rotating the QA role
• Allowing developers to refuse to test
• The “dev in test” role
• The phrase “dev-complete”
• “We’ll release, then come back and write tests later…”

34. IF THE PO IS ALSO CAUSING A WATERFALL,
WHY NOT GET RID OF THAT ROLE AS WELL?
34
PO
Dev
QA

35. IF THE PO IS ALSO CAUSING A WATERFALL,
WHY NOT GET RID OF THAT ROLE AS WELL?
35
PO
Dev
Deliver
Team

36. 36
Quicker, faster,
cheaper, higher
quality deliveries –
really, what’s not
to like?...
steve.wells@marks-and-spencer.com