- resource planning for testing. Given the importance that many higher-level managers put on the question "When do we start testing?" moving out the start of testing can be really hard to justify.
- We don't want to touch our process. You would hear this argument in an organization that has recently invested a lot of time, energy, and money into improving their software development process and is wary of introducing yet another change. They might feel they already spend an awful lot of time and money on finding defects, and would need to do a lot more measurement with regard to the effectiveness of the tools and processes they just installed, before they add more to their process.
- Fear of bureaucracy. Then there are those who have not invested heavily in a development process, because they love their informal culture. They feel that inspection increases the amount of bureaucracy and restricts their creative approach to software development.
3. Complexity. Inspections can be performed in different stages of the development cycle. Requirements, designs, and implementation/code can all be inspected. Development principles like separation of concerns, as supported by the V-model, help to keep the complexity under control. But the sheer size of modern software applications, where a mobile phone application can be a million lines of code, adds a whole other dimension to complexity. The perception of high complexity is strongly related to this dimension:
- How can this be better, faster, and cheaper? The fear of delayed schedules, while the actual measures show otherwise, is perhaps the best example that the perceived complexity of inspection is high.
- We don't have the resources. Even if the relative advantages are understood, there is the practical complexity that you need people who are proficient in the programming language, have sufficient application knowledge, have been trained on doing inspections, and last but not least, have the right attitude. It may be far from simple to find these people and direct their effort towards inspection, away from what they're doing now. Often, the attitude of test engineers is better, but they might not have the coding skills that are needed to do an effective inspection.
4. Trialability. To get meaningful results, you need to inspect a nontrivial piece of code, which will usually involve quite a few people. This leads to an additional concern:
- The investment is too high. Introducing inspection means training people and setting up a structure to collect and process metrics.
5. Observability. The measured results cited in volumes of inspection literature speak for themselves. But observability also refers to the extent to which the benefits can be imagined or described. This turns out not to be easy for the majority of managers and developers. Some of the factors are:
- Overconfidence in testing effectiveness. Many defects are found during testing, and a lot of time and money may have been sunk into tools that measure test coverage, and developing test cases that increase coverage. Having reached a test coverage of 80 percent of the statements, it is tempting to assume that you're finding 80 percent of the defects (which you aren't because you're covering only a fraction of the code paths, and an even tinier fraction of the combinations of values that the variables may have on these code paths). It is also tempting to think that you only have a little more to go to cover the remaining 20 percent of the code (which isn't true, because getting more coverage gets harder and harder).
- Overconfidence in testing tools. A related phenomenon is the belief that, since tools such as Purify and Insure++ are