A question testers and management often ask is ‘Should testers be able to code?’, I’ve read more answers and opinions on this topic than almost any other in the testing arena, so I thought I’d add another one that nobody asked for.

One argument against testers coding seems to be this perceived ‘lack of autonomy’ that will allegedly develop if testers so much as sniff a piece of code. Codswallop! Indeed, this appears to be a misrepresentation of the old ISTQB mantra that ‘a certain degree of independence often makes the tester more effective at finding defects and failures’, hardly convincing. Anyone espousing this as a reason for testers not to learn to code is missing the point, the argument seems to me more to do with an autonomy of objectives and goals than skills.

I write automated tests for a living, so I’ve got to code, there’s no two ways about it: if I couldn’t write some code I’d be out of a job. I’m not for a minute saying that I write code to the same level as our top developers, but I like to think I do a pretty good job of it. Has it compromised my ability to test independently? No. I still design and implement test cases, I still have a vested interest in providing as much information as possible to stakeholders on the current risk of shipping their product (because to me, that’s the job of a tester), that hasn’t changed and if testers don’t lose sight of that then there’s no reason why they can’t learn to code.

That said, if a manual tester came to me and said ‘I’ve never written a piece of code in my life, what should I learn?’ my answer would be very different than if someone interested in development asked me. I believe we’re asking the wrong question when we ask if a tester should learn to code, we should be asking ‘What should a tester learn to code?’ and the answer to that, in my opinion is almost always ‘scripts’.

If you learn via one of the myriad online courses out there, you’ll learn to build a website from scratch with some nice JS framework or you’ll start with a tool that takes some user input and performs a calculation on it – useful, but probably not that useful for a tester. This is one of the mistakes I made early on, I was so preoccupied with learning to code, that I didn’t stop to think how relevant it was, and every time I started, I stopped within days or weeks because I never benefitted from the knowledge.

Instead, I’d recommend learning a language first that allows us to interact with files, data, applications and/or operating systems and that’s gonna either be SQL or Bash (I’m assuming here, insert other shell where appropriate), then moving onto a more advanced scripting language like Python.

As a manual turned automation tester, my first steps into coding went something like this:

Basic SQL queries to interrogate and verify data. Small shell script to automate deployments of the application – Bash/Jenkins. Script to repetitively exercise API endpoints and generate data – Python

All three of the above were relatively simple to learn, didn’t require an in-depth (or any) knowledge of Object Oriented principles, and provided an invaluable foundation upon which to build my automation skills. From there, I bought a few books and developed my knowledge of more advanced topics (OOP, automation models etc.), and that’s how I got started in automation. I’m not for once saying that all or even most testers should move towards automation, manual testing still has its place, but if you don’t have some coding knowledge I think you’ll fall behind the crowd. Instead of going online and straight into the courses on there, I’d recommend looking at the following books, I guarantee you’ll find at least something useful in your day job…