Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

So we're going no-QA - how do we get the devs to do enough testing?

266 views

Published on

Talk from Agile Cambridge 2017 about how to improve speed and quality of releases by getting rid of manual testers in agile teams.

Published in: Software
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/CEseB5 ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

So we're going no-QA - how do we get the devs to do enough testing?

  1. 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. 2. BACKGROUND 2
  3. 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. 4. AGILE CAMBRIDGE 2016 - “DON’T GO CHASING WATERFALLS” 4 PO Dev QA
  5. 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. 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. 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. 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. 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. 10. SO I GAVE THIS TALK… 10
  11. 11. HOW DO WE GET THE DEVS TO DO ENOUGH TESTING? 11
  12. 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. 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. 14 Full team responsibility
  15. 15. 15
  16. 16. Empowered Team Team Success and Failure Motivated Team Quality Baked In Data and Visibility
  17. 17. 17 A model for high-performing teams Simon Powers
  18. 18. 18 Support what they build
  19. 19. 19 Stop all “over the wall thinking”
  20. 20. 20 Don’t recruit to roles
  21. 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. 22 Automate everything
  23. 23. TESTING AUTOMATION – REVERSE THE CONE! 23 Manual Automated Measure: coverage, areas of failure, time to run etc, etc.
  24. 24. TESTING AUTOMATION – “SHIFT LEFT” 24 development test development and test
  25. 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. 26 YES, BUT SOMETIMES, YOU STILL NEED MANUAL TESTING…
  27. 27. 27 YES, BUT SOMETIMES, YOU STILL NEED MANUAL TESTING…
  28. 28. 28 YES, BUT SOMETIMES, YOU STILL NEED MANUAL TESTING…
  29. 29. 29 Play the “shiny new stuff’ card
  30. 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. 31 Make it competitive
  32. 32. 32 Cross-
  33. 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. 34. IF THE PO IS ALSO CAUSING A WATERFALL, WHY NOT GET RID OF THAT ROLE AS WELL? 34 PO Dev QA
  35. 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. 36 Quicker, faster, cheaper, higher quality deliveries – really, what’s not to like?... steve.wells@marks-and-spencer.com

×