The 3 Pillars Approach to Agile Testing StrategyGo Back
- Posted by Daragh
Far too often agile adoptions focus just on the development teams, agile frameworks, or technical practices as a part of their adoption strategies. And then there’s the near perpetual focus on tooling or developing test automation without striking a balanced approach. Often the testing activity and the testing teams are “left behind” in agile testing strategy development or worse yet, they’re simply “along for the ride”. That is not an effective transformation strategy.
Experienced agile coaches Bob Galen and Mary Thorn share the Three Pillars framework for establishing a balanced strategic plan for effective quality and testing. The Three Pillars focus on development and test automation, testing practices, and collaboration activities that will ensure you have a balanced approach to agile testing. Specifically, risk-based testing, exploratory testing, paired collaboration around agile requirements, agile test design, and TDD-BDD-Functional testing automation will be explored as tactic within a balanced Three Pillars framework.
Agile Testing Strategy
Bob and Mary’s approach to Agile Testing strategy involves first thinking about Agile as a whole. The three pillars of Agile Testing are:
1. Development & Test Automation:
This pillar is the technology-side of quality and testing and it’s not simply focused towards testing and testers. It includes tooling, execution of the Automation Test Pyramid, Continuous Integration, deep use of Extreme Programming technical practices, and support for ALM distributed collaboration tools. Often it’s the place where organisations gravitate towards first—probably because of our general affinity towards tools and technology solving all of our challenges. An important way to think about this pillar is that it is foundational, in that the other two pillars are built on top of the tooling. And often, organisations underestimate the importance, initial cost, and ongoing costs to maintain foundational agility in this pillar. Investment and focus is an ongoing challenge here; see Mary’s Corner below. Finally, this pillar is not centric to the testing function or group. While it includes test tooling and automation, it inherently includes ALL tooling related to product development across the entire agile organisation. It provides much of the ‘glue’ in cross-connecting tools and automation towards efficiency and quality.
2. Software Testing:
This pillar is focused towards the profession of testing. Towards solid testing practices, not simply agile testing practices, but leveraging the teams’ past testing experience, skills, techniques, and tools. This is the place where agile teams move from a trivial view to software testing, which only looks at TDD, ATDD, and developer-based testing; towards a more holistic view of quality and testing. It’s a pillar where functional and non-functional testing breadth and depth is embraced. Where exploratory testing is understood and practised as a viable testing technique. It’s where non-functional testings’ breadth and requirements are fully understood and applied to meet business and domain needs, including: performance, load, security, and customer usability testing. By definition, here is where testing strategy resides, where planning and governance sits, and where broad reporting is performed. To be clear, I’m not talking about traditional testing with all of its process-focus and gatekeeper mindset. Instead, I’m talking about effective professional testing, broadly and deeply applied within agile contexts.
3. Cross Functional Team Practices:
Finally, this pillar is focused towards crossteam collaboration, team-based standards, quality attitudes and importantly towards building things right. Consider this the soft skills area of the Three Pillars, where direction is provided for how each team will operate. You could also consider them “rules of engagement”. For example, this is the place where good old-fashioned “reviews” are valued. This would include pairing (across ALL team members), but also slightly more formal reviews of architecture, design, code, and test cases. It’s a place where inspection is valued and performed rigorously as established by the teams’ Definition of Done (DoD). Where refactoring of the code base and keeping it “well kept” is of prime importance. Speaking of DoD, this is the pillar where cross-team physical constraints, conventions, and agreements are established. But more importantly than creating them, it’s where the team makes commitments to consistency and actually “holding to” their agreements. And those agreements (or promises) include those to the customer for delivering high-value, high-quality, and high-impact features that truly solve their problems. I’m sure many readers will have differing opinions regarding the Three Pillars. Why three for example, why not four or five? Or why was this practice placed here vs. there? Or you’ve forgotten “this” – does that mean it isn’t important? I’ve seen this same type of over analysis occur in the 4 Quadrants of Agile Testing that Lisa Crispin and Janet Gregory have shared in their book. An important point to emphasise about the Three Pillars is to not get too hung up on the model. It’s not intended to constrain you or to serve as the definitive view of agile testing. It’s simply a model. Ultimately my intent is to get you thinking about your agile testing, and to help guide you towards more balanced strategies. Please don’t take it too seriously. It’s a thinking tool and a starting point. Yes, I think it’s sound, but I want you to make it context-based to YOUR context.
Foundations of the Pillars of Agile Testing
There are some key concepts that permeate through the model and across the Three Pillars. They are first concepts that are crosscutting in nature—serving as a foundation. But they’re also things that, at least in my estimation, are ongoing goals rather than things you achieve overnight. Instead, you should be constantly focusing on, investing in, talking about, and evolving them within your agile transformation.
- Whole-Team Ownership
- Knowing the Right thing to Build; And Building it Right
- Healthy Agile Metrics
For more on developing your agile testing strategy, you can download the ebook from Bob and Mary here