The New Agile Testing Quadrants: Bringing Skilled Testers and Developers Together - James Bach
3 likes11,944 views
The document critiques existing models of agile testing quadrants, arguing that they misrepresent the role of testers and the nature of testing as distinct from simple output checks. It emphasizes that testing is a collaborative and dynamic process that cannot be reduced to static representations or mere documentation, urging a focus on value and adaptability in agile practices. The authors advocate for an inclusive understanding of testing that integrates diverse perspectives and promotes ongoing dialogue within agile teams.
The New Agile Testing Quadrants: Bringing Skilled Testers and Developers Together - James Bach
- 1. The New Agile Tes,ng Quadrants: Bringing Skilled Testers and Developers Together James Bach james@sa,sfice.com Michael Bolton michael@developsense.com) (and with helpful comments from Interna,onal Society of SoAware Tes,ng members: Anne-‐Marie CharreI, James Lyndsay, Simon Morley, and Ben Kelly)
- 4. • Marick’s original confuses concept of cri,cal distance with that of process integrity– sees simple output checks as more “integral” to the programming process than vigorous tes,ng. (Let’s treat it all as connected together. It’s agile, dammit.) • Crispin/Gregory version implies that cri,que is not suppor,ng the work of programming. This helps perpetuate the ignorant aVtude that testers do not belong in Agile unless they write code. (Tes,ng IS suppor,ng the team. Testers ARE on the team.) • Both versions confuse output checking (which is completely automatable) with tes,ng (which is not). (Tes,ng is a live thought process, just like programming.) • Crispin/Gregory version makes confusing and unnecessary dis,nc,ons about tes,ng with tools and without tools. (Tools are not remarkable in tes,ng. Good testers use them anywhere.) • Both versions pin certain techniques and approaches to certain quadrants. (Any test technique or approach may relate to any quadrant– which represent overarching tasks and goals.)
- 5. “Facings” are beside the point. • THE BUSINESS needs us to produce something of value. • THE BUSINESS needs us to do that efficiently. • THE BUSINESS needs to learn what it values over ,me rather guessing and freezing that guess forever. • Hence, the core heuris,c of agile: con,nually re-‐focus on value (in order to produce value) and ply our craQ in ways that reduce the cost of change (rather than deny change). • “Technology-‐facing” simply means doing things that help us build with change in mind– an ac,vity our business clients need but do not directly care about (or some,mes even know about.)
- 6. Reifica,on Fallacy • The versions of the quadrants I’ve seen also commit the “test cases are tes,ng” and “examples are tests” reifica,on fallacies. • Tes,ng cannot be encoded. (Just as “programming” cannot be encoded. You cannot “code me a programmer.”) • It is pointless to discuss whether “business people” can “read the tests” because what they can read are not tests– they are par,al representa,ons of tes,ng ac,vity, or else they are checks. • If you try to communicate tes,ng primarily through wri,ng then you are doing it wrong (viola,ng Agile principles). Instead: prefer conversa,on and demonstra,on.
- 7. Dimensions of Crispin/Gregory “Agile Tes,ng Quadrants” Based on Marick
- 8. First, refactor those dimensions… (This version avoids alienating professional testers and more directly addresses the tension between business and technology “facings.”) “Con,nuous aIen,on to technical excellence and good design enhances agility.” “Our highest priority is to sa,sfy the customer through…valuable soAware”
- 9. And remind ourselves of the core tac,cs of Agile…
- 10. And remind ourselves of the core tac,cs of Agile… (These are the core tactics as we see them. You may prefer a slightly different list.)
- 11. But hold on a moment. Development plays out over ,me… All development of any new design works like this.
- 12. But hold on a moment. Development plays out over ,me… Waterfall “Built it right the first ,me.” Agile “Build with change in mind.”
- 13. So, we have our clockwise cycle…
- 14. …and corners that represent enabling paIerns.
- 15. “As” does not mean “aAer”
- 16. Although there is a cyclic tendency to these ac,vi,es, they also overlap, combine, and support each other, in big loops, small loops, sudden turns, and epicycles. Like swirls from s,rring a cup of coffee… …not like being ,ed to the hands of a clock Development isn’t strictly sequen,al!
- 17. Stories, spikes, itera,ons, sprints, releases; whatever name for some burst of development work.
- 19. Now, let’s create the tes,ng quadrants…
- 20. Each quadrant represents a set of Agile tes,ng ac,vi,es. (Testing suffuses Agile development, but the character of the activities is quite different in each of the quadrants.)
- 21. (Notice that there are no test techniques or tools listed in the activities. That’s because test techniques and tools do not live in any particular quadrant.)
- 22. “Distance” refers to the difference between one perspective and another. Testing benefits from diverse perspectives. Shallow testing doesn’t need critical distance, but deeper or naturalistic long- form testing tends to require or create more distance from the builder’s mindset. Deep tes,ng requires cri,cal distance.
- 23. Envisioning Success An,cipa,ng Failure Focusing Mindset Defocusing Mindset
- 24. Central Obstacle Divides Work Mt. Mindset NOTE: We do NOT claim that this work must be done by different people, or that the people must have different roles. We DO claim that roles on an agile team (collaborating with each other) are a powerful heuristic for solving the mindset switching problem. Developer skill focus Tester skill focus Business analyst skill focus
- 25. Skilled tes,ng and skilled development interact in a “trading zone” Peter Galison introduced the notion of a trading zone in Science as a situation wherein people from different disciplines try to work together despite their very different and incompatible concepts and language.
- 26. Collins’ Trading Zones Model
- 27. Complex Tes,ng Example #1
- 28. Example #2A: 3000 iden,cal queries on eBay in 1.5 hours, graphing number of hits returned What explains the weirdly different levels? 284900 283950
- 29. 0 200 400 600 800 1000 44700448004490045000 Index sim$V1 Example #2B: Simulator created by tester to explore one theory of the strange hit paIern: One Hadoop cluster out of a hundred has flaky servers in it.