Zee Spencer

Three Reasons For Testers Not To Learn To Code

Michael Bolton wrote an exceptional article listing three reasons for software testers to learn to write code. Here's three reasons why a tester shouldn't learn to code.

On one hand, this is incredibly important. After all, learning as much as we can about as many things as we can is a powerful career move.

Yet there are some decent reasons why a software tester shouldn't learn how to program. Bear in mind, I'm not saying we shouldn't learn to program. I'm merely stating there are repercussions to learning to code which can harm our awesomeness as a tester if we're not careful.

1. The More We Think Like A Computer, The Less We Think Like a Person.

Computers, eh? All those zero's and one's. All that reductionist logic. Absolutely zero innovation. As we learn to program, we discover to program well we have to think like a computer. As we think like a computer, we begin to focus on the happy path: "What is the one thing I need to do to verify this bit works." This focus blinds us to the less-happy path.

The more we learn to isolate, the harder it is to notice emergent issues. Reductionism is powerful. Experiment driven systems like the scientific method have reshaped our planet's surface and sent us to space.

But reductionism sucks when it comes to emergent properties. Bad. The best testers are the adept at seeing the whole. They notice that twiddling this feature here will impact the outcome of that feature there. Coding is reductionist in nature, which is why we developers often screw up integration.

2. Coding is Hard. Developers Are Good At It.

Do you know how to write maintainable, expressive, working code? No? Neither do I. And neither do most coders. But they're probably better at it than we are, for now. After a while we can be a code master, but until then we run the risk of creating automated checks that are less reliable than the code they're checking. This causes false positives and a high cost of ownership.

But hey! If we follow some basic principles, devote ourselves to learning, and remain pragmatic we may wind up being one of the best coders on the team. Then our vengeance will be complete on those developers who spurned our bug reports and laughed at our test plans! Oh yes... Vengeance...

3. The More Time We Spend Coding, The Less Time We Spend Testing.

Given the definition of checking and testing, test automation is often not testing, it's the verification of testing. I'm not advocating avoiding automating checks. That way lies madness. And bad software. And tears. I'm suggesting testers are highly skilled contextual evaluatores who evaluate and communicate risk and reward to decision makers more effectively than any automated check. Excellent testers prioritize that over learning the intricacies of a programming language.

Learning to code as a way to improve your ability to evaluate risk and check for errors more effectively is reasonable. Learning to code to convert test plans to automated tests may not be.

If you're a tester and you want to learn to code, consider checking out codeunion.io. We provide customized training to supercharge your technical career path, no matter what your current skill level.

Browse posts about:

Want to get notified when I publish new articles or update old ones? Subscribe to my newsletter. It's a weekly-ish set of interesting links with a short essay on programming, design, technical leadership, or anything else that strikes my fancy.

Not sure? Read the archive.