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.

 

Testers Learning To Code

One of the topics that always pops up in conversation with Testers is whether or not we need to know how to code.

I think a lot of this depends on your context and your career goals and aims, but really it pays to at least understand how the code is hanging together and to get a sense of what it’s doing. It would undoubtedly be useful to code at a basic level to help build tools and programs to help you and also to crack Test Automation (i.e. not relying on Record and Playback as your strategy).

I often hear the excuse that there isn’t time to learn, but I don’t think this is true. I think we could all snaffle 10 minutes a day to work on some code. The time argument depends greatly on the importance you place on learning to code. There are lunch times and after work and weekends too.

One of the things we’ve got set up within our team is two 30 minute sessions each week where the whole test team sit together and work through coding katas with our tech tester and programmer. It works really well but still needs each Tester to spend a little extra time each week re-enforcing the learning.

I thought I would collate together some resources that might help and inspire you. Oh yeah, and deciding which language to learn is often the hardest decision. I can’t offer any guidance on that really, it’s what works best for your environment, your product, your goals and your interest in each language.

So here are a few resources I’m finding helpful:

So you want to learn programming basics?

There are loads of resources for learning basic programming (try a Google search for it) but the one that stands out from the crowd is Code Academy. It’s a great interactive tutorial teaching you the basics using JavaScript as it’s main language. The lessons are short and the guidance is awesome.

So you want to learn Python?

Python is a really powerful scripting language and you would be surprised at how many of your favourite sites are running on it on the web.

There are a number of great resources available on Python but one of my favourites is this very straight forward guide called “The Programming Historian“. The lessons are kept simple and you’ll be writing Python to manipulate files and text in no time.

If you’re in a .Net environment then IronPython might be the way to go.

So you want to learn C#?

There is a pretty good course here at Programmer’s Heaven on C# basics.

CSharp-station also has some good tutorials.

 

So you want to learn Java?

By far the most relevant and intuitive book on Java for Testing is Alan Richardson’sSelenium Simplified“. The guide is very straight forward and in no time you’ll have some tests running on your web site. It’s obviously aimed at getting you started with Selenium but Alan introduces you to Java as part of the journey.

Update – Alan has also now released Java For Testers. Head over to the site and check it out.

Here is an introduction to Object Orientated Programming in Java.

Learn Java Programming with Green Foot. This is a really great program for learning about Java and Object Orientated Programming. You get to build a world where Wombats eat leaves. Great fun.

So you want to learn Ruby?

I would recommend to you dive straight in to Brian Marick’s excellent book “everyday scripting with Ruby“. It’s partly aimed at Tester’s so it’s a great read.

Ruby for Kids is very cool also. Don’t be put off by the title. The lessons are great and the basics can be learned very quickly indeed.

 

Why’s Poignant’s Guide to Ruby is a cult classic in the Ruby domain. It’s a crazy story that introduces Ruby and general programming ideas. I actually enjoyed reading this. It’s a PDF –> http://www.rubyinside.com/media/poignant-guide.pdf

Ruby in Twenty Minutes offers snippets of learning. A good resource for getting started and getting it all installed etc.

If you’re in a .net environment but still want to use Ruby then check out IronRuby.

Each of these languages is typically coded in an IDE (Integrated Development Environment) although you could also use something low tech like Notepad. A good list of IDEs is here on Wikipedia.

There are also other languages I’ve not covered here like PERL, PHP, C++ and many others.

Any other sources I might have missed? Let me know in the comments.