Should developers test?

These are some of the arguments I have heard over the years:

1. Developers can’t test because they don’t have the right mindset, testers think about negative cases and how to break the system, developers only think about the happy path.

Is this true? There is indeed a huge amount of hackers that don’t care about much, and don’t give a rat’s arse about the quality of their code because they know there is a large number of lowly paid human beings called testers that will clean after them like a babysitter. They feel they shouldn’t bother with testing because other people will do it for them, they focus on writing tons of rubbish code and if a bug is found in production they don’t care because somebody will blame a tester for not finding it, certainly not them for writing it. I call this species the “half developer”. A large generation of half developers has been produced by some management thinking that by assigning a time consuming task like testing to somebody they can pay less they would have an overall cost saving with no repercussion on the product.

But is it really true that developers can’t test? Testing is a software engineering activity, as much as analysis, design, coding. Why in the name of God, developers would be so dumb that they cannot learn it? Please give me an explanation based on facts and not on the “mindset”.

Half developer going for a walk on the beach
Half developer going for a walk on the beach

When a developer tells me that he doesn’t have the right mindset for testing, expecting me, tester, to agree and reassure him like a loving mummy, saying “don’t worry I have the mindset and I will do it for you”, he is up for a surprise. I will stare at him with a concerned look and tell him: “Dude, I can help you learn the fundamental engineering skill you have ignored until now, so that when you have mastered it, you can finally call yourself a developer. You are welcome.”

2. Testers have a better understanding of the big picture

Why? Let me guess. In the aforementioned organizations where large amounts of babysitters are employed to clean the mess, developers time is so precious that they cannot be distracted by the real business of the organization they work for or by whether the business value is actually delivered. They must focus on writing code, the way such code will integrate with the other systems is not their concern, the babysitters will do integration testing, why do I bother knowing how the system works if the babysitters know it and will check it for me? I call this species the “clueless developer”.

But does knowing the big picture help developers make the right decision and write better code? Hell yeah! Without understanding the value that needs to be delivered, developers at best will write very efficient code that does nothing important.

So yes, yet again, a real developer understands the big picture, is fully aware of the business value he is delivering, and he will be able to contribute to the design of a business solution, however, clueless developers can skip this insignificant bit.

3. Testers are the voice of the customer

Of course, developers are too busy writing complex code to think about who will use their software and they can’t do anything about it for some strange reason, only the testers MUST talk to the customer! I call this the “sociopath developer”.

Sociopath developer: “Who cares if the customer can’t use my code as long as it does compile? What did you say? You told me you wanted this button otherwise you can’t do anything with my software? I must have had my headphones on, that’s what cool developers do, write code and listen to music, screw customers.”

Sociopath developer faces reality
Sociopath developer faces reality

Do people like this really exist? If they do, should we call them developers?

4. Context switching is bad, developers should develop, testers should test

This is probably the lamest argument of them all. Apparently a developer is able to switch between, analysis, design, code and coffee breaks but it is only the switching to test that magically creates context switching issues. I call these the “selective switchers”.

5. Developers can’t test their own code because they are biased

I ask you developer to honestly think about what your real goal is?

1) Producing successful software

2) Showing off in front of your colleagues

If you answered 2 you are a primadonna and I have no interest in working with you, so please get out of my blog now. If you answered 1 you are a real professional and you will find bugs in your own code, don’t worry.


17 thoughts on “Should developers test?

  1. Completely agree, the tester is a role that should disappear when the level of maturity and quality in the team is high.
    But until the team is not mature enough, testers play an important role, that is not to merely test the software, but it’s to enforce the test process and help the developers in following the best practices for testing.

  2. Marco, thanks for your comment. I don’t think the role of tester should be enforcing practices, in general I don’t believe in the benefits of enforcement as a concept. I believe though that testers can help and coach half developers in understanding the value of said practices so that they will use them voluntarily and become excellent developers.

  3. In advance sorry for my english 🙂

    I do a lot struggle to understand the concept of mindset in relation to speech testing.
    What it means to have the right mindset?
    I think that a tester should be like the conductor of an orchestra that plays the dual role of coordinator and coach for the entire orchestra according to the sheet music.
    Often the developer is concentrated to implement the specification without wondering what him is implementing. @_@
    In many cases, i’m talking about of my experience, there is not a critical view of business that he is implementing (monkey developers delegate to tester for finding bugs).
    Developer are not too busy writing complex code but in many cases them are busy to tie technology and business specification.
    A simple game for a developer:
    Augusto try this : take a developer and you ask to him :
    Hey mate there is a bug in production due to X, Y, Z
    Can you formalize the technical-functionalty solution in uml or in pseudo code regardless of the technology ?

    • @raju, I am not sure where you read that, my article responds to some arguments around the inability of developers to test. I believe developers can test, I am not advocating the exclusion of testers from agile teams.

  4. There’s a fundamental ground in this article to which I disagree: testers and developers being two different roles. While I agree with all the concept expressed here I don’t agree on the war-like approach, the division between the so called testers and the so called developers. I could understand a separation between coders, analysts, designers and testers, but if we speak in terms of software developers I don’t agree on the distinction.

    As software developers we should all focus on “developing the best software solution that meets the business requirement”, where the key word in that sentence is “best” as it greatly vary as a function of the business requirements.

    Anyway, I wouldn’t consider someone being a software developer is he doesn’t show some skills on software quality.

    I believe that “separation of concerns” has been put in place not only by lazy programmers, but by cheap monkey-like testers that are so often found around in the IT industry: hire a bunch of monkeys and let them play with the system rather than use our expensive software developers produce useful/usable software.

    This doesn’t justify lazy developers still surrounding you, but please don’t consider software developers as a category of enemies: you are a software developer too 😉

    • Roberto, thanks for your comment. I think we are saying the same things, but as usual you can express it better than me 🙂
      Have a look at my T-shaped tester/agile team member if you want to understand better the context of this post.

  5. Testing is a profession that requires a great deal of knowledge in terms of types of testing, testing processes, test completion and test case selection criteria, test tools, test environments/bed, test labs/facilities, etc.

    Just like most programmers are not qualified to be requirements engineers and architects (both professions with their own methods, techniques, tools, etc.), most are also not qualified to be testers. Whereas programmers should unit test their own code (or the code of a peer as in pair programming), they are very rarely qualified to perform integration testing, system testing, specialty engineering testing (e.g., reliability, safety, security, usability), etc.

    Of course, if you hire low-paid newbees to be your testers, then they are also not qualified.

  6. Donald, thanks for your feedback. I appreciate the fact that if developers work in environments where they can rely on other people to test their code then they will never learn how to do that for themselves. You say “they are not qualified” to test, let me ask you, what stops them from being qualified to test?

  7. I have about equal experience as tester (first) and developer (nowadays), with success in both roles. After a certain point, it is more economical for someone else to find the remaining flaws in my work than it is for me to find them. That is true regardless of that person’s role (be they developer, tester, technical author or, ahem, user). As a developer I aim to respect that other person’s time as much as my own – I don’t want them finding the sort of flaws that are obvious to anyone.

    I think that some of the viewpoints expressed in your article may originate from highly skilled developers who deeply understand their craft, and that without really understanding them, you have ascribed the opinions to those who you characterise as “half-developers”.

    On point 4, the other tasks you mention (including the coffee) are “making”, so I can switch more comfortably between those. The switch from making to breaking I find harder. I am good at both, but if I try to do both in the same day it’s a less productive day than if I focus on one or the other.

    On point 5, I didn’t just sneeze and out came some code (or a test) – I made all sorts of decisions and assumptions as I created it. I can’t imagine investing time and effort in producing software whilst at the same time staying completely impartial about whether it works or not, so I think it’s inevitable that I become biased in its favour. An independent evaluator who is free of those decisions and assumptions is therefore less biased.

    Whilst I agree that a good developer can and should test, I also think that achieving quality without multiple perspectives is extremely, and unnecessarily, expensive.

    • Dylan, thanks for your feedback. I am afraid you have read more than I really wanted to say. The question I tried to answer (as per title) is “should developers test?”
      On your last point in particular, nowhere in my post I say that developers should be the only ones that test, have a look at some other articles on my blog where I discuss shared activities.

      • Fair comment. My last point was more in response to Marco’s implication (and I’ve heard the same view elsewhere) that if developers did their jobs properly, testers wouldn’t be needed. The testers I work with make a great contribution. On a poor team, yes, testers may find that a large portion of their time is spent making up for deficiencies in development, and in those circumstances I agree with you that they should be coaching the developers in good practice.

        In essence I was saying that if your post had only had items 1 to 3, I could have agreed with you 100% rather than 60%.

        • Thanks for your comment Dylan, I see where you are coming from and I can tell you that on point 5 since I wrote the post I had time to reflect on the feedback I received and I have moved my stand towards yours. On 4 we will have to agree to disagree, but we have a healthy 75% agreement now 🙂

Leave a Reply

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

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

Google photo

You are commenting using your Google 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