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.
