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.
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:
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.
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.
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.
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.
Knowledge of scripting languages can help testers in tasks like data generation, test data setup, and test environment configuration.
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.