TLDR; Are you getting the results you want from testing? If not, change how you test as part of the development process. Don’t change the role definition of “Tester”.
What is a Tester?
So the question is… what is a tester?
Now, for me, a tester is someone who tests and that is tautological. So it doesn’t really help explore a problem in a workspace like how do testers fit into agile.
But that’s the point.
The answer to most software development problems around testing is not, as it’s commonly the case, “we need a tester”, or “we need a tester who can coach”.
The answer is “we need some different ways of approaching testing”.
The verb “to test”, or the process “testing” is key.
The Process is Key, not the Role
Roles are often a shortcut way of trying to address a process problem.
We hire someone into a role and hope they will do the Process and solve the problems.
For me, discussions about “Do we need testers?” and “What is the Tester role on Agile?” are based on a different definition of Tester than I use.
With my tautological definition, the question “Do we need to testers?” becomes “Do we need to test?” and the answer is usually yes.
The discussion then moves on to, “well, how can we test?” and “do we have the right skills to test?”, and the focus moves on to the Process and not the Role.
If we want to share roles or processes amongst the team it can’t be isolated to a single role or a single person, it must be shared. And processes can involve multiple people.
People can do multiple roles, but they might not be able to do every process that’s in that role.
I often see people write “in agile, everyone tests”, and with a tautological definition, that would mean that everyone is a tester in addition to all their other roles.
Because we don’t usually do just one role.
That’s a different discussion.
The point I want to draw from “everyone as a tester”, at this point in time, is that Agile has historically said “everyone is a developer”. But that’s not really true since everyone is not: programming or designing or releasing or documenting or supporting.
How?
If we had phrased it as “everyone is a tester”, then we could look at “How are they testing?”, “Is everyone doing everything we would normally expect from that role?”
And if not then “what is missing?” and the discussion then comes back to the Process because in reality everyone can Test.
Everyone can get involved in the Testing Process in some way.
Everyone is a tester.
But the focus has to be.
“Are we doing Testing well enough?”
Saying that “Quality Is everyone’s responsibility”.
And “so everyone tests” is a fairly glib non-committal statement.
But saying “everyone is a Tester”, would suggest that the process of Testing is a key part, and a core part, of the development process.
Summary
So, in summary:
- at work and in teams, look at the roles that you have.
- evaluate, the expectations and biases associated with the role description, because role descriptions hide Process descriptions.
- The process is key.
“Are we getting the results we want?” If not, “how do we change the process to achieve those results?”
This was originally recorded on Racket in 202106
