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.

Data Geek

I’m a big fan of gathering metrics about my own activities.

It allows me to look at trends and patterns about my own behavior either for self-improvement, or to simply understand more about the things I may have often taken for granted.

I’ve also found tracking my Testing activities and some of the metrics that go along with that incredibly valuable. I know at what time of the day I am most productive, what sort of music brings out the best Tester in me and some interesting data points suggesting I find twice as many bugs per Testing session when I work from home versus the office.

Freak! I hear you shout. Yep. Maybe.

I’ve “quantified” myself for many years now right from how much I spend each day to my fitness routine. (or lack of)

In the work place I don’t live by numbers, for example progress based on No. of Tests executed, or any other crazy metric some teams may be governed by.

But I do like to look for trends. Trends and patterns can show me interesting things. I want to know how many times a story or defect has been bounced back from Test, even more so for groups or clusters of stories over periods of time.

I want to know how long on average it takes to spin kits to out test environment over X number of days. I want to know on average how many kits are good versus how many are bad. This shows me useful data that can start further conversations with, nothing more than that.

With data points, trends and patterns I can start to look at underlying problems (or enablers) and do techniques like “The 5 Why’s” to get to the root cause. Single sets of numbers often don’t offer insights like this, they can be flukes, anomalies or unrepresentative. Numbers gathered over periods of time offer more credibility (although could still be invalid or incorrect).

So I thought I would share with you two of my favourite tools for tracking data.

  • Daytum
  • Your Flowing Data


Daytum has been around for quite a while now. I love Daytum because it lets you create almost any data combination structures you want and gives you a nice simple interface and some neat graphical displays to choose from.

I’ve been using Daytum for some time for personal stuff like expenses, items I spend money on, miles run, etc etc. For Testing I’ve experimented with data such as “Sessions completed”, “Bugs per session”, “Bugs per sprint”, “Most Bugs Per Music Genre” and all-sorts of other crazy data that might lead to more insights in to my Testing.

Your Flowing Data

Your Flowing Data (YFD) YFD is a new one for me but I’m really liking it.

It’s proving pretty awesome at capturing all types of data for me.

The killer feature for me is that I can do all of this from Twitter. I can send a DM to YFD from my Twitter account and it records that data for me. This is a neat little feature. You can still enter data via the web interface also.

The data can be graphed or exported for further manipulation which gives it a great level of flexibility. There are more graphs being added too as well as the ability to export your data out to a spreadsheet.

Want more?

There’s also Me-Trics, mycrocosm, grafitter and beeminder (more goals related)

If none of the above sound cool, then how about trusty excel, or a whiteboard with stickies on it?

For a data geek like me though, these tools allow me to shift my focus towards understanding people and behaviours, and how these different behaviours may interlink and relate to each other. From this data I can start to see patterns, stories and trends. And I really quite like that.

No Test Case, No Bug

A while ago I remember Phil Kirkham mentioning that he’d found a bug that “fell” outside of the Test Cases he’d been given and someone was arguing that it wasn’t a bug. I found it incredibly interesting that someone would dismiss a serious bug because it was not found as part of a test case.

The test case is an abstract, it’s something we create to guide us (mostly), yet too many people take the test case to be the testing. The testing is a human process. The test case is a guide, an artefact, a crutch, something we may *have* to create, a container of information, a checklist or any other supporting element to our testing. The test case itself…is not testing.

About a year or so ago I wrote a short eBook on the problems with Testing. I set the main Test Manager character in a company who valued process over actual results. That process over results was similar to what I believe Phil saw.

This was originally going to be a decent sized blog post about process and test case management. Instead I thought I’d spent 5 minutes hacking together an Xtra Normal video to see if I could get the point across with animated characters instead (I also wanted an excuse to have a go at an Xtra Normal vid). (BTW – The Evil Tester did an Xtra Normal video here : http://www.eviltester.com/index.php/2010/03/03/hey-you-are-you-a-tester-the-m…

My video is by no means an award winning video, but it was actually quicker than writing out my thoughts. I think it conveys a similar meaning.

I’ve always wanted to be a film director too. I’ve got a lot of work to do to make that a paying reality 🙂