If developers have autonomy, mastery and purpose, what do you need testers for?
At the latest FroGS conf open space, I hosted a session around the question:
If developers have autonomy, mastery and purpose, what do you need testers for?
Not because I believe that obviously in that case you don’t, but I thought exploring the question would clarify the different roles a tester might have in different organizations.
After briefly sharing my own answers and my critique on the premise of the question, we had a great discussion with the group. As this post is based on the session as a whole (without claiming to cover everything that was discussed), I want to give a big thank you to everyone who participated in it.
Sidenote: for a post about a different session at the latest FroGS conf, read Elizabeth Zagroba’s post “Tortured Fish Metaphors”.
Autonomy, mastery and purpose
In his book “Drive” Daniel Pink claims that:
The three key elements in enduring motivation are autonomy, mastery, and purpose. Autonomy is having a measure of control over what we do and how we do it. Mastery is making progress and getting better at something that matters. Purpose is doing something that makes a difference in the world or a contribution to others. (source: author’s site linked above)
I put those three elements in the question not because I think they are the be-all and end-all for work or software development. I did it because they’re fairly well-known and because they provide a good baseline for an organization. If developers have autonomy, mastery and purpose, arguably they’re in a position to deliver great work. Which sets up the second part of the question: if they’re delivering great work, what do you need testers for?
I’ll explore the first part of the question, its premise, later in this post. First I’ll list some circumstances in which you might (or not?) still need testers, even when your developers have autonomy, mastery, and purpose.
You might still need testers
When you have no developers
If your organization has to do acceptance testing, as in: testing to accept a piece of software - often in a contractual sense, there are developers involved, but they are not yours. You might have outsourced the full development, or you might be customizing and configuring an off-the-shelf product. In any case, you will need to test this piece of software, without (fully) being able to rely on how good a job the developers did. (One could additionally argue that the developers in these situations tend to not have a very high level of autonomy or purpose).
Similarly, you might want to do chain testing (aka end-to-end testing) over several applications. That will require a separate testing team that operates apart from developers. Even if the testers in that team are members of the teams owning all the applications, they are (temporarily) operating in two teams: their development team and the chain testing team. That second team does not have developers.
For the skeptical attitude and critical distance
Programming is an optimistic endeavor. A lot of things have to go right for a single line of code to do what it’s intended to do. Testing is a skeptical endeavor. Reality is so much more rich and varied than you can ever imagine and yet you need to somehow anticipate and explore all of it - or at least the most important parts of it.
So there is an argument to be made that in general developers feel more comfortable in that optimistic mindset and testers in that skeptical mindset. I don’t buy it though. First of all, it feels like a gross overgeneralization, not based on any solid empirical data. Secondly, anyone who has been in an architecture or refinement meeting with good developers, has seen developers have no problems with taking up that skeptical attitude.
Which leads to the argument of critical distance. You need a tester because it’s easier to have the required critical distance for testing, when you’re not the person who built the thing you’re testing. While I agree that testing something you’ve just built, is hard, why is the only solution a tester? Why not a different developer on the team? Or the same developer but the next day, or after their lunch break?
So personally, I find neither argument very convincing. It reminds me too much of the argument that testers should not have access to the code, otherwise they can’t do black-box testing. To me it makes much more sense to give testers access to the code, while also ensuring they have the skill to recognize when they make a decision that’s informed by their knowledge of the code. The benefits of having access to the code greatly outweigh the occasional failure of not recognizing those moments.
Similarly, I don’t see a reason why being a developer would make you unable to have the skeptical attitude or the critical distance required to do good testing. The limiting factor here seems to be the organization, more than the people.
Because developers already have to do so many things
As a counter to the previous section, of letting developers do all the testing, I think it is fair to say that developers have too much on their plate already. They need to design, write, and test code. Keeping performance, security and accessibility in mind as they do so. They should have domain knowledge. They’re involved in planning and refining work. Then there’s infrastructure and Ops work. They need to do process improvement, if only be participating in retros. And of course, they need to collaborate and communicate well.
And not only should they be able to do those things, they should also keep themselves up-to-date with new developments in those areas.
So maybe, that list is long enough and we shouldn’t be adding the full breadth of software testing skills, knowledge and tooling to it as well.
However, each handover is a loss of knowledge. And with that a loss of learning. Also, once you have testers to do the testing, they will fill up their time with testing. Even if some of the testing they do, isn’t that important. But what else are they supposed to do with their time?
So if we want take something off the developers’ plates, maybe testing should stay/go on and some other things need to come off. Maybe there are better ways of splitting up the work than in programming and testing. Maybe we shouldn’t be talking about programming versus testing, but about the team members’ capability combs.
Activities over roles over titles
The capability comb and the three reasons above highlight something important: we should distinguish activities, roles and titles. You can do testing, perform the role of a tester, you can be a tester. These are three different things. And we tend to conflate the three, resulting in weird dynamics.
A developer can (and should) do testing. They can perform the role of a tester, switching from a programmer role, briefly or for a longer period of time. A developer can’t be a tester, in the job title sense, because that’s not how HR operates.
Unfortunately we tend to focus on that last part, the titles: you are a developer or you are a tester. Developers go to developer conferences. Testers go to tester conferences. And rarely the two will meet. And that’s such a shame.
Your developers might not have autonomy, mastery or purpose
Now that we have explored some answers to the question, we shouldn’t forget to explore its premise. How often do developers actually have autonomy, mastery or purpose?
Developers without autonomy will get pressured to produce more features, more faster. They don’t get to spend time refactoring. Or write unit tests. They don’t get a say about the quality of what they build, especially not the internal quality. They get a Jira ticket and a deadline.
Developers without mastery lack some of the skills required to their job. Or their environment prevents them from using them. Or they are not allowed to take any time for learning on the job. They’re stuck in a loop, where 10 years of experience is actually 1 year of experience 10 times over.
Without purpose, a developer is alienated from their work. They follow the process steps, they go through the motions, but there’s nothing more there. All they get for their time an energy, is a paycheck.
If you take away enough autonomy, mastery, and purpose, you get demotivated developers. Quality suffers as a result. So yes, then you need testers. To try to fix things. Which basically means that the worse your organization is, the more anti-patterns it displays, the more testers you will need. To try to test some level of quality in at the end. And we all know how well that works…
This is not a new insight. Elisabeth Hendrickson described it in her 2001 paper “Better Testing, Worse Quality”. If your organization communicates through everything it does that the testers will take care of testing and quality, guess what effect that will have on everybody else?
So where does that leave testers?
A cynical interpretation is that as a tester you will always end up in moderately to highly dysfunctional organizations, because they’re the ones that tend to hire testers. Then you have the choice of either expanding or contracting your role. Contracting as in: creating a safe island, where you just execute your tests based on the acceptance criteria, or where you just write test automation based on the test scripts you were given. Alternatively you can expand your role: try to address some of the dysfunctions and make things better. Neither are great choices, although both are valid.
A more optimistic interpretation is that people working together is always a messy business. People, processes, tools, none of these are flawless. Something is lost in every transition. And bugs tend to hide in those transitions, in the boundaries. Which is true both for process bugs and product bugs, by the way. So the conclusion to all of this might be: what testers do, is filling in the gaps. I still have some very ambivalent feelings about that, though.
What was your initial reaction to the question: “If developers have autonomy, mastery and purpose, what do you need testers for?” And what was your reaction after giving it some thought? How would you respond to this question?