Many developers and even testers believe that testers should not be able to look at the code. They have a belief that the tester might identify defects just by looking at the code. I very much agree with this. If I am not able to find defects during the system testing then people might get a perception that I am not a "good" tester or I am not dedicated to my job and I would certainly not want this perception about me. But this is not my point when I say that tester should have access to the code.
Both the tester and developer have one thing in common i.e. the functional specifications. However the developers also have the technical specification. Usually their main focus is on the technical part. This leads the developers to miss out on the whole purpose of what the code is actually supposed to do. This is one of the reasons why lots of defects are clustered over one area. It doesn't matter if the code is very much efficient if it was not processing what it should be.
There will be times when defects are found in one common area. This is because the dev has not understood the functionality correctly and has a different understanding.
At this stage, the tester should have a look into the code and tell the dev that this where you're going wrong and the logic should be this instead of increasing the bug count to his name.
But beware this will not at all go down well the developers !!!! Only tell them that the logic behind the code is incorrect.
Now one might say that how would the tester understand the written code??? My suggestion (and Cem Kaner's-Lessons Learnt in Software Testing) for such testers would be to first go and learn a programming language. I am not saying that become a master of that language, but just get used to the whole feel of coding. Writing code is not tough, it's the logic behind the code which is challenging. The logic is all what the tester needs to care about and not how efficiently the code has been written.
