George Lawton, from the ServiceVirtualizaton.com blog asked me for an interview. He was generally interested in KEYS to agile testing maturity. Something Mary Thorn and I have been “yacking” about for quite some time.
I thought it might be interesting to share his questions and my answers. It will even be more interesting to see “what parts” of my answers make it into his blog ;-)
Stay agile my friends,
Bob.
What are the best ways to determine how well an agile practice is really doing?
Two things come to mind. First is the health of the team. Are they working in a balanced fashion? Do they have time for creativity and innovation as they deliver on the customers needs?
And in a word, are they having…Fun?
The second critical focus is the delivery of value to the customer. And don’t view this as simply giving the customer what they asked for. No, it surrounds partnering with the client and, based on this relationship, delivering what they need to solve their problems.
I would include the quality of the deliverables as part of the overall value proposition. I.e. not only have we delivered the “right thing”, but we’ve “built it right” too.
What are the key elements of continuously improving an agile practice?
Again, I think of two key things. First, is a consistent focus on the retrospective as the cornerstone of continuous improvement. Too many teams today either skip their retrospectives entirely or they sort of “mail in” their engagement. In either case, they’re not taking their improvement responsibilities seriously.
Agile retrospectives need to be powerful, congruent and action-oriented meetings that take ideas and drive change and improvement.
Secondly, is that each team and team-member is responsible for improvement. Again, triggering from the retrospective, many teams come out of it looking for “someone else” to take on the improvements. They lack accountability for improvement. Another key then is team-based accountability towards improvement.
My experience is that about 80% of the improvement ideas are within the teams’ capabilities to improve. So they need to carve out some time and take incremental steps towards changing things for the better.
What role does testing play in rolling out a successful agile practice?
There are some individuals and organizations in the agile community that believe that testing is something that can be done by anyone. For example, Microsoft, Facebook, and Google are famous for the notion of Software Developers in Test or SDET’s. They clearly don’t see QA or Testing as having much of a role in an agile transition.
I on the other hand have different experience. I think testing should have a “partnership” role with development within any agile transformation. I don’t accept the notion that developers can test as well as professional testers who have studied hard to understand and master their craft.
The other key point is that I think these “examples” where testers are “removed” are edge cases. They’re companies that are leaders in their spaces and that can get away with making their customers test their software. (Read: How Google Tests Software by James Whittaker for an example of this mindset). While it might work for them, I can see so many other business domains and contexts where the strategy fails because their customers want “working software”. Imagine that.
So in a word, testing should play a central and leading role in rolling out a successful agile practice. Anything else will be incredibly imbalanced in my view.
What are some of the key insights you have gleaned from your most successful agile testing transitions?
I’m glad you asked. I’m writing a book entitled – The 3-Pillars of Agile Quality and Testing. In it I explore some of the baseline patterns that are part of my experiences in creating high-performance test teams within organizational agile transformations. Some of the keys I’ve realized include:
1. Taking a whole-team view towards quality and testing; not just “dumping it” into the lap of the testers.
2. Establishing a partnership with the business-side, in this case with Product Ownership in ensuring that the team is solving the customer’s problems.
3. Empowering everyone to test and to automate, not simply thinking of it as a tester-level responsibility.
4. Incorporating test planning and execution as part of Backlog Refinement and Sprint Planning activity.
5. Avoiding the notion that you don’t need “professional testers” as part of your team, instead thinking that developers can do all of the testing.
Another theme is to actually include your testing organization in your agile adoption planning efforts. Far too often, it’s a technology or development-driven activity and the QA organization is sort of “left behind” or an afterthought. In my experience, all three organizations: Product, Development, and QA / Testing need to be strong partners in any truly successful agile transition.
You can join a mailing list to keep up with the development of the 3-Pillars book here.
What is your take on the current state of agile test automation strategies?
I actually only see one strategy at the moment that is working well within agile contexts – that is the Agile Test Automation Pyramid put forward by Mike Cohn so many years ago. It’s a three-level approach where you attack your automation at the Unit, Below-UI, and UI levels simultaneously, leveraging the same or different tooling of your choice.
I think what makes this space more interesting, and perhaps part of your question, is the ongoing development of tooling. I see the Open Source test automation tools basically leap-frogging traditional, enterprise level tools. But in addition, things like virtualization, cloud-based testing environments, and continuous deployment platforms continue to make this space incredibly interesting in its support of iterative agile delivery.
If you’re not familiar with the Pyramid strategy, I have an overview blog article here that describes it and the advantages of the approach over more traditional strategies.