Tuesday, 17 December 2013

SIGIST 2013 Panel - Should Testers Be Able to Code

I attended the SIGIST in December because I was asked to be part of a Panel with the starting discussion title of "Should testers be able to code?".

I was on the panel with Dorothy Graham, Paul Gerrard and Dr Stuart Reid

Embedded image permalink

Initial Notes

I wrote the following in an email to the other panel members during the run up to the SIGIST. It wasn't polished but represented my notes and pre-conf prep.


I pretty much have to ignore the title "Should testers be able to code?"

In my mind "Should", at that point in the sentence equals "An obligation to..."

We don't work in an industry where testers have an obligation to code. So any question about obligation has no place in my reality.

I've met developers who do not seem to feel they have an obligation to be able to code. Similarly I've met testers who do not seem to feel they have an obligation to be able to test, or managers who do not seem to feel they have an obligation to be able to 'manage'. The process of Software Development has a lot of fungibility built in and can work with many different skill sets and skill levels on the project.

Personally, I do know how code, and while I can code some things as well as professional developers I consider my coding skills intermediate. Therefore I hope to phrase my answers in the form "When testers can code the advantages are ..." "When testers can not code the disadvantages are..." and "My experience of having up to date and intermediate coding ability has been..."

I do hold some opinions that might pop up:
  • "Testers who can not code, should not write automation code" 
  • "Testers who can not code well, will write worse automation code than testers who can code well."
  • and I suspect that "Many failed test automation programmes are a result of testers not knowing how to code". 
  • "I've also seen developers write awful automation code, I think automation code may require some different coding and design styles than application code."
I've worked with enough teams and reviewed enough automation code over the years to have some evidence base for those opinions. But we have an industry that has pretty low expectations around automation skillsets and automation, and for some reason has lumped most 'automation' in the 'testing' realm.

But this panel isn't about automation. Automation != Testing.

Much of my recent on-line work has been about lowering the barriers to entry for people who do want to code or develop more technical skills. I prefer to help someone do something, if they express an interest.

Personally I try to learn as much as possible about the process, and skill sets involved in, Software Development. One small part of that involves 'coding'. Other parts include "Architecture", "Design", "Databases", "Modelling", "Protocols", "Tools", "Estimation", "Planning", "Communication" etc. etc. etc.

I don't think that any role ("Tester", "Developer", "Analyst") has exclusive right to a set of skills, techniques and knowledge: "testing", "coding", "modelling", "analysis" etc.

I value diverse skills across the team.

On the Panel

My brain, working the way it does, has forgotten most of the questions and answers, so I revisit the memory with some degree of trepidation, false memories may well rear their head.

I think many of the above notes were covered during the Q&A. I was able to pull on some of the material from my Helsinki Talk on 'Experiences with Exploratory Testing...' because someone in the audience said "Developers should not test their own code", and so I was able to riff off the T-Shirt slogan slide from that presentation.

Basically - statements like "Developers should not test their own code" and "Developers do not make good testers" are the kind of statements people post on internet forums, and we should relegate them to T-Shirt slogans so we can mock them and laugh at them. Developers do test their own code, and they can learn to test better. The sooner the 'test community' wipes this nonsense from its collective meme pool the better.

Because we were sitting down on the panel, my opinions were phrased in a less confrontational amanner nd with more humour than might appear from the written form on this page.

I remember saying things like:

  • Projects depend on teams. So we need the team to have a diverse set of skills. And when we build teams look at the gaps in the skillsets.
  • Keep investing in your staff to make sure they keep expanding and improving their skillsets.
  • Becoming a better programmer has helped me test better.
  • Becoming better at testing, has helped me write code better
  • I recommend the book "Growing Object Oriented Software Guided by Tests"
  • Teams are systems. As soon as you add a team member, or mandate that they do something, you change the system. Keep looking at and evaluating the system.
  • Programming means lots of different approaches because there are different styles: OO, Functional, Procedural, etc. They require different skills and models
  • Modelling is a vital skill for testers

We on the panel certainly had fun, I hope the discussions and alternative view points added value to the audience.

End Notes

I think one message that came through from everyone on the panel was that testers need to have the ability to demonstrably add value to projects.

Having the role 'tester' does not mean you automatically add value.

Having the ability to write code does not mean you automatically add value (you might write really bad code).

Each tester needs to identify how they can add value.

The current market vogue is for testers with coding skills.

If that isn't your thang. Then it might mean becoming an expert in UX and psychology so that you can add more value for user focused testing. It might mean a whole bunch of things.

Each tester needs to figure out what they can do to add value, and what they can do to demonstrate their capabilities to the teams or potential employers.

And keep improving.


  1. Great read, wish I'd been there to see you on the panel.
    Reasoned arguments and not t-shirt slogans, and once again so much i can take from your writing. +100

  2. I like the article, too. I regularly question preconceptions. I had a manager that suggested we have the developers test their bugs because there too many for the test team to keep up. People's heads exploded. But then I saw the developers take responsibility for their fixes - no more throwing it over the wall. Since then, I question everything - and grow for it.

    1. Thanks for leaving a comment sharing your experience Dave.

  3. Hi Alan,

    So are you saying that a tester without a coding background should never write automation code but you have to start somewhere right? Don't agree on that point at all! Considering you sell a book Java for testers to help a tester code then your saying "Oh by the way dont code"

    1. Hi Anonymous,

      Thanks for taking the time to write a comment and offering me the chance to clarify my writing

      I am not saying "a tester without a coding background should never write automation code". I disagree with that too. At no point in this post did I write that, so I wasn't "saying that"

      Also, at no point did I write "Oh by the way don't code".

      I think you have disagreed with a point I didn't write or say. I assume your comment was based on something you inferred from the line of text "Testers who can not code, should not write automation code"?

      If so, you inferred something very different from what I hoped you would infer. If I misunderstood your response then feel free to reply quoting the text in the post that led to your inference.

      By that line of text, I meant. If you can't code, you can't code. If you attempt to write automation code without knowing how to code it is going to be excruciatingly bad. Don't do it. If you attempt to engage in automation without knowing how to code then you will end up with a non-coding automation tool and exist at the mercy of some tool vendor. I do not recommend this approach.

      If you are starting with a book like "Java For Testers" then you have moved into the "Testers who can not code well, will write worse automation code than testers who can code well." category. And you should adjust your expectations for automation accordingly. By the time you finish Java For Testers, you will be well on your way to a good start and hopefully you will build on that knowledge and become a good programmer.

      I thought one point I was making was. You don't have to learn to code to add value to projects, but if you choose to create automation then you should expect to work on your coding skills and keep improving them.

      Hope that clarifies.

  4. Hi Alan,

    I hear the points you are making but like I said before everyone has to start somewhere and its better to learn by making mistakes.

    I do agree that if your coding skills are not to a high standard yes it will be hard but like everything in life you keep on trying and trying you are bound to get better at it.

    I have studied computer science at uni a few years ago and I did some Java on my courses but never went down that road however Im very interested in automation and I am reading your book and also watch online video's in cave of programming.com and I do feel im picking it up.

    Im not saying am the next Bill Gates but in order for me to use Webdriver i need to start putting in to context what I have learned and actualluy writing very small simple tests and as time goes on build on that to more complex stuff.

  5. I recall Dorothy making a statement a few years ago re:testers and automation. (I paraphrase.) "You've not only lost a tester but you've gained a bad developer." I would be curious if anything like that came up on this panel.

    1. I think Dot quoted Hans Buwalda's statement in her Keynote. It may also have come up in the discussion, I don't really remember.