Should Testers know how to code?

I was actively involved in recruitment of testers for in 2012 and came across an age old discussion once again which made me write about this topic. Should Testers know how to code?

Adding to this, there was also a statement made by Adam Goucher at CAST2012..

This is the last generation of testers that don’t know how to code

In my opinion, it totally depends on the situation. For example, in companies like Microsoft and Google, virtually all testers must know some form of coding. There are still companies out there which only require manual testers. If coding know how was not a requirement, I would also prefer to hire a tester who has critical thinking, analytical, investigative skills, good communication, understanding of risk and knowledge of common areas where bugs tend to hide as compared to someone who can just write C#.

 I also agree with Cem Kraner’s view below:

Testing within a business involves at least two types of knowledge: knowledge about testing and knowledge about the type of application under test. Much of the PR about the need for “software development engineers in test” has come from software companies. For them, software is the subject matter. For them, expecting someone to understand code is like a bank expecting someone to understand financial statements. It is unfortunate that the software publishers and software service providers have been speaking with a louder megaphone than the other industries: the result has been that some non-software companies are changing recruiting standards to look for people with stronger software knowledge instead of stronger industry (e.g. banking) knowledge.

Vacancies for “Developers in Test” or “QA Developers” are coming out more and more, especially in Agile environments. We need to remember, automation testing can never replace the need to do manual testing. There has to be a balance between the two. Skilled testers are adaptable people and should not be threatened by test automation. It’s a valuable skill to have and it’s not like learning how to code will make you forget manual testing. Secondly, the more the tester knows about coding, they’ll be able to do their jobs better, and the more career opportunities they will have (more on this later – I have some stats to prove this). Additionally, talking to developers in a language they can understand, writing clear bug reports which put your message across correctly and quickly has to be a good thing, right?

As a recruiter, you also need to use a common sense approach. I have seen companies that seem to use a standard list of demands, that they once created, and keep on using because they have been told it is a good list by the consultant they hired to create it, or they see other companies ask for the same skills, so they assume they are vital. You should look at the job spec, the role of a tester in your organisation and your team structure. What does a tester’s role involve, instead of what others testers in your company do/can do. Sometime you may find that the ability to write code is desirable instead of a requirement. If it is a requirement, state the level of familiarity with coding that you require. This way you will avoid putting off good candidates who will just be overwhelmed by the long list of requirements. Here at the Trainline, I have amended our requirements in job specs to be inline with the role of a QA Developer.

Lastly, what all programming skills should a tester have? This totally depends upon the job requirement and differs from one company to the other. Some positions are for automated testers and for this you require a good set of programming skills to create test frameworks. A recommendation for a manual tester or a tester thinking of improving their programming skills would be to:

  • Learn enough in any language (look at your target market or see research below) so you can write some test automation helper code, create classes, make asserts etc.
  • Learn enough of general programming concepts so that you can write code for typical easy programming exercises available on the internet.
  •  Once you have mastered this, drill deeper into object oriented design skills/concepts and create a mock test framework testing a website or an application.
  •  Also attend tester gatherings and talk to other testers/managers and see what skills they seek in a tester.

Now, let’s have a look at testing job specs taken from 2012. This research has been done by a UK based recruitment company.

Percentage of jobs that require Good/Exceptional coding skills:

Q1/Q2 2012 – 63%

Q3/Q4 2012 – 84%

Breakdown of languages required:

  Q1/Q2 2012  –  28% – Java, 26% – C#, 23% – Ruby, 16% – C, 7% – PHP

Q3/Q4 2012  –  39% – Java, 35% – C#,  8% – Ruby, 12% – C, 6% – PHP

The remaining  37% in Q1/2 2012 and 16% in Q3/4 2012 were a mixture of “we don’t need someone with any coding experience”, or “we purely need a Manual tester.”

Research also shows that salaries for testers with exceptional coding abilities have risen by £3500 per annum in the past 6 months.

What this means:

The research above suggests there are 21% more people being hired in the past 6 months alone with good to exceptional coding knowledge than without, however, there is clearly still a requirement for Manual testers.

Java is a still the main scripting requirement but Ruby has become increasingly popular.

Top Test Automation Technologies are:

  •   Selenium, including SeleniumRC and Webdriver
  •   QTP
  •   XUnit frameworks such as JUnit, NUnit, TestNG, etc
  •   BDD tools like Specflow/Cucumber
  •   Watir or Watin.

The above results are for the UK. A similar study was done in the US not long ago and you can read the details about that here.

Final Words:

Adam Goucher is probably right. But for now, manual testing and manual testers are here to stay. As more and more companies move towards the “Developer in Test” mentality, I see future testers taking up coding, especially if they want to work for the best companies and not to forget, these roles pay considerably more as compared to manual testing roles.

Comments & Bad Comments

You should always strive to write your code so that it does what it looks like it does.  Have you heard of the phenomenon called the “write-only code”? This is code that made some kind of sense to whoever wrote it at some point in time, but it is difficult to understand for anyone trying to read it a later date, even if the person reading is the author. This kind of problem can be resolved by comments in the code.

Although comments can be very useful but sometimes it can also go wrong. I saw a common mistake today, which is this:

//Updating all records


//Updating 20 records


As you can see, these comments are just repeating what the code already said. This is just a waste but surprisingly, this is very common. One of the reason for this is mainly because these developers have been told that comments are good, but they have no idea as to what makes a good comment. A comment should say something that is not obvious from the code and which is likely to be useful to anyone trying to understand the code.

Another common fault is this:

//Updating 30 records


Here, the comment contradicts the code which is not very helpful. This kind of thing usually happens when someone modified/refactored the code without updating the comment. A quick review of the comments after a code change is always worth doing.

Moving from Selenium RC to Webdriver

Two years ago, while working at the The Trainilne, I was part of the Automated Refunds project and the main QA/Developer for its automated test framework. The aim was to replace the existing mainly manual system and provide a transactional and fully automated refund processing system.

As this application was mainly to be used in Internet Explorer, we decided to build an automated testing framework using Selenium RC, NUNIT and C#. This testing framework was a success, with 30,000 lines of code (including coding of 120 tests) and 1650 Assertions.

My Selenium journey started way back in September 2006, while I was still at University and was doing my work placement at Volantis. The selenium RC version back then was 0.8.1 and Selenium IDE was 0.8.2. Selenium has come a long way since then and became a popular and well established testing framework that worked with a large number of browsers, allowed you to write your tests in almost any language, it was Open Source and as it was written in JavaScript, it was very easy and quick to add support for new browsers that might be released.

But it was not perfect. I took a lot of shortcuts, cut corners and did stuff in ugly/dirty ways to get things done. JavaScript being selenium’s strength was also its weakness. Browsers impose a very strict security model on any JavaScript that they execute in order to protect a user from malicious scripts. Examples of where this security model makes testing harder are when trying to upload a file (IE prevents JavaScript from changing the value of an Input file element) and when trying to navigate between domains (because of the single host origin policy problem). Selenium API has also grown over time and with that, it’s become harder to understand how to best use it. I personally found the API difficult to navigate.

To solve these problems, I said Hi to Selenium 2 also know as Webdriver! Webdriver takes a different approach to solve the same problem as Selenium. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser. For Firefox, this means that WebDriver is implemented as an extension. For IE, WebDriver makes use of IE’s Automation controls. According to Selenium HQ:

The primary new feature is the integration of the WebDriver API. This addresses a number of limitations along with providing an alternative, and simpler, programming interface. The goal is to develop an object-oriented API that provides additional support for a larger number of browsers along with improved support for modern advanced web-app testing problems.

Let’s hope that is the case. I am starting to switch over from Selenium  RC to Webdriver. Along the way, I will be sharing my findings with you. The aim is to one day, change the beast (Automated Refunds Testing Framework) from Selenium RC to Webdriver. I will also be using Automated Refunds as my guinea pig while learning Webdriver. Watch this space!

My New Site is finally Up & Running !

My new site is finally up and running yay !

I’ve changed the look and feel, bought a new domain name and also changed my hosting company. So hopefully this site will be a alot more stable as compared to before.

I now have the boring task of migrating all previous articles/posts from the old site to the new one. I would have been happy if it was a straightforward copy & paste, but in few cases it involves modifying the posts or formatting the data so that they don’t look out of place in the new site.

Its also been a while since I wrote anything new for my site. Hopefully I’ll get time to write something soon. Watch this space 🙂