Why so few Agile testers?
Because most companies are faux-Agile…
Why are QA and tester roles a rare view in Agile projects?
The legacy
When working on waterfall projects, the role is kind of obvious: it’s basically checking compliance to the specification — even when the role is named “QA” for Quality Assurance!
Moving to Agile
However, this part of the development chain is precisely what disappears when moving to Agile:
- Team is expected to be very mature about his Definition of Done, making sure that the software produced is of very high quality.
- Specification kind of becomes a rude word in Agile… Preferring live discussions and collaboration between the team and the customers and stakeholders.
So what’s left to the tester in this new Agile world?
The Agile tester?
I want to give a shot at defining the Agile tester role.
This is a drawing I made recently about my vision of the Agile tester. Let me comment it further:
- A key role during backlog grooming/backlog refinement, helping the whole team to think about testability, tricky cases, and so on.
- An expert on writing automated test case scenarios, helping the whole team become proficient with this special activity. A good test case is all about the business and should be understandable by the business people. Yet a test case is also pulling strings to technical components! In the end, writing good automated test case is a skillset by itself.
- Exploratory testing. Non-exploratory tests are mostly automated and hence a main responsibility of the developers.
- Continuous testing, testing new developments before even they are finished. Working in pair with other team members is common.
- Monitoring : exploring logs to better understand the users and to find unexpected behaviors only encountered by some users.
- Maintaining automated test case repository as a whole. Like developers, applying a continuous refactoring mindset. Also working with other teams to make sure all the tests are written consistently.
- Manage crowdtesting sessions: providing test cases, training the testers if necessary, untangling test results. All this with the specific constraints of crowdtesting: remote, many testers with mostly no direct access to them.
- A full member of the team. Like any other team member, the main way to tell if the tester is doing a good job is to look at the team’s performance as a whole.
Nothing’s about checking compliance to the spec, yet the Agile tester is very valuable to the team
As you can see, the Agile tester has a lot of work to do — but nothing is about this check that the developers followed the spec.
Instead, the Agile tester…
- Puts a major part of his time into helping the team think about interesting cases right from the start, and to help writing them as automated test cases. That way, developers can check compliance by themselves. Plus the continuous integration will raise a flag if developers have not been thorough enough.
- Brings unique skillsets in the team about risk analysis and exploration. He’ll strain the product beyond the initial acceptance tests through exploratory testing — a skill the rest of the team is usually lacking. Furthermore he’ll perform these extra tests as early as possible, even right from the beginning of development, to literally build quality into the product. Not to mention that the earlier a bug is detected, the cheaper it is to fix.
- Gets feedback from real users using their own device and setup in production: the tester will put his unique exploration skill to log analysis. He will find bugs that users actually encounter, but will also provide interesting insights to the next product design session. He will also leverage crowdtesting to generate more explicit feedbacks, or to perform more comprehensive exploratory sessions.
Agile tester vs. waterfall tester: same core skills
So the Agile tester job has definitely not that much in common with the tester from the old days… Or has it?
Both waterfall and Agile testers share the same foundations:
- Analytical mindset, at ease with risk-analysis and return-on-investment
- Ability to explore a product and to smell dubious behaviors
- Understand and speak both business and technical languages, and at ease to bridge both
It seems to me that thus it should be natural to move to the Agile tester role. The waterfall tester already have all she needs. Obviously she’ll have to learn many things but, again, it’s more about practices and methods than it is about core skills and mindset.
Why so few Agile testers?
… Which gets us back to the original question we asked ourselves: why is it common to see Agile teams with no testers at all?
Given that the waterfall and Agile testers are not that far from each other, getting Agile testers on the team should not be that much harder than getting waterfall testers.
The answer might not be in the role itself
Maybe we need to look at the question from a different angle. What are managers expecting from an Agile team?
Well, that will sound sad, but most managers are simply expecting from the team to deliver. Preferably at a reliable, steady, predictable rate.
So in this context, managers would ask:
What’s the production capacity of this resource?
Obviously it’s very hard to answer to this question if we are talking about a tester.
Sure, the tester would help reduce the number of defects, saving money and freeing development time. But it’s not that easy to count, especially since the goal is to prevent defect generation at the earliest stages of development.
In a well-running team, there is simply no tracking of the bugs that are NOT created every day.
The tester will also find bugs that would go unnoticed otherwise, through exploratory testing, crowdtesting, or log analysis. However in the eyes of the previously mentioned managers this is closer to a loss of productivity capacity than an improvement.
It’s all about product, users and value
Indeed it might not be obvious how a tester is improving the production capacity of the team.
But it’s obvious that the tester will bring value, through focusing on the user experience and overall building a better product.
Basically the idea is the following:
tester➛great product➛awesome user experience➛delighted users➛$$$
This is called a user-centric approach: focusing on users and on their experience of the product is a more sustainable and profitable way to make money.
My bet is that if you’re doing well without an Agile tester, chances are you’re not in such a user-centric approach.
Not being truly Agile
Indeed, “moving to Agile” and not embracing product management and focusing on the user is a sure way not to be Agile. Too often, the move to Agile is only superficial.
You don’t need a tester if you’re not Agile
Let’s be honest: you don’t need a tester to check compliance to a spec.
Most managers understood this and simply stopped hiring testers in their teams. In some way, it is a good thing: if you’re only focusing on delivery, indeed it will be hard to justify the cost of the tester.
Yet I’m having a hard time to qualify such a setting as “Agile”: Agile is about focusing on value, on the user and on the product.
While the waterfall tester helps making sure the project is not a failure, the Agile tester helps a great product become an awesome one!
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!
