The Three Pillars of Agile Quality and Testing: Crosscutting Concerns
The Three Pillars is a framework for establishing a balanced strategic plan for effective quality and testing:
Pillar 1: Technical practices, such as BDD-based requirements and testing
Pillar 2: Testing practices, such as risk-based testing practices and more formal test planning
Pillar 3: Collaborative and mindset practices, such as collaborating around user stories and having discussions
Foundational Practices
Beneath the three pillars are some foundational principles and practices that glue everything together. For example, taking a whole-team view of quality and testing, where it is not just the responsibility of the testers, but of everyone on the team. Continuously challenging this position and coaching the teams toward whole-team ownership is an ongoing focus.
Another foundational area is metrics. We all know that what you measure drives the behavior of the team. As we move toward agility, we need to begin measuring team results rather than functional results. However, we must also show care when measuring the team—for example, understanding that velocity is probably not the best metric to measure a healthy team.
One component that permeates through the pillars and the foundation embraces the core idea that each agile, self-directed team has a basic responsibility to build the right things (customer value) and to build them properly (design, construction integrity, and quality).
Crosscutting Strategy
Beyond the individual pillars themselves, the real value resides in crosscutting concerns. I have a favorite story I use to help make this point. My client was advanced in behavior-driven development (BDD) practices but was struggling with writing user stories.
The results would have been better if the client had made the following cross-pillar connections:
- In Pillar 1: BDD and acceptance test-driven development (ATDD) are mostly technical practices. They focus on articulating user story acceptance testing in such a way as to make them automatable via a variety of open source tooling. Unfortunately, BDD and ATDD have an underlying assumption that you understand how to write a solid story.
- In Pillar 2: One thing I did not mention in the story was that every team had a different view of what a story should look like and the “rules” for writing effective stories. There were no norms, consistency rules, templates, or even solid examples. A focus on the software testing aspects of Pillar 2 would have established these practices, which would have significantly helped their teams.
- In Pillar 3: An important aspect of the user story that my client failed to realize was the conversation. If you reference the "three Cs" of effective story writing as a model, one of the Cs is "conversation," where team members communicate and collaborate on the story. The developer(s), tester(s), and product owner(s) get together and leverage the story to create conversations that surround the customer problem they are trying to solve.
Do you see the pattern in this case?
You cannot effectively deliver on agile quality practices without crosscutting the concerns and focus. In this case, effective use of user stories and standards, plus BDD and automation, plus the conversations needed to cross all three pillars. It requires a strategic balance in order to implement any one of the practices properly.
I hope this example illustrated the crosscutting nature for effective use of the Three Pillars, and that you start doing that on your own, as well. For a free PDF copy of The Three Pillars of Agile Quality & Testing, please join my mailing list. You’ll then gain access to my website downloads area.
Bob Galen will be leading tutorials based on his Three Pillars framework at STAREAST 2015.
