Should Testers Learn How to Write Code?

The debate on whether testers should learn how to write code has ebbed and flowed. There have been many blogs on the subject both recent and not so recent. I have selected the ten most prominent examples and listed them below. I could have chosen twenty or more. I encourage you to read references [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].

At the BCS SIGIST in London on the 5th December 2013, a panel discussion was staged on the topic “Should software testers be able to code?” The panellists were: Stuart Reid, Alan Richardson, Dot Graham and myself. Dot recorded the session and has very kindly transcribed the text of the debate. I have edited my contributions to make more sense than I appear to have made ‘live’. (I don’t know if the other contributors will refine their content and a useful record will emerge). Alan Richardson has captured some pre- and post-session thoughts here – “SIGIST 2013 Panel – Should testers be able to code? [11]. I have used some sections of the comments I made at the session in this article.

It’s easy to find thoughtful comments on the subject of testers and coding skills. But why are smart people still writing about the subject? Hasn’t this issue been resolved yet?  There’s a certain amount of hand-wringing and polarisation in the discussion. For example, one argument goes, if you learn how to code, then either:

a)    You are not, by definition, a tester anymore; you are a programmer and

b)    By learning how to code, you may go native, lose your independence and become a less effective tester.

Another perfectly reasonable view is that you can be a very effective tester without knowing how to code if your perspective is black-box or functional testing only.

I’d like to explore in this article how I think the situation is obviously not black-and-white. It’s what you do, not what you know, that frames your role but also that adding one skill to your skills-set does not reduce the value of another. I’d like to move away from the ‘should I, shouldn’t I’ debate and explore how you might acquire capabilities that are more useful for you personally or your team – if your team need those capabilities.

My Contribution to the ‘Debate’

Before we go any further, let me make a few position statements derived from the Q&A of the SIGIST debate. By the way, when the SiGIST audience was asked, it appeared that more than half confirmed that they had programming skills/experience.

Software testers should know about software, but don’t usually need to be an expert

Business acceptance testers need to know something of the business that the system under test will support. A system tester needs to know something about systems, and systems thinking. Software testers ought to know something about software, shouldn’t they? Should a tester know how to write code? If they are looking at code figuring ways to test it, then probably. And if they need to write code of their own or they are in day to day contact with developers helping them to test their code then technical skills are required. But what a tester needs to know depends on the conversations they need to have with developers.

Code comprehension (reading, understanding code) might be all that is required to take part in a technical discussion. Some programming skills, but not necessarily at a ‘professional programmer level’, are required to create unit tests, services or GUI test automation, test data generation, output scanning, searching and filtering and so on. The level of skill required varies with the task in hand.

New skills only add, they can’t subtract

There is some resistance to learning a programming language from some testers. But having skills can’t do you any harm. Having them is better than not having them; new skills only add, they don’t subtract.

Should testers be compelled to learn coding skills?

Most of us live in free countries, so if your employer insists and you refuse, then you can find a job elsewhere. But is it reasonable to compel people to learn new skills? It seems to me that if your employer decides to adopt new working practices, you can resist the change on the basis of principle or conscience or whatever, but if your company wishes to embed code-savvy testers in the development teams it really is their call. You can either be part of that change or not. If you have the skills, you become more useful in your team and more flexible too of course.

How easy is it to learn to code? When is the best time to learn?

Having any useful skill earlier is better than later of course, but there’s no reason why a dyed-in-the-wool non-techy can’t learn how to code. I suppose it’s harder to learn anything new the older you are, but if you have an open mind, like problem-solving, precise thinking, are a bit of a pedant and have patience – it’s just a matter of motivation.

However, there are people who simply do not like programming or find it too hard or uncomfortable to think the way a programmer needs to think. Some just don’t have the patience to work this way. It doesn’t suit everyone. The goal is not usually to become a full-time programmer, so maybe you have to persist. But ultimately, it’s your call whether you take this path.

How competent at coding should testers be?

My thesis is that all testers could benefit from some programming knowledge, but you don’t need to be as ‘good’ a programmer as a professional developer in order to add value. It depends of course, but if you have to deal with developers and their code, it must be helpful to be able to read and understand their code. Code comprehension is a less ambitious goal than programming. The level of skill varies with the task in hand. There is a range of technical capabilities that testers are being asked for these days, but these do not usually require you to be a professional programmer.

Does knowing how to code make you a better tester?

I would like to turn that around and say, is it a bad thing to know how to write code if you’re a tester? I can’t see a downside. Now you could argue: if you learn to write code, then you’re infected with the same disease that the programmers have – they are blind to their own mistakes. But testers are blind to their own mistakes too. This is a human failing, not one that is unique to developers.

Let’s take a different perspective: If you are exploring some feature, then having some level of code knowledge could help you to think more deeply about the possible modes (the risks) of failure in software and there’s value in that. You might make the same assumptions, and be blind to some assumptions that the developer made, but you are also more likely to build better mental models and create more insightful tests.

Are we not losing the tester as a kind of proxy of the user?

If you push a tester to be more like a programmer, won’t they then think like a programmer, making the same assumptions, and stop thinking of or like the end user?

Dot Graham suggested at the SiGIST event, “The reason to separate them (testers) was to get an independent view, to find the things that other people missed. One of the presentations at EuroSTAR (2013) was a guy from an agile team who found that all of the testers had ‘gone native’ and were no longer finding bugs important to users. They had to find a way to get independence back.”

On the other hand, by separating the testers, the team lose much of the rapid feedback which is probably more important than ‘independence’. Independence is important, but you don’t need to be in a separate team (with a bureaucratic process) to have an independent mindset – which is what really matters. The independence, wherever the tester is based, is their independent mind whether it’s at the end or working with the developer before they write the code.

There is a Homer Simpson quote [12]: “How is education supposed to make me feel smarter? Besides, every time I learn something new, it pushes some old stuff out of my brain. Remember when I took that home winemaking course, and I forgot how to drive?”

I don’t think that if you learn how to code, you lose your perspective as a subject matter expert or experience as a real user, although I suppose there is a risk of that if you are a cartoon character. There is a risk of going native if, for example, you are a tester embedded with developers. By the same token, there is a risk that by being separated from developers you don’t treat them as members of the same team, you think of them as incompetent, as the enemy. A professional attitude and awareness of biases are the best defences here.

Why did we ever separate testers from developers? Suppose that today, your testers were embedded and you had to make a case that the testers should be extracted into a separate team. I’m not sure the case for ‘independence’ is so easily made because siloed teams are being discredited and discouraged in most organisations nowadays.

What is this shift-left thing?

There seem to be a growing number of companies who are reducing their dependency on scripted testing. The dependency on exploratory testers and of testers ‘shifting left’ is increasing.

Right now, a lot of companies are pushing forward with shift-left, Behaviour-Driven Development, Acceptance Test-Driven Development or Test-Driven Development. In all cases, someone needs to articulate the examples – the checks – that drive these processes. Who will write them, if not the tester? With ATDD, BDD approaches, communication is supported with stories, and these stories are used to generate automated checks using tools.

Companies are looking to embed testers into development teams to give the developers a jump start to do a better job (of development and testing). An emerging pattern is that companies are saying, “The way we’ll go Agile is to adopt TDD or BDD, and get our developers to do better testing. Obviously, the developers need some testing support, so we’ll need to embed some of our system testers in those teams. These testers need to get more technical.”

One goal is to reduce the number of functional system testers. There is a move to do this – not driven by testers – but by development managers and accountants. Testers who can’t do anything but script tests, follow scripts and log incidents – the plain old functional testers – are being offshored, outsourced, or squeezed out completely and the shift-left approach supports that goal.

How many testers are doing BDD, ATDD or TDD?

About a third of the SIGIST audience (of around 80) raised their hands when asked this. That seems to be the pattern at the moment. Some companies practising these approaches have never had dedicated independent testers so the proportion of companies adopting these practices may be higher.

Shouldn’t developers test their own code?

Glen Myers’ book [12] makes the statement, “A programmer should avoid attempting to test his or her own program”. We may have depended on that ‘principle’ too strongly, and built an industry on it, it seems. There are far too many testers who do bureaucratic paperwork shuffling – writing stuff down, creating scripts that are inaccurate and out of date, processing incidents that add little value etc. The industry is somewhat bloated and budget-holders see them as an easy target for savings. Shift-left is a reassessment and realignment of responsibility for testing.

Developers can and must test their own code. But that is not ALL the testing that is done, of course.

Do testers need to re-skill?

Having technical skills means that you can become a more sophisticated tester. We have an opportunity, on the technical side, working more closely – pairing even – with developers. (Although we should also look further upstream for opportunities to work more closely with business analysts).

Testers have much to offer to their teams. We know that siloed teams don’t work very well and Agile has reminded us that collaboration and rapid feedback drive progress in software teams. But who provides this feedback? Mostly the testers. We have the right skills and they are in demand. So although the door might be closing on ‘plain old functional testers’ the window is open and opportunities emerging to do really exciting things. We need to be willing to take a chance.

We’re talking about testers learning to code but what about developers learning to test better? Should organisations look at this?

Alan Richardson: We need to look at reality and listen to people on the ground. Developers can test better, business analysts can test better – the entire process can be improved. We’re discussing testers because this is a testing conference. I don’t know if other conferences are discussing these things, but developers are certainly getting better at testing, although they argue about different ways of doing it. I would encourage you to read some of the modern development books like “Growing Object-Oriented Software Guided by Tests” [14] or Kent Beck [15]. That’s how developers are starting to think about testing, and this has important lessons for us as well.

There is no question that testers need to understand how test-driven approaches (BDD, TDD in particular) are changing the way developers think about testing. The test strategy for a system and testers, in general, must take account (and advantage) of these approaches.

Summary

In this article, I have suggested that:

• Tester programming skills are helpful in some situations and having those skills would make a tester more productive
• It doesn’t make sense to mandate these skills unless your organisation is moving to a new way of working, e.g. shift-left
• Tester programming skills rarely need to be as comprehensive as a professional programmer’s
• A tester-programming training syllabus should map to required capabilities and include code-design and automated checking methods.

We should move on from the ‘debate’ and start thinking more seriously about appropriate development approaches for testers who need and want more technical capabilities.

References

1. Do Testers Have to Write Code?, Elizabeth Hendrickson,  http://testobsessed.com/2010/10/testers-code/
2. Cem Kaner, comments on blog above http://testobsessed.com/2010/10/testers-code/comment-page-1/#comment-716
3. Alister Scott, Do software testers need technical skills?, http://watirmelon.com/2013/02/23/do-software-testers-need-technical-skills/
4. Markus Gartner, Learn how to program in 21 days or so, http://www.associationforsoftwaretesting.org/2014/01/23/learn-how-to-program-in-21-days-or-so/
5. Schmuel Gerson, Should/Need Testers know how to Program, http://testing.gershon.info/201003/testers-know-how-to-program/
6. Alan Page, Tear Down the Wall, http://angryweasel.com/blog/?p=624, Exploring Testing and Programming, http://angryweasel.com/blog/?p=613,
7. Alessandra Moreira, Should Testers Learn to Code? http://roadlesstested.com/2013/02/11/the-controversy-of-becoming-a-tester-developer/
8. Rob Lambert, Tester’s need to learn to code, http://thesocialtester.co.uk/testers-need-to-learn-to-code/
9. Rahul Verma, Should the Testers Learn Programming?, http://www.testingperspective.com/?p=46
10. Michael Bolton, At least three good reasons for testers to learn how to program, http://www.developsense.com/blog/2011/09/at-least-three-good-reasons-for-testers-to-learn-to-program/
11. Alan Richardson, SIGIST 2013 Panel – Should Testers Be Able to Code, http://blog.eviltester.com/2013/12/sigist-2013-panel-should-testers-be.html
12. 50 Funniest Homer Simpson Quotes, http://www.2spare.com/item_61333.aspx
13. Glenford J Myers, The Art of Software Testing
14. Steve Freeman and Nat Pryce , Growing Object-Oriented Software Guided by Tests, http://www.growing-object-oriented-software.com/
15. Kent Beck, Test-Driven Development by Example
16. A Survey of Literature on the Teaching of Introductory Programming, Arnold Pears et al., http://www.seas.upenn.edu/~eas285/Readings/Pears_SurveyTeachingIntroProgramming.pdf

Author Bio

Paul Gerrard is a consultant, teacher, author, webmaster, developer, tester, conference speaker, rowing coach and a publisher. He has conducted consulting assignments in all aspects of software testing and quality assurance, specialising in test assurance. He has presented keynote talks and tutorials at testing conferences across Europe, the USA, Australia, South Africa and occasionally won awards for them.

Educated at the universities of Oxford and Imperial College London, in 2010, Paul won the Eurostar European Testing Excellence Award. In 2012, with Susan Windsor, Paul recently co-authored “The Business Story Pocketbook”.

He is Principal of Gerrard Consulting Limited and is the host of the UK Test Management Forum and the UK Business Analysis Forum.

Mail: paul@gerrardconsulting.com
Twitter: @paul_gerrard
Web: gerrardconsulting.com