Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, starting out with Logo turtles. With more than 15 years of developing commercial software, he has vast experience in software methodology and practices. Gil is the product manager at Typemock, working as part of an agile team in an agile company, creating tools for agile developers. He promotes unit testing and other design practices, down–to–earth agile methods, and some incredibly cool tools. Gil speaks locally in Israel and internationally about unit testing, TDD, and agile practices and communication. And in his spare time he kills dragons, for fun. Gil blogs at on different agile topics, including processes, communication and unit testing. Gil is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. You can read more from them at their website. View Full User Profile

The Real Enemy: Testers That Can't Program & Programmers That Can't Test

  • submit to reddit
Lior Friedman asked whether a tester should know how to program or become obsolete. Lanette Creamer said the same fate awaits programmers who can’t test.

This kind of discussion only happens in the dark corner of the software world. Within our small community.

In most companies, nobody thinks about this.

Human Resources

“When we hire a tester, make sure he does only that. God knows we don’t want to pay him like a real programmer.”

“When we hire a programmer, we don’t want her to spend her time testing, that would be a waste.”

Companies still hire to fill positions. Programmers have a very different job description than testers.  Job descriptions, however,  don’t help with fulfilling the business’ mission. 

It starts with hiring, but doesn’t stop there. Let’s say this company is one that really believes in “our employees are our most valuable assets”. How does it train its employees? Of course, programmers are encouraged to learn more programming and debugging techniques. Testers are trained in deeper testing methodologies.

Changing Roles

The agile manifesto talks about collaboration and interaction. Scrum talks about the team. Neither talked about testing and programming roles.

Extreme programming, you say? Doesn’t mention roles. But does talk about programming and testing.

The reason there’s no squabbling over roles in agile land is that role separation is really none of the business’ business. Agile methodologies are about making the business money by building quality software fast. All the process you need is already there, anything else just puts wasteful constraints on the system.

Software needs to be of high quality. For that it needs to be programmed and tested. It doesn’t really say who does what. Make it so.

And yet we’re still attached to these titles. Asking if programmers can test, or tester can program is reinforcing titles over skills.

What we’re actually doing is reinforcing HR’s role in the organization.

We’re All Developers Here

Programmers should know how to test their code. Without testing they are going to waste both theirs and the company’s time on bugs.

Testers need to program. Without automation, they are going to waste both theirs and the company’s time on manual rote work.

We all value working software over comprehensive job descriptions.

We’re all software developers.

Who hate HR.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)