Why developers don’t find defects
Jan18
Fellow Twit @testingqa recommended this article to me. It’s about how your brain hides facts from you. Even if these facts are the thruth. This also has its effect of the software development process. On how testers should look at the SuT, but even more important why developers don’t find defects.
As a test manager I try to help developers test their created code and software. Most of the time they tend to check their code quite thorough but don’t see the errors in the software itself. They tend to look only at the mistakes in their own code, but don’t see errors everywhere else in the system. It’s like they don’t ‘see’ the defects.
When I was reading the article I learned that scientists have the same problem. They ignore failures. Kevin Dunbar states “Although we pretend we’re empiricists — our views dictated by nothing but the facts — we’re actually blinkered, especially when it comes to information that contradicts our theories.” I think this goes for a lot of ‘logical’ engineers. I state engineers because not only do software developers have this problem, but also analysts and testers. But why is this? Why is all data is created equal in our mind’s eye, but some data is created more equal than others?
This is because a part in the brain. This part, the dorsolateral prefrontal cortex, or DLPFC, is editing our reality. If you would like to know where it is. It’s located just behind the forehead. This DLPFC is one of the main reasons people ignore or suppress unwanted representations. It deletes unwanted information.
When a developer is checking the software for defects the software produces failures. And because the failures are unwanted to the developer they are ignored. Maybe they are not ignored on purpose, but because of the developer’s brain. Their DLPFC’s kick into gear and delete the ‘image’ of the failure from their consciousness. In most contexts, this act of editing is an essential cognitive skill. However, when it comes to noticing anomalies (defects), an efficient DLPFC can actually be a serious liability. The DLPFC is constantly censoring the world, erasing facts from our experience.
How can we help developers overcome this disability? We know it’s in their brain, but there can be action on taken on this. The article states four steps.
First of all check your assumptions. This is a skill a tester sometimes lacks. Run the test again and check if the failure is still there. Then look at your test and see if the test is correct. But also developers need this skill. They run checks at the system and when these checks fail, the system can be correct and the check can be false. Seek the correct failure.
Next is to seek out the ignorant. Use people from the outside to look at your software. Explain to them how it works and what is wrong. They can have a different view at the problem and can help you fix the problem in another manner.
Too often, developers assume that a failed check is a wasted effort, but testers or users think otherwise. Even analysts can see in differently. Let this diversity help enhance the software and make it work better. More different eyes on a system creates more helpful views on it! When everybody ‘sees’ the system the same way they all have the same DLPFC that kicks in.
The DLPFC shall kick in ‘delete’ the unwanted information. But if you are aware of this you can help yourself to take actions on it. You can try to be very methodical at what you see and act on this instead of your brain.
What I get out of this is that diverse teams help to develop better software. These teams can help each other to look at problems from different viewpoints. Agile teams try to use this diversity create a product faster, but also better. With this in mind agile seems to be a good option to use to help developers not to use their brain J!
January 18th, 2010 at 11:15
Thanks for this explaning blog!
Beside my job as testcoordinator, I also develop my own tools and websites. And I must say that it is hard to test my own work. I have to sit back, put on my testcap and look at the results of my developing with a different mindset. Only in this way I can tell what is still not correct or should be improved.
I always encourage testers to develop their developing skills. This help them look to the SuT with a completer view.
And it is a comfortable thought that I can always blame my DLPFC for not finding these nasty bugs
January 19th, 2010 at 15:36
Fascinating. I think a lot is made about the differences between the mindset of the software tester and the software developer. We’re all human beings though and I know I make mistakes as a software tester just as software developers do.
Personally I think a lot of it depends on what your main objective is. Developers are focused on delivering code. Testers focus on finding software defects. If developers stopped writing code and set their objective to finding software defects then I’m sure that they would make great software testers too. It’s just re-aligning your objective, and as mentioned changing your viewpoints. Would be interesting to see if software testers could make good developers with a little bit of training.
Perhaps that’s one of the things I really like about software testing. With software testing you are driven to think more about your viewpoint and objectives. With software testing you have to look for problems from different viewpoints in order to make sure you help drive the whole team towards delivering the highest quality possible. In software testing seeing things from the developers, users and project management’s perspective is essential.
William Echlin
http://www.SoftwareTesting.net
January 31st, 2010 at 16:57
Good points, clearly expressed.
I sometimes express the difference in mindset between developers and testers this way: Developers want to prove their code works, and testers are looking for ways the code might break (including ways the code doesn’t satisfy users, even if it is functional).
Not meaning to get on anyone’s bad side, I have to say I don’t think it is a big leap for a developer to switch gears and look for weaknesses in his/her code. The fact there is a need for testing specialists may be a “smell” suggesting possible areas of improvement for software developers’ skill sets (or mindsets, as the case may be). The two “professions” of developer and tester should merge into one, IMHO.
September 4th, 2010 at 00:12