Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à So we're going no-QA - how do we get the devs to do enough testing?
Similaire à So we're going no-QA - how do we get the devs to do enough testing? (20)
Dernier
Dernier (20)
So we're going no-QA - how do we get the devs to do enough 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
- 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?
- 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
- 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
Notes de l'éditeur
- Note: This doesn’t just apply to Scrum! Scrum and agile are *not* the same thing!
- So I gave this talk, and got mobbed by angry testers. However, of more interest to me was the question on the next slide, which was asked by Scrum Masters, Pos, etc. etc.
- From the original scrum guide – in terms of breakfast, chickens are involved, pigs are committed. Make your teams into pigs (as it were )
- You wouldn’t let someone else pack your parachute! Same with software – don’t rely on other teams (integration, e2e, etc.) to do your testing – make it perfect before it leaves the team…
- Once you have headcount for “a tester” or “a QA” or any other role such as “front-end developer”, that defines salary ranges, job specs, etc. etc. Only recruit T-shaped people, and don’t define roles apart from “developer” or “engineer”
- The case given was software that flies planes, I do *not* actually want humans testing that!
- Make it competitive between team members, but keep it light-hearted!
- The PO should be embedded in the team and work in collaboration with the team. The team as a whole make the decisions…