thesis - Faculty of Information and Communication Technologies ...

Chapter 7. Implications
tional support to this recommendation. However, this recommendation
should be extended to ensure testing covers both complex and popular
classes. But, is there a specific value that can be used as the threshold?
Though a specific and well defined value is appealing, different projects
have different needs and hence a universally applicable threshold is not
practical. However, in our study we were able to generate modification
probability models (See Figure 6.8 and Figure 6.9). Depending on the
risk profile of a specific project (at a specific instance of time), developers
can use these models to determine an appropriate modification
probability threshold.
7.2.4 Competent programmer hypothesis
The competent programmer hypothesis states that programmers write
code that is close to being correct [211]. This hypothesis is used as
one of the fundamental assumptions to support mutation testing [212].
Interestingly, though this assumption has been widely used, we were
not able to find studies that verify this assumption. Our findings provide
some empirical support for the competent programmer hypothesis.
Though change is unavoidable, we observe that most of the changes
made to classes are minor and the number of times a class is modified
in fairly small. The consistency of minor changes in our study indicates
that developers tend to deliver code that adequately satisfies the
requirements by the time of a formal release.
Although our observations are suggestive of the competent programmer
hypothesis, a system that has an abnormal modification profile does not
imply that the programmers are incompetent. Rather, it should be used
as a trigger to investigate potential underlying causes. For example, the
unusual change profile may be driven by a high degree of volatility in
the software requirements, or changes in the external domain.
190