Is it necessary for testers to learn coding and programming?

Another question, that I generated by asking ChatGPT for a list of controversial questions for Testers:

“Is it necessary for testers to learn coding and programming? How much technical expertise should testers possess?”

I think while there are great benefits to learning coding and programming as a tester, it isn’t a necessity for all testers to be programmers.

Testers bring a different, complementary skill set. And while Tester and Developer skills can naturally overlap, Testers bring a huge amount of value to the table in the non-coding work they do.

I also think it’s important not to conflate technical expertise with ability to write code. Modeling, analysing, thinking critically and other classic Tester skills can be very technical and valuable.

I do expect that Software Testers who progress in their career to want to learn over time to understand software and how it is built. And I would recommend anyone working in software testing to learn to read code if they cannot do so already.


I personally liked ChatGPT’s answer also:

While coding and programming skills are not strictly necessary for all testers, having a certain level of technical expertise can be beneficial in many testing scenarios. The specific technical skills and knowledge required for testers can vary depending on the nature of the software being tested, the testing methodologies employed, and the organization’s requirements. Here are a few points to consider:

  1. Testers who possess coding skills can contribute more effectively in certain areas such as test automation, where writing code/scripts to automate test cases can significantly enhance productivity and efficiency.
  2. Testers with programming knowledge can better understand the underlying codebase, identify potential issues, and collaborate more effectively with developers in troubleshooting and providing valuable feedback.
  3. Familiarity with programming concepts enables testers to create complex test scenarios, simulate specific conditions, and perform specialized testing, such as security testing, performance testing, or API testing.
  4. Understanding programming languages and frameworks allows testers to interpret error messages, investigate logs, and diagnose issues more accurately, which can expedite bug reporting and resolution.
  5. Knowledge of scripting languages can help testers in tasks like data generation, test data setup, and test environment configuration.
  6. Testers who can read and interpret code can proactively identify potential areas of risk or vulnerability, ensuring thorough test coverage and reducing the likelihood of critical defects slipping through.

However, it’s important to note that not all testing roles require deep programming expertise. Testers can excel with a combination of domain knowledge, critical thinking, analytical skills, and a solid understanding of testing principles and methodologies. The level of technical expertise required will depend on the specific job requirements, the complexity of the software being tested, and the organization’s expectations.

Ultimately, organizations should assess their testing needs, project requirements, and team composition to determine the appropriate level of technical expertise for their testers. Providing training and opportunities for testers to acquire relevant technical skills can be beneficial in improving their effectiveness and expanding their contribution to the software development lifecycle.

For my own opinion: I actually prefer to hire non-technical people who are willing to learn how to code. They often know how to test and then can put their way of thinking into test automation. Compared to people who start in test automation directly and only want to code, they often fail all creativity and testing technique tests (in interviews).

But I do agree a bit of technical knowledge can’t hurt. I’m not saying they need to dive into code 24/7. But the basic concepts is nice, also a bit of knowledge of CI/CD and how to setup a pipeline through scripting etc.


I like to code when I have time because it allows me to remain focused in times when I do not do automation at my job. Also there more I know about a certain language or tech stack the more I know how and what to test if the project uses it.


As someone who is a full time automator, I say:
I’m totally impressed by the junior tester on our team, she is almost certainly as good or better at testing than any of the senior testers here (And we’re all REALLY good in my opinion).

She has only just begun to learn SQL queries, and knows nothing about devops, pipelines, automated tests, etc.

What she does know is the product and how to (ab)use it. She knows what the customers will ask about and what is confusing to them (We “stole” her from support). She has amazing critical thinking skills, and is not afraid to ask questions.


Absolutely not if you mean writing code. If you mean understanding or being able to read and follow code to understand it’s purpose then I’d reply, it can be really useful and helpful. I put a lot of effort into understanding code or reading code as I phrase it. It has helped me give actionable insights to devs. Raised my pairing with devs to a higher level as I was able to discuss the logic and order things were happening and extrapolate what that might mean to the user flows and experience.
Technical knowledge, rather than expertise, I would say is important to understand where things fit and how things work. That opens up other areas of investigation and tests.

So writing code and being a technical expert no.
Understanding code and technology yes.


I don’t thinks its necessary to learn how to code but I think it is essential to at least be able to read code. Now that collaboration seems more prominent, being able to discuss the actual code with say a developer will enable you as a tester to understand a feature in more detail from an implementation perspective which will in turn help your testing efforts. It will also enable you to review pull requests so you can potentially capture issues before they go into the main branch.

Also if you can code then thats great, you may pick up a small change that adds value to the customer - and therefore helping to improve quality.

One thing I have observed with coding is that there is coding and there is “coding”. What I mean by this is that coding is things like loops, variables and inheritance - the kind of things you see on various courses on programming. “Coding” on the other is things like code architecture, Inversion of control, Factories and other such things that are a step on from coding.


We have found that it’s helpful to have a more technical and a less technical person on the test team. Understanding the code can give you new ideas on how to test. But it can also give you the impression that other components won’t be affected by a change you otherwise would have tested. As developers already bring the technical perspective the other one is really important. We found quite a few bugs even though they swore there would be no side effect on other components.

So I would say that testers don’t need to learn how to actually write code or fully understand code written by others. Understanding descriptions by developers of their change on a higher level is important. If a change to the date calculation routine is mentioned because of a bug, you need to pick up that this means date calculation is impacted in all dialogs.

1 Like

I’ve really benefited from this - having a highly technical tester and a non-techical tester. The technical tester get’s those deep, specific edge cases that can show up (like overflows, calculation edges, etc). And the non-technical tester acts more like a user and checks more of the “normal and sometimes weird” things that users can get up to.

Both are super helpful IMHO.


Whilst you can get by without, it is something that I would recommend. That isn’t necessarily writing automated tests or being able to read & understand the code (both very useful skills), but just being able to write a script in python, VBScript, Perl, C# or whatever for test data generation, load testing or making it easier to set up a test environment.

I think my greatest benefit of knowing how to code as a tester is that I also know how to screw up when writing code. I think that is a valuable bit of knowledge.

1 Like

I like this reply. I wish someone would tell the market that non-technical/coding testers have value. Adverts for 90% of the testing roles out there are just a list of languages and frameworks almost nothing to do with the process of testing itself.

I can see the benefits of coding for SDETs but I actually think testers need to act as the user so there isn’t really a need to know how the software is working just that it is working.

1 Like

Just to be deliberately awkward for discussion, non-technical?

I’ve worked with someone who would use wireshark to analyse network traffic, was great at load testing and was often reprogramming devices over SSH. But he once referred to himself as non-technical. Drove me nuts.


Totally fine with awkwardness :slight_smile:

By non-technical, I’m thinking of testers who never lift the lid to look behind the scenes of an app. At one place I worked, we’d hire school teachers for the summer to help us test things.

Yeah, I’d agree that your SSH friend was probably a little more technical than he was willing to admit :laughing:


I’ll hijack this for a follow-up question.
I see a trend of jobs where the software tester is required to be:

  • expert, proficient, fluent with a specific programming language either of the product, or the automation; sometimes it’s two different ones, or three if they want the tester to also look into database apps, monitoring, performance, or others.
  • oop
  • algorithms.
    This is because they see testing from the developer’s perspective(analytical software testing school of thought).
    The skill of less focus is testing, where they consider that almost anyone could pick up a set of specs, some code, and tools and ‘validate’ them.

Are developers picking most of those jobs?
Are professional testers going often in that direction of deep programming knowledge?
How would one be able to function as both a tester and developer at the same time? How do you switch the job to another programming environment(take another 6-18 months to get deep practice and expertise in the new stack)?


I can’t speak for all the open roles, but in my limited experience:

  1. Often, people hiring for these positions are not professional testers, so they only understand the development part of the role
  2. It’s sometimes what they are asking for, but not actually what the team needs
  3. There are genuinely some software testing professionals who are highly skilled in many programming languages, and also in testing
  4. Some of the people in these development-heavy testing roles have previously, or will in the future work as Developers.
  5. Plenty companies are loosing out on very talented testing professionals ,because they are being put off by such job listings focused on programming language and not quality and testing skills or experience

Amen indeed to point 5


My take is probably both simple, simplistic, and has a certain underlying complexity.

It’s not necessary for testers to learn coding and programming, but it can help to improve understanding of how the software in test works. I’ve worked with excellent testers who had no coding ability beyond some basic SQL skills, and mediocre testers who could code - and vice versa.

In my view the skills that bring most value to a testing role aren’t the coding skills but the ability to analyze a new piece of software and determine how it is likely to be used, where the likely points of failure might be, where and how the new software could interact with and cause problems with other modules, and so on. That’s usually a combination of product knowledge, domain knowledge, and user knowledge.

Coding helps to be able to build and maintain automated regression suites and to design ways to get at some of the less accessible parts of a system. It usually doesn’t do much to explore the system in the first place or to get a feel for where the fragile parts are (and there will always be fragile parts. If you’re lucky, they’ll be concentrated in the less trafficked part of the system, making them less obvious to users).

This might be news to recruiters and interviewers, but coding is very much a nice to have for most testing roles - especially in well-designed modern software that can have developers writing most of the unit and API testing and not need a lot of UI-focused automation.

And, for the record, I’m a capable coder, probably at an intermediate level. I also enjoy writing automation - but I recognize that it’s not the be-all and end-all of testing and quality.


This thread seems to restart on every platform related to testing. In all but the bigger software companies of 200+ engineers, everyone needs to know a tiny bit of everything. Because relying blindly on someone to never make a mistake setting up your internal web app testing environment is a mythical place. Quite often the app build itself can be buggy. If one of the VM’s hosting a web service will run low on space sometimes, and ends up only impacting one of your test cases, you need to be able to detect it correctly and either fix it yourself if you are a lone tester, or know how to ask for specific help. Certificates expiring? How often dos that happen to you? These are all critical bits of technical troubleshooting you need to know how to do so as to not raise product defects when it’s a process defect. Differences in how the app deploys in each environment and how to work out version numbers for things for example or even understand exactly what it means when a developer says their code is on branch X. How on earth do you test for example a web app if you don’t know which branch you just tested…unless you only have one test track and only have one feature or one product?

None of these require coding skills, but all require ability to “read” code and understand how it is structured and deploys. So when the tester sits in a meeting and a developer says they fixed a CVE caused by an outdated dependency in their Flutter code, the tester needs to get a good handle on what the impact is going to be and not keep asking, “so what feature will that change impact now?” It’s like using one of those old map scrolls, you wont’ see the detail, if you often don’t “see” the entire picture in your mind.


Some examples of what I’ve encountered while job hunting:

  • Ready to be tested on algorithms;
  • A technical interview with one of our developers will be done in order to assess your programming skills in X;
  • An online technical assessment;
  • Proficiency in programming C/C++;
  • Code challenge / code challenge review;

Sometimes it doesn’t matter what we as testers think about it.


I’ve failed one of these online assessments, and gone on to write excellent automation for other companies… so Company XYZ missed out on my mad skills, more fool them.

It’s frustrating when the generalized programming skills test has nothing to do with the job, e.g it’s about implementing random algorithms in a short time, not about say building automation or testing things.

1 Like

Sadly, true.

This one, I’d fail. I’m not big on algorithms - my skill set is much more towards figuring out how to do what I need to do when I need to do it. Funnily enough my managers appreciate that a lot more than knowing specific algorithms.

I guess I’m lucky I’ve mostly worked in small companies (at least until the small companies got bought by something bigger). They tend to be more willing to take someone who’s more of a generalist.