SIGIST Panel Winter 2013

December 2013 in London, at the SIGIST Winter 2013 Conference, I was on a panel session with Dorothy Graham, Paul Gerrard and Dr Stuart Reid

The panel session ran with the title “Should Testers Code”

I wrote up my notes on the panel in a blog post

Notes

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

#sigist the panel gets going! pic.twitter.com/bHzcoSsiRm
— SIGiST (@SIGiST) December 5, 2013

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.