Are coders better testers than regular testers?

Are coders better testers than regular testers?

My opinion is – yes, they are – when they test other’s code. They can be good in both types of testing – black box testing and definitely white box testing.

In case of black box testing:

Black-box testing is a method of software testing that examines the functionality or behavior of an application or system (e.g. what the software does) without the knowledge of its internal structures. Black-box testers normally use techniques like:

• Decision table testing
• State transition tables
• Equivalence partitioning
• Boundary value analysis

A coder-turned-tester should be able to guess which component/part of the software is defect-prone.

For example, inserting appropriate validations at the boundaries of all equivalent partitions are sensitive and critical part of satisfying user requirement. He knows there is a possibility of development team to succumb to a common error and there is a possibility that a validation is missed for a particular boundary. He might have experienced this when he coded for his own software. Naturally he will take extra care when he will write test cases using BVA.

In case of white box testing:

A coder-turned-tester has the inherent sense of internal structure of the code. Hence he is expected to be good in white box testing. Internal structure of the software code is how the code is written. By looking at the code, an experienced coder can understand the flow of execution, interface call, data flow, data dependency, design patterns used etc. He is expected to be good at:

• Control flow testing
• Data flow testing
• Branch testing
• Path testing
• Statement coverage
• Decision coverage

How about taking an example of statement coverage? If client acceptance criteria are to achieve 85% statement coverage before each deployment of code, don’t you think a coder-turned-tester will be at ease to achieve this than a regular tester?

Another example, Client acceptance criteria are to maintain cyclomatic complexity less than or equal to 7. For those, who are new to this metric - Cyclomatic complexity (or conditional complexity) is a measurement. It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It is based on the number of decisions in a software function. A coder-turned-tester, who has a working knowledge of control flows and re-factoring of code, he will re-factor the code (and yes, without changing the behavior of function) to achieve the metric threshold 7 in more time-efficient way, when compared to a regular tester.

My opinion is true for not only testing done in waterfall, but also testing done in agile. Especially, agile methodologies that follow TDD, a seasoned coder-turned-tester supposed to have better understanding of the structure of the code. Better technical understanding helps him to concentrate on writing effective unit tests, than a regular (non-technical) tester. Here, I am assuming the agile team is cross-functional and the team works on collective ownership.

But, yes, one argument against my opinion can be coders normally think technical implementation of the requirement. They think about more technical aspects to improve the quality of code. Testers think from user point of view. Sometimes they make use of error guessing, monkey testing or exploratory testing to find if the application is robust enough to pass the test cases.

Do you have opinion other than this? Please feel free to let me know.