Testers and Coding

Aug 12, 2020 | Programming, Test Automation Insights

Chart with a red x for wrong software testing metrics

For at least the last 10 years there has been one persistent question which comes back on a regular basis: Must testers learn to code?

The debate has swirled around from very loosely defined collections of ideas to very precise considerations. As time has progressed and various ideas and models have been tried and tested, many have come down firmly on the fence about this.

My own thoughts have grown and developed. The last several months have helped solidify my thinking more clearly than it was before.

Some software shops have a distinct “automate a bunch of stuff” culture. They have “manual testers” who do the grunt work of writing test plans and scripts, then executing them with little or no assistance from technology. These get handed to an “automation team” which turns these manual scripts into “automated tests.” The “automation team” is often considered “better” than the “testers.” Even though it was the testers who figured out what needed to be tested and how.

Automation teams tend to be paid better than testers, but often not as well as the developers. They are often considered more skilled than those who are “just testers.” While this was almost universal a few years ago, it is still common now. It is easy to see why “learning to code” is considered “essential” for testers.

I have developed a series of responses when asked about this. My basic response is to ask a series of questions. People think I am doing something Socratic or setting a trap to show the fallacy in their argument.

I do not care for that when people play that game with me. I do not play it with others. When I ask questions, it is to better understand the situation you are in. Most people who assert one thing or another as absolutes tend to do so without considering the situation other people are in. They also rarely consider the possibility of a situation where the “absolute” fails.

Code basics

“Learning to Code” comes in many forms. When people say “testers must learn to code” it is worth asking what is meant by that. If the team uses Java, JavaScript, C, C#, or any common development language, it might be worthwhile to learn something about the language the team writes in.

It seems reasonable to expect testers are at least conversant with the terms being used by the people you work with. We prefer, if not expect, developers and BAs and PMs to use terms in the way we use them. We want them to not assign definitions to things at random which make us cringe.

A basic understanding of what “assert” or “class” means is a reasonable thing to expect. It helps testers appreciate the complexities and not simply bemoan how “bugs take so long to fix.” Given that, as testers are expected to help with code, either reviews of production or test code, does it not make sense to at least learn the fundamentals?

If an organization is open to pairing, the need for testers to become anything other than “almost dangerous” in writing or understanding code decreases dramatically. Even that minimal knowledge might help you do a better job of testing.

All-in-one Test Automation

Cross-Technology | Cross-Device | Cross-Platform

More than code basics

Understanding the basic concepts of writing code is important. Another powerful tool for doing better work as a tester is to learn as much as possible about the database system under the software app or product.

Learning the fundamentals here is important as well. For example, learning to write basic queries is a huge step forward. If a tester can identify and retrieve information directly from the database, she can more reliably predict results from specific tests. She can call out behavior in the software with a better understanding of what is going on in the system. Most importantly, she can work with the developers to track behavior and find issues that might be otherwise missed.

It may be that the language which fits your needs best is not the same language used by the developers you work with. It is possible to learn a language that drives testing in a framework dedicated to testing and is not used by a software customer.

Code and tools

By learning tools to help your testing, you can broaden your skills and possibly strengthen your testing approach. The split between “manual tester” and “automation tester” seems a false one when the main difference is generally the tools available for use.

If your team or company has test tools available, learn to use them. Even if the company is not willing to pay for your training, there are often low-cost (or free!) online courses you can take to learn the basics. When you have the basics, ask about using them to help your testing. This might be the catalyst to bigger things in the organization. It might be the very thing needed to get you noticed in a good way. By learning to use tools appropriately that assist your testing, you can use the testing skills you already have in a more meaningful way.

Not every tool is appropriate for all situations or problems. If the tools used at your organization do not help your testing or are not intended for the type(s) of testing you need to do, talk with managers about the tools and what others might be available.

Look to see if there are tools better suited for the tasks you need to do. Anything that helps make testing more efficient and effective improves and aids the delivery of software of improved quality might be worth considering. For you, the tester, learning tools to improve your testing can improve the work you are doing, and help you work better all the way around.

Should testers write production code?

We have looked at understanding code and basic programming concepts. We have considered testers writing queries to support their own testing. We have looked at writing code specifically for testing and understanding and applying tools appropriately for testing.

There is one great question that comes regularly: Should testers write production code?

A growing number of organizations have been requiring “testers” to double as “developers.” Some have simply eliminated the position of tester or testing specialist and made everyone a developer. The challenge of course, is that if organizations do not value the skills needed to do good testing, what will be the result of this? What will be the impact to the customer if there are no people in the role of tester or testing specialist?

Of course, years ago developers were expected to test their own code as well as the code written by other developers. Some were better than others at this. However, the skills needed to do good testing have not been emphasized in many “code writing” courses. Most “code academies” and even collegiate and university programs are not presenting a robust level of instruction in what goes into good testing. While some touch on it, many do not even do that.

Meanwhile, most testers have worked years to develop very specific skills. These are different skills than those that developers have honed. Both sets of skills are needed. However, neither group, as a rule, have been taught both sets of skills in depth.

This does not mean developers cannot hone testing skills, or testers cannot hone development skills. To get to the point where testers are capable of writing production, customer-facing code to the extent they can do good, meaningful testing, is a task of years. Likewise, developers learning and mastering testing skills to the same extent they have mastered programming is also a task of years.

Is this an investment that makes sense? Some organizations, large ones at that, certainly seem to think it is. Others have simply made all their testers redundant (fired them) unless they had some in-demand skills.

Is this the best choice? To me, people who understand the basics of developing software and writing code, who have strong skills in testing have great value. People who understand the basics of good solid testing and have strong skills in all aspects of programming also have great value.

To answer the original question: Must testers learn to code? The answer I would give is this: learning to code can help testers become better as testers and contribute to the success of their organization. When they can contribute by writing some customer-facing code, that makes sense as well.

Yes. Testers learning to code is a good thing for them and for their organizations

Solve Your Testing Challenges
Test management tool for QA & development

Related Posts:

5 Software Quality Metrics That Matter

5 Software Quality Metrics That Matter

Which software quality metrics matter most? That’s the question we all need to ask. If your company is dedicated to developing high-quality software, then you need a definition for what “high-quality” actually looks like. This means understanding different aspects of...

The Ins and Outs of Pairwise Testing

The Ins and Outs of Pairwise Testing

Software testing typically involves taking user requirements and stories to create test cases that provide a desired level of coverage. Many of these tests contain a certain level of redundancy. Traditional testing methods can lead to a lot of wasted time and extend...