“An agile team composed entirely of coders is just fine and dandy!”…. Really??

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?

5 thoughts on ““An agile team composed entirely of coders is just fine and dandy!”…. Really??

  1. Nice article. I’ve had this conversation in one form or another for 15 years. I like to say “Programmers make sure a program does what it is supposed to do. Testers make sure a program doesn’t do what it is not supposed to do.”

    I used to be a programmer. I found I liked breaking things more than creating them. So now I’m a tester and much happier. I still like to program test automation.


    1. Hi Darrell! Thanks for the comment!
      I like your statement about testers making sure the software doesn’t do what its not supposed to do! That’s one of 4 quadrants that i think about when im testing:
      – doesn’t do what its not supposed to do,
      – does do what its supposed to do,
      – doesn’t do what it is supposed to do,
      – does do what it isn’t supposed to do.

      I find if i break these down it keeps my thinking open and i am able to think of more scenarios around the functionality!

      One think i would say though, is that software testers don’t actually break anything! (unless its a DoS bug that we find!) 🙂
      Bugs already existent in the code we are testing… We just uncover them and flash a big light on them to let the stakeholders see it so they can tell us if they want them fixed or not.


  2. Hi Dan, very good reading. I am not sure which side I am on. I am a tester and have been one for a long time. I don’t think we should be thinking in traditional role terms when we try to be agile. I prefer to think that in my team we have people that are able to deliver a complex piece of software. Do I think my team could do the work well without me? Sure they could. An agile development team continuously evolves and improves, why should i think that they can’t replace me with a developer? Why can’t developers learn the skills I today use to help the team? If you are interested in what I think about the topic, have a look at what I wrote on the subject a couple of weeks ago. http://mysoftwarequality.wordpress.com/2013/08/10/should-developers-test/


  3. Hi Dan, I guess you weren’t present at Ciprian Balea’s keynote speech on the last day of RTC2019? The one titled “Just watch and let monkeys test for you”. He said, more-or-less, that Exploratory Testing “consists of clicking a lot”. This misconception seems to be prevalent, I guess it’s the job of testers to have conversations like the one you relate above. And preferably in a pub!


    1. Hey Ralph!
      I must admit, I skipped that talk at RTC…
      I agree with you. ET is much more than clicking around.
      Sure, it’s important to test for the many different ways you can interact with the software, but how you interact with it is just one type of risk within the product, out of hundreds of different types of other product risks.

      His “monkey” tool can’t test for any of these other risks. I’d view it more like a button/link checker tool. It’s useful for quickly checking that no buttons or links are causing a 404, crash or just not doing anything… But it won’t detect if the wrong page loads, or if the button looks awful, or if it’s inaccessible for some people, etc… That’s why ET is a human activity. It’s not “clicking around”. It’s thinking skills and investigation based around risks.

      And yes!! Testers need to also learn the skills in being able to talk about this, and present this within their organisations! That’s becoming just as important as doing testing these days. 🙂 (And doing that down the pub helps, as it’ll be a more relaxed and open than in a meeting room!)


Please leave a comment!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s