Why testers really should learn to code

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.

 

27 Replies to “Why testers really should learn to code”

    1. Thanks Frank – I’m not getting a totally overwhelming positive response which clearly shows that it’s a topic of great interest and passion.

      Thanks for commenting.
      Rob

      1. I was working as lead tester in one project for about 5 years. We hired only testers who could code or pick up the perk Really Fast.. In the end, dev team of 150 had support of 15 testers during the whole project within our team. Coverage and bug count within the whole project was really good.

        During that time and since then ive sworn not to go with people who vant code.. And ive noticed the same, feedback is not very positive.

        1. Hi Jani,

          Interesting story – I hear of many stories similar to this. I think it upsets many people to think that it is possible – it’s certainly not the norm, but tester who code being part of a dev team is increasingly becoming more common.

          Thanks for the comments.

          Rob

  1. I think, to an extent, there’s a vicious circle at play for many people.

    “I can’t code.” > “My current job doesn’t require me to code.” > “My current employer won’t let me learn to code because they don’t think it’s relevant.” > “I still can’t code.”

    There are a number of ways to break this cycle, any of which will improve your career chances:

    (a) As per the thrust of this post: Recognise that regardless of what your current job spec may say, having coding skills can give you an extra edge in your current role. Even if you’re not involved in an automation project, being able to programmatically create/submit large volumes of custom data can remove a lot of your manual legwork.

    (b) Recognise that an employer who denies opportunities for skills development and career advancement may not be the employer for you.

    (c) Recognise that even if you don’t have any spare time in your “9-to-5” job, there are 24 hours in a day, and you don’t need it all for sleeping and eating! I’ve lost track of how many times I’ve heard interview candidates tell me that they wanted to learn XYZ but they “didn’t have time”. (Hint to future candidates: a better answer is “recently my free time has been spent learning ABC” is a better answer!) Make yourself some time – set aside an achievable amount of time and put it in your diary (e.g. “I will spend 2 hours every Sunday afternoon learning about Selenium WebDriver”).

    Learning doesn’t have to be a lonely process either. There are a growing number of high-quality MOOCs (Massively-Open Online Courses) where like-minded people follow a weekly syllabus, submit coursework online, and converse in dedicated forums. I’d recommend Coursera and Codecademy as good starting points.

    1. Neil – great points and thanks for sharing these as comments on this post. Spot on.

  2. I’ve had testers who can code but can’t test. They call themselves testers, since they can’t code well enough to excel in developer positions.

    When I code, I hate the idea that I code in testing for the idea of knowing “just enough to inject data”. When I code, I want to code as well as the others. It’s not a mystery. It’s just learning. But it’s a choice of learning I feel ready having spent almost 20 years in testing. Learning more of that earlier would have been away from something else I chose to learn about how businesses and products work and where and how problems can be found.

    There’s also a shift in the market requiring developers to test. I find many get interested, but only some excel. It’s great that we see developers willing to spend three days on RST course and try out stuff they learn from there in practice, combined with good programming skills. Some of them actually see problems. I’m just not lucky with that in my current project, its a work in progress.

    1. Hi Maaret,

      Thanks for the comments. It’s entirely true that some people who can code can’t test. And you’re absolutely right to point out that it’s a choice of learning and learning one thing takes your time away from another; but the trend I’m seeing right now in the industry is for hiring testers who can script or code, whether a little or a lot. And yep – there are indeed many developers who are interested in learning about testing – that’s great.

      Thanks for taking the time to share your thoughts.

      Rob

  3. I agree that testers should at least have “technical awareness” as Janet and I call it. They need to know enough about system architecture, coding, the frameworks and IDE in use by their team so that they can communicate with coders. And they need to help coders learn enough about testing to make that communication two-way. :->

    That said – at least here in Denver, Colorado, it is extremely difficult to find any testers who know how to code. So I can’t say that the competition is very stiff. Testers who can’t code can still easily get a job here.

    I think in part that is because some people call themselves testers, when what they do is execute manual test scripts, and they have no desire to grow beyond that. So, I think we need to raise the bar for ourselves.

    I’m going to be refreshing my coding skills over the rest of the year, working through books such as Cucumber and Cheese by Cheezy Morgan, pairing on Ruby koans, and maybe going to one of the local user groups for women who code. I encourage everyone to do the same.
    — Lisa

    1. Hi Lisa,

      Thanks for the comments.

      We do absolutely need to raise the bar and here in the UK a tester who cannot code will still get a job – but it will, like you say, be a testing job that is simply running test scripts.
      The problem is that anything above and beyond simply running a test case is starting to require some form of technical awareness.

      I like the sound of those books – time to add them to our test team reading list maybe 🙂

      Rob

  4. Great post! I am, proudly, among those developers who moved to testing in a technical capacity. I have learned more about testing, more about coding, and more about myself since becoming a Tester. It is a very rewarding career and I see so much potential to assist testing groups helping them deliver solid information through their testing.

    1. Hi Joe,

      Thanks – glad you liked the post. Sounds like you’re enjoying your transition in to a test/dev role. It’s always nice to hear of people who are enjoying their role 🙂

      Thanks for the comments.
      Rob

  5. While I do think a tester should know at least one programming language (for many different reasons),
    I do feel that for time being – there is an artificial inflation in the demands for Coding Testers in the job posts.
    Many ask for coding abilities, while knowing there is a very slight chance the tester would actually be requested to code.
    This leaves out many talented testers who could have been much better for that position, and costs more money to the firm (In Salary and in longer recruiting process).
    I do like Neil comment – its up to every one of us to learn how to code.
    (Though without real practice theoretical learning is very limited)

    @halperinko – Kobi Halperin

  6. Rob,

    Interest post and comments all around. I guess I’m a bit of an oddball in the testing world because I came in knowing how to program (code). I started off my career as a Fortran 77 programmer and then went into C on the PC. But as part of the job programming in C I was doing a lot of debugging and testing work. I did this as a contract to a roommates company. A few months later they hired me fulltime and had me help start the Testing group. I found it was a particular niche I was good at.

    Needless to say as part of that initial experience I was both learning how to do Testing and Software Construction as part of the development work. I even got an early introduction to “Test Automation”, which later on I saw as another niche to work with. When the Windows explosion happened I got heavily involved in automation and combined my skills as a tester and programmer. Been doing it ever since, and it has kept me busy.

    As part of that experience I saw a division of ‘testers’ in the industry, basically two main classes of testers. First, the business oriented one. They focus on the business functionality of the SUT, make sure it works as expected by the users and the requirements. They don’t concern themselves with ‘code’, but more on the end result of it. They see the whole of the system, and don’t focus too much on the parts. It isn’t a technical oriented view .
    The second one is a technical oriented type of person. They are concerned about the ‘code’ working right and being built correctly. They worry about the different pieces of the system (UI, Business Logic, Database, etc.) and how they come together. They make sure all the mechanics work along with making sure it all fits the requirements set forth. They look at how the software reacts to different configurations of system and hardware. This is a more technical oriented view.
    So because of my programming background I can create code for various purposes, and it has give me some advantages in my career. But I know purely business oriented test people who are highly effective testers and come up with some of the best scenarios.
    From all of this I have seen a couple of key things. First, other people outside of testing (and some within) don’t ‘get’ what Testing is and what needs to be done for it. They don’t fully understand the purpose, methods, and benefits of software testing. Second, we as a profession do a crappy job of explaining ourselves and how we help to make a product and how to make it better.
    This increased demand for coding skills/knowledge (programming) for testers is part of the “next best shiny new toy” syndrome that agile has helped to create. It is a pendulum swing to a side, and will eventually level out again. And this isn’t a bad thing, just that expectations need to be reset and levelset too with the ‘other’ people involved in software.
    That’s my take on things.

    1. Hi Jim,

      Thanks for commenting. Some great points.

      I absolutely do see the value in very talented testers who can come up with loads of great scenarios and who maybe don’t code, but I’ve seen on the market a growing number of testers who can provide this business analysis (or appear to), and can code. It makes it hard to convince a hiring manager to hire the non-coder over the coder even when they don’t really fully understand what problem the coding may solve 🙂

      I do think there is something shiny about it but it feels like we’re now starting to see testers who can code hitting the market – something I never saw in significant numbers before.

      Thanks again for your comments – always good to read.

      Thanks
      Rob

    1. Hi,

      That’s pretty hard to say really – a lot depends on what you’re trying to do and what context you find yourself working in. Python, Ruby and Perl seem to be good choices right now but that’s all very subjective.

      Thanks
      Rob

  7. I’ve been observing this “code or not code” controversy in the testing community with amazement. I’m having trouble understanding why any tester would *not* want to learn to code. I’m a test manager, consultant and strategist, and I haven’t done serious hands-on testing in many years. But when I was a tester I knew how to code — and I worked at learning every language I need to know to understand and at least read the code for all the applications I was working with.

    Beyond the hiring considerations, there are many reasons why I think it’s important for a tester to know how to code.

    As coding advocates keep saying, you don’t have to be able to turn out production-level code. But it’s enormously helpful for a tester to understand how a system is constructed from the inside out. When you’ve tried to write working code, you learn to know the kinds of mistakes it’s easy to make with a given language. Not only does that help you find bugs in other people’s code, it helps you understand your programmer team mates and it teaches you empathy and respect for their skills. (You want programmers to empathise with you and respect your skills, don’t you?)

    When you can code, you can write routines to inject data. You can write routines that help you test faster, or make it possible for you to test a larger number of input variations than you could ever manage otherwise. You can write and run your own batch jobs. You can query a database directly, to find out what’s really getting written to it. (SQL is code, too.) You can make clever use of spreadsheets to boost your test capabilities.

    There are so many things a tester can do with code. And coding is FUN, folks! In fact, executing working code that you’ve written yourself is a blast! It’s almost as much fun as testing.

    1. Hi Fiona – thanks for the excellent comment. I think that’s my struggle too – understanding why a tester would not want to code. I guess it comes down to fear and of being pushed out of a comfort zone. All of the reasons you list are great reasons why learning to code is good and yes – SQL is code in my mind too.

      The empathy angle is one I’d never considered! – Thanks.

      Thanks again
      Rob

  8. I scrolled down to add a comment, and then found that Fiona had added just about everything I wanted to say.

    Being able to code – slowly, sometimes quite badly – has helped my testing enormously. Learning one programming language translates into understanding how code is structured, a skill which can be ported into programming languages that are new to you, meaning you can design better tests, following functions and routines to investigate where errors might be lurking. I can talk technically to developers to find out where there might be issues, and (it might just be a perception!) I feel that I get just that little bit more respect from the developers just for understanding what they are doing at a code level and being able to talk their language.

    1. Hi Shane,

      Thanks for commenting. I do think the respect thing is really important – of course, some devs do respect people who cannot code also – but being able to sit down and talk through what is being built can add a lot to a relationship between devs and tests.

      Thank again for commenting.

      Rob

  9. Hello,

    I’m somewhat new to the development world (I got a QA position and held it at one company for 4 years with no background schooling on the subject matter) and upon my attempt to branch out I’ve noticed that a lot of employers are looking for QAs that know code. Unfortunately in the position I had Automation wasn’t really a serious topic of conversation and therefore the notion of learning code was unknown to me. Now I did get into the SQL side of things for back end testing but as I have started to search for the best classes / sites / courses to learn to code I’m finding fairly difficult to find something tailored for QAs.

    Would you have any suggestions of places to start that you would offer to your employees?

    1. Hi,

      Welcome to the industry. Great to have new people in it.

      The best place to start would be “Ruby for testers” book by Brian Marick – good book with a testing focus.
      Alan Richardson also has a lot of good resources for testers learning to code – http://www.eviltester.com/

      Hope these help.

      Thanks
      Rob

Comments are closed.