A software tester created a presentation about “the role of a tester”, and discussed whether “software developers” make good “software testers”. I thought the presentation was a bit confusing, because in some parts it sounded like she was saying they can, but in other places, it sounded like a categorical NO.
I found this quote recently from Ron Gilbert, creator of computer games like Monkey Island and Thimbleweed Park. It covers “game development” specifically:
Don’t believe the myth that programmers can test their own code. They can’t. Programmers will test for all the conditions they can imagine, but a good tester will imagine many many more and players will try things programmers never even considered. Knowledge of their code is the achilles heel of programmers. I’ve had code I was 100% sure was rock solid, only to have one of our testers reduce me to tears. A good tester excels at poking your code in places you never considered. I’m not talking about your unit tested sort routine, I’m talking about complex puzzle logic and odd UI uses. It’s the stuff unit tests will never catch, but a good tester will. Testers are the unsung heroes of your team, treat them very well.
Ron Gilbert – https://grumpygamer.com/delores_dev
This is the way I see it:
There’s the concept of being “close to the code”. So the developer that wrote the code will test exactly how they implemented it – and not test the cases they missed; because they never thought of those scenarios in the first place.
A tester inside the company could be influenced by their relationship with the developer; have some unconscious bias about not wanting to find a flaw in their code because they don’t want to upset them.
A tester for a third-party has no connection to the code or the staff at the company. They can test it without any bias. Finding all bugs is a good thing, because it enhances their reputation and should help with repeat custom. This is a good rationale for why some companies choose to outsource the Testing aspect entirely.
When I have worked in small teams and there is a testing backlog, sometimes the developers will help out with the testing, but they won’t test their own work; they will make sure it was done by another developer. This helps alleviate the above point slightly.
I have heard many developers say “they aren’t testers”, “I don’t know how to test” etc and for the most part; I think that’s nonsense. If you understand code and how to use software, then you understand how to test it. Sometimes it is directly transferable skills, but I think sometimes you need to take a step back, “put on another hat” and try to look at it from another perspective. For example, you then think “If I was a user, what would I want to do?”, “if I hated the company and wanted to find a bug in the code, no matter what it is, what would I try?”. You poke it in different ways. I think if you fail in the skill of being able to “put on a different hat”, then Ron Gilbert is 100% correct.
Personally, I have experience as a software tester, and as a developer. I do think I test my own code better than many other developers – ones without that experience. However, I don’t think I test as well as I used to when I was testing someone else’s code. It mainly comes down to the point I mentioned earlier – the fact that you only test what you know you have implemented and don’t test the things you haven’t. I mean, if you did think of it earlier, then you would have implemented it.
Stranger Coding Tings 