Programmers as Testers?

There was an interesting and bit controversial thread on the agile testing yahoo group over the last couple of days. Some people thought that all agile testers should have programming skills. Others thought that programmers cannot possibly be good testers because they don’t consider overall quality.


It raised a lot of thoughts in my mind, so I thought I’d put them down here. I started my career as a programmer and developed much of my attitude towards testing in my first job. My supervisor was diligent about making me walk through the tests I wrote, and my test results. We did all our own functional type testing, and the operations group did the installation and system testing.

Programmers can make excellent testers, and on agile teams that practice TDD, when asked, they say they spend about half their time testing. Teams that truly practice the ‘whole team’ approach and believe everyone on the team is responsible for quality will work together as a team to make sure all the necessary testing is done.

That said, I probably wouldn’t hire someone who’s main passion was programming and saw the tester role as a stepping stone to being a programmer – mostly because they wouldn’t be committed to the craft of testing. However I do prefer testers with a technical background because it makes it easier for them to collaborate with the programmers. That does not mean I wouldn’t hire testers who do not have programming or some kind of technical background. Depending on the tools the team uses, it is not an absolute necessity... as long as they are willing to learn. I look for attitude.

There are many testers who are “ex-programmers” – I am one, so I wouldn’t let the fact they are programmers stop me from hiring them as testers if that is what they want to do.

Testers do add value to an agile team – with or without programming experience. They can see the big picture and consider impacts to the system that programmers often miss. When programmers are in a team, they are programming at the code level. It is hard for them to switch contexts and be concerned about the big picture impacts. I think we sometimes do teams harm when we ask them to switch contexts often. I’ve seen “programmer only” teams be successful, but they do have to make a conscious effort to think big picture and often have one team member play the role.

To quote Lisa Crispin, “Diversity of skills and viewpoints is critical to a successful project. We need people with different backgrounds, different types of experience, different abilities working together.”

I do not believe an agile team can succeed in the long term without automation of some kind. We need to consider the agile testing quadrants, as well as the pyramid. Our regression suite includes automated unit tests, as well as service layer tests and yes, some GUI and workflow tests. We do need to remember that automation does the checking – it doesn’t find new bugs but exposes unexpected changes. Automation is necessary, but not sufficient, so the team needs the skill set to support all automation tasks.

The team also needs skills to perform exploratory testing, and most often those come from someone with a testing background. I have seen several teams be successful where “manual” testers create/design the tests using Fit, or a Fit-like type of interface, while the programmers create the fixtures in the code itself. This has been very successful, and when it was done using Ruby instead of Java, within 1 ½ years, those manual testers were supporting the whole automation framework. They learned how to code in Ruby, but still collaborated with the programmers on new ideas.

I don’t really care who does the automation – unit tests, API or service layer, GUI / scenario tests, load automation, etc..... , as long as it gets done in a timely way, and provides the feedback necessary.