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”.
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.”
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.