There is a large debate ongoing in the testing community about how technical a tester has to be. I actually believe that a tester has to be technical enough to implement test solutions when they are most needed or know how to gather the skills to become technical enough. Pretty vague, huh? The problem is that it really depends on what test solutions you need and the skills needed to create them.

I read the article It’s Time to Wake Up the Tester in You. It’s a good article suggesting that engineers need to be putting on a testing hat periodically and thus be cross-discipline. The corollary, of course, is that testers also need to be cross-discipline to an extent. Does that mean a “technical” tester?

In thinking about that, I also read the article Do Testers and Software QA Engineers Need Technical Skills?. Clearly there is a lot of wiggle room regarding what is meant by “technical.” But there’s a wider issue here that even allows questions like these to be prompted.

Testing may finally be going back to what it started as — and that’s a positive thing!

After all, in the early days of app development, back when dinosaurs roamed the Earth and wore polyester, the same people who wrote software were the ones who tested it. Yet there was a point where the need for applications outpaced the ability of trained professionals to produce those apps. There just weren’t enough coders out there. Given that cloning wasn’t an option, one solution to this problem was to separate the roles of developer and tester. The idea being that to free up time of those trained to code, the problem of testing the code was put into the hands of a new class of professional.

Sounds logical, right? Well, unfortunately this new “profession” seemed to become a clerical one. The tradition of hiring “non-technical” people for testing roles became pervasive. This led to an industry where testers rationalized their lack of knowledge into how the technology behind their applications actually worked. This was even enshrined as a concept: “black box testing.” As opposed to making that just one approach, it was treated as the strategy. Testers spent time coming up with ideas for why it was “better” that they treated the system as a black box. After all, don’t our users? They don’t see the insides. And if I’m acting like a user, shouldn’t I be equally as unaware of the insides? (There’s a major assumption lurking there, right?)

The point is: testing started life as a technical discipline. A flood of non-technical testers took testing away from its roots, allowing (and even forcing) developers to come in and innovate and improve upon the very discipline that testers were claiming was their own province. That is why many test solutions out there are written by developers. That is why concepts like Test Driven-Development put more focus on the “development” than on the “test”, name not withstanding. The focus is on handling bugs at the code level.

I do believe it’s important to correct for the fact that along the way testing became treated as a reactive, clerical discipline. The reason for this is because testing simply will not advance if it doesn’t make this focus shift. It’s why we’ve seen the conflation of developer and tester roles and treated that as necessarily a good thing without necessarily questioning what the trade-offs are. It’s why there is a focus on, once again, people using testing as a stepping stone to development, as opposed to recognizing it as a dynamic discipline of its own. It’s why people focus on titles like SDET (Software Developer in Test), usually forgoing skills like business analysis, test case design, etc.

Values and Testing

A lot of this focus has actually taken away from the idea of systems of values. I really do believe this and I wrote about it in Resilient Teams and Systems of Values. Two other articles I acme across seem to highlight the cross-discipline idea of value when it comes to taking a broad view of testing and how it is practiced: Why Testers Need to Tune Out the Noise and Focus on Value and The Value of Developer Testing in Software.

The Wrong Focus

Some of the ambiguity I’m talking about was evident to me in the fact that someone could write The Day the QA Department Died. To my way of thinking, there is so much that is fundamentally wrong with that article. Not least of which is that it conflates the concepts of “QA” and “Testing”. In fact, maybe this article, better than any other, will show why I think it’s critical to maintain that distinction.

The article also seems to fundamentally misunderstand the notion of agile, using it to buttress an already flimsy argument.

That being said, I think the article does get one thing at least correct. It says: “I think we will see them working as part of the developer teams rather than in their own department.” The ‘them’ here refers to what the author calls ‘QA’. I agree insofar as I think the functions of a “QA team” need to become more distributed. (See my post Quality Assurance – Obviously for my thoughts on that). However, what the author should have meant by ‘them’ is “tester” and in that case I fully agree: the industry notion of a “tester” is moving to one that requires people with certain critical thinking abilities and mindsets — backed up with a technical background.

As QA and Test practitioners, my view is that we should be worried that articles like this are so prevalent. (And they are prevalent, even if only by implication.) The thinking here inevitably draws a negative value line and that line is an easy one for a company, or a team within it, to adopt.

What’s always interesting for me to consider is: what does any of this mean for the context I’m working in? This is what I try to engage test and development teams on. Where and to what extent does our testing have to shift? Does it at all? No doubt many people will have different thoughts about this, but it’s something worth thinking — and communicating! — about.

So … Technical or Not?

Well, I wrote up about the cross-discipline thing in Testers Should Be Cross-Discipline Associative. Do testers need to be “technical”? Yes, I would say absolutely they do. However, do they have to have a degree in computer science? No, I don’t think so. Should they be able to do coding challenges on the spot during an interview? For me, no.

What testers have to show is a technical aptitude across a wide array of languages, tool solutions, and technologies. I’m going to talk about this a bit more in a future post because I’ve noticed a somewhat interesting trend among interview techniques for “technical testers.”

More on that soon!