There is a relatively common sentiment that tester roles, as opposed to the testing activity, should disappear entirely. We see that a bit with descriptions of jobs like “Software Development Engineer in Test” (SDET) which basically just means “developer who can test” rather than “tester who can develop.” Is this evolution necessarily an unhealthy one? Let’s talk about this.

One sentiment you’ll hear, often from developers, is that the development of code without a good deal of architectural thinking before will hurt you regardless of how much testing you actually have. And by “testing” here they mean testing done by the “tester role” after the coding has been completed.

Another sentiment, that the industry has picked up on, is that a “tester role” can only be effective if it has a position directly related to development. The idea here is that having the acts of “development” and the acts of “testing” separated tends to disengage people from their accountabilities and responsibilities regarding the production of quality work.

Are Those Good Sentiments?

That first sentiment is one I would agree with to a large extent. You need testing as a design activity (putting pressure on design) rather than solely as an execution activity.

And that leads to the second sentiment.. Should the tester role (as opposed to the testing activity) be subsumed into development? I think there is an argument to be made there. However, it’s not as simple as saying the tester role should be gone.

The tester role has to evolve. That evolution is in the process of happening as we speak and has been for the last couple of years. Actually, you could argue this has been an accelerated evolution over the last decade as pressures from different approaches — like “continuous” strategies, DevOps, and agile — have shifted and refined how people conceive of the value of testing in projects.

But Evolve How?

There is value in a testing mindset distinct from that of a development mindset. For example, good and effective testers have a very solid basis for dealing with categories of error, particularly in human thinking. Testers must also have a solid basis for the construction of narrative framing as business domains become more complex.

But it’s also true that all of this has to be in service to the development of products that people value. And, as such, the role of Developer — and I do firmly believe this — has to evolve to incorporate Tester. But where there is a distinct type of personality and skill set. The industry settled a bit on the SDET concept and that, to me, was the wrong place to settle. I say that because it’s put too much emphasis on the “technical” skills to the exclusion of skills like investigation, experimentation, and exploration. It’s conflated “Tester” not with “Developer” but with “Programmer.” And, quite honestly, developers should be against that trend as well.

So The Evolution Must Continue

The traditional idea of “verifying the software to make sure it meets requirements” is testing as execution activity. But there’s also, as I said, testing as a design activity. Meaning, putting pressure on design at various levels of abstraction. One of those levels is the requirements themselves.

And this gets to a point that I think testers need to repeat more often.

In development projects, people make their most errors when they are defining and/or elaborating requirements and expectations. This is where human communication and thought are most likely to fall prey to various cognitive biases and categories of errors. Testing — regardless of who performs it — puts pressure on that communication and thought, such that what is designed is better than what it might have been otherwise.

Obviously I would have to unpack a lot of that statement so it doesn’t sound terribly theoretical. But the key thing there for me is regardless of who performs it. The practice — not discipline — of testing can be carried out by everyone. In fact, testing is a democratized activity.

But I do believe there is still a notion of specialist testers; people who specialize in the practice and discipline of testing as it relates to investigation, experimentation, and exploration. Not everyone is good at those things, particularly when they have to straddle human level concerns with technology concerns; when a social discipline has to operate in the context of a technology discipline.

This, I believe, is one of the core challenges of the modern testing specialist who also wants to be a pragmatic (as opposed to reactionary) evangelist for the discipline.