Testers need to learn to code *. Period.
And here’s why.
The market demands it and the supply is arriving.
As a hiring manager I’ve personally seen a massive increase in the number of testers who can now code. They may not be able to write production grade feature code, or automated tests, but they can write scripts to help them test, or they can write a small app that will inject data or they can extend an Open Source tool to make it work for their needs.
They can basically dig deeper than what you see on the screen, do more with automation and do a more varied set of testing by using tools and code. I see this as a positive thing – I know some people may not.
There is also a growing number of developers who are moving in to a technical testing capacity and learning how to do good exploratory testing and test planning. The market is buoyant for testers who code (and who know how to sell themselves) and it’s good for hiring managers. It’s quite rare now for me to find a tester who isn’t coding, or at least really focused on learning it.
In a nutshell the market is now being supplied with these once elusive testers who can code.
You could of course replace “learn to code” with “learn to do security testing” or “learn to do performance testing” but the reality is that most of these niches also require coding or scripting experience. It’s rare to find a tool that pops out of a box and does what you want it to do – despite what many of the tool vendors sales people will tell you.
To ignore the shift in the market is to leave yourself at a disadvantage when trying to get a job.
Whether you believe that coding is essential to being a good tester or not will soon become an irrelevant moral viewpoint. Testers now need to remain relevant to those with jobs, and those people with jobs for offer are starting to get multi-skilled testers (or T-Shaped as I call them) applying.
Instead of investing energy in fighting the inevitable train of change it might be worth spending that time learning to script, or carving out a niche in another aspect of testing (security, usability, off-shoring, test management etc), or resigning yourself to being outpaced in job applications.
We should be careful though to discern from simply following trends such as certifications and following evolutions in how testing is done. One is very dangerous and leads to lazy recruiting and competitions like certification inflation – the other is a natural progression of our testing craft. Learning to code is deeper than a certification; it’s a skill that can open up many new doors and give you access to tests that were once impossible without some code. Of course you could rely on the developers in the team to help out and that models works well, but the market is shifting and to remain relevant in this market means your skills will need to shift also **.
It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code ***.
* Note – there are of course many roles within testing that mean coding or scripting is not essential such as management, strategy, coaching, leadership/directorship roles and problems solvers etc but for the mainstream testing roles the times are changing.
** Note – shifting skills could also mean learning specific tools, learning how to solve problems or, as the post suggests, learning how to code.
*** Note – of course – there are also lots of other ways to get hired rather than applying for a job – thought leadership and networking are two – I cover lots more in my book.