I regularly have some great conversations with other testers and developers that I socialize with, and a few nights ago I met a developer and got absorbed in a conversation with him about agile… Let me tell you how the conversation went.

In the beginning, I found myself in agreement with the majority of his statements about agile, about the principles of agile and about teamwork and being lean… until he said: “a team composed entirely of developers is just fine and dandy”…

I asked him for clarification on his definition of “developers”, as I know that some people consider “developers” to include coders, testers, BA’s etc, i.e. everyone in an agile team makes up the agile development team… We all build a quality product together. But he informed me that when he said “developers” he meant “coders”, meaning that a team full of coders with no testers in it at all is “fine and dandy”.

I was a little confused about this statement. So I then turned the question around and asked him what he thought about the statement: “a team composed entirely of testers is just fine and dandy”.

He chuckled a bit and said that would be silly!
“That’s silly… That’s not feasible at all!” I think were his actual words. And when I questioned him further about why he thought like that, he said that developers are “multi-skilled” in being able to code and test, whereas “testers can’t build a product as they don’t know how to code”.

Now, I understand that some testers don’t know how to write code. (And that’s perfectly fine!).
And I know that some developers do actually make great testers. (And if you work with someone like this, don’t ever let them leave!!). But to say that ALL developers make good testers and that ALL testers don’t know how to code is just nonsense!

I went on to explain to him my opinions on why a lot of developers (most developers that I have worked with) don’t have the same thinking pattern as testers do… Developers think constructively, (which is what we need them to think like for building software in the best way possible). And testers think destructively, (which is exactly how we want testers to think as the more scenarios that they can think that the software might fail then the better)…

We each have our roles within the team to build QUALITY software. If you want to have that quality label, you need the best people possible to investigate your product in order to determine what level of quality the software has, so that it can be enhanced to be at the highest permitted level of quality that you can build within your means. If you don’t employ the people who are best at investigating, then you are lowering your means in being able to determine what level of quality the software has, therefore that has a diverse effect on the level of quality you can produce…

This broke the conversation into new realms, where he said: “But that’s not what testers do!! Testers don’t investigate… They click buttons!! “………..
After I collected myself, I went on to discover that the company that my new friend was working for seem to employ a single “QA Engineer” that writes lots of step by step test scripts, that they then hands the scripts to the “testers” to follow to the letter and mark a tick or a cross in the box next to the expected result column.

Now, I usually like being in a situation where I am able to dispel misconceptions, but sometimes it feels like we are fighting a losing battle…. I quickly tried to set the record straight around the misconceptions of job titles in this instance. The “testers” that are employed by my new friend’s company are not testing! They are checking.

They shouldn’t really be called “Testers” as they are not testing. In-fact, the only person employed by that company that could be considered a tester is the “QA Engineer”, as that is the person who is thinking about the system – how it might fail, the risk areas, the requirements and other sources of information about the product and what it should and could do, although even that person is being limited with being able to investigate the software to determine what the software does do.

My new developer friend left the conversation with a new insight into the roles within his organisation and what those roles could be. Hopefully he’ll be able to influence change within his organisation to allow the “testers” to break free from the shackles of their scripted checking!

What about you? Have you ever found yourself in a similar situation where you had to contend with misconceptions such as this one? What are the misconceptions that you found yourself meeting and how did you get around them?