How Many Programming Languages Does a QA Programmer Need to Know?

Have you ever wondered if your routine tasks have become time-consuming? Perhaps finding the right tools for specific project tasks has become increasingly challenging? There is a practical solution for these problems—automation. Automation will help you eliminate week-long regressions, endless management reports in excel sheets, and the need to check bug after bug manually. However, to consider this topic more broadly, let’s not limit it just to QA automation.

In this article, you will find programming as one of the possible tools for a QA engineer. You will learn how to finally understand programming, where to use this knowledge later on as a tester, and how it will benefit you in your daily work.

If I’m a QA, why would I dive deep into programming?

Mastering any language will help you understand all the basic programming parts—variables, data types, loops, conditional statements, objects, etc. It’s a great entry point into test automation, and from there, it’s a short walk to advanced skills like reading developer code. Let’s say that it is relatively easy to localize almost any data validation error on the backend to the line. If this information is displayed in the bug report, the developer can fix it in just a few minutes. 

Once you understand the application code, you can test it like a “white box.” That is, immediately see what test cases are needed and how to write them as rationally as possible. In addition, understanding the software code allows you to investigate bugs found in the application much more deeply, thus helping developers reduce the time of the next fix.

Ok, but can only one language be enough?

It’s an excellent place to start. When you thoroughly learn and can use one programming language, you can and should take up almost any other language. Most programming languages are created according to the same molds. Basic concepts are the same everywhere, only syntax and minor points differ. In any language, variables remain variables, loops remain loops, and classes remain classes. And so, you understand that when you get into details, the low-level concepts of this or that language will be different. But for the average QA Automator,  these theses will be relevant.

In the context of automation, in today’s IT, you can safely say that almost any automation task can be solved with any of the common languages in which many frameworks and libraries are written. But in any case, some language has to come first. Among the most popular today are Java, Python, JS, C#, and of the least popular, Ruby and Groovy. Suppose you try to estimate their ability (the availability of tools in the language), popularity (which will directly affect the ease of finding answers to questions), and ease of use. In that case, it may come out about this graph:

The advice is simple: take whatever language you like and master the basics.

When might a QA need to know another programming language?

Whether you have enough knowledge of one language for a long time depends on the specific situation or the project you are working on. There may be particular tasks in your career path for which the tools and knowledge of one language are insufficient. I’ve divided these cases into three subcategories, which I’ll discuss next. You will most likely have to learn and use a new language during these times. Let’s briefly go through each of the cases.

Customer requirements

Customers often ask that automation in their projects be executed in a specific language. The reasons vary: from “All our teams use this framework for automation” to “I heard that this framework is the best, and it’s worth trying.” Of course, you can argue against the customer’s decisions, but that doesn’t always work. In reality, you’ll have to adapt to the customer’s circumstances.

Project specifics 

It sometimes happens that you enter a project, and some processes have long been set up and cannot be changed. For example, in addition to basic automation, the team is used to doing small automation tests in Postman for spot checks, and you can only write a JavaScript script in it. In that case, you just join the team and run at the same pace. Or maybe you’ve proven in an interview that you’re relatively quick to learn the necessary language or framework and join the automation the team now supports.

Another reason for choosing a new programming language may be that developers sometimes want to participate in testing automation to write tests or just read them. Then it is worth selecting the language in which software development is done, and everyone will be able to participate in everyday activities. Yes, it can be aggravating at first, but if you do it right, the help of developers will quickly pay for all the initial pain.

In addition, the project may use specific technologies that can not be tested in any language. For example, there is the MQTT data transfer protocol. For simplicity, you can call it an analog of HTTP, but with some reservations and use cases specific to IoT. If you need to write performance tests for MQTT, you do not need any performance tools. You have to take one of the popular ones with the necessary toolkit. For example, there is a library for Jmeter, albeit with limited functionality. Or you can use one of the tools which were created specifically for testing MQTT:

• MQTT stresser
• MQTT stress

Otherwise, you will be unable to perform the task assigned to you.

Special tasks

They are appreciated more as an opportunity to broaden a professional outlook and try something new in the short term. Such tasks are beneficial for development without going very far out of one’s working comfort zone. Suppose you need to read/correct test code written by other teams using a different set of technologies. Sometimes you need to be a trailblazer and learn a new tool to tell if it will be helpful for your project. In that case, success could mean introducing that tool to the whole team.

The main thing is to understand the basics of programming, and then any other languages will not be difficult to learn

Programming is a set of concepts. Once you have mastered them, it is not difficult to “pull” on that concept a specific implementation in the form of a programming language, library, or framework. It’s like learning to ride a bike—in the first five minutes, you’re awkwardly pushing yourself with your foot, trying to get sideways, and eventually, you start riding relatively briskly, trying to learn how to turn, brake, and avoid passersby. You know that feeling when you learn, and suddenly everything becomes apparent, and everything comes out? It’s like something clicks in your head.

The same thing can happen to your programming skills back. At first, you can have a lot of things that were not easy. It’s okay to not understand even half of what the teacher tell in the first year. But later, you should stop thinking about “how to ride a bicycle” and be able to master more complex designs and skills. Once tricky for me at first, the theory became orderly and understandable.

An engineering approach to automation problems is the key to solving any task. If you understand the basic concepts and are confident with at least one tool, you won’t have too much trouble mastering almost any similar tool. As you develop professionally, you’ll gain experience and be able to solve problems of varying complexity. In addition, there is always the ubiquitous Google and plenty of instructions on how and what to do.

If you are already learning to program but have made no visible progress, you may already be a few steps away from the same “click in your head.” Just don’t stop. Perseverance is what will make you a professional in the future.