Why isn’t Everyone Using Inspections
Inspections provide significant benefit, why has adoption been so slow? Why is
not all of the software community using the method? The publicly published data
twenty-four years ago clearly demonstrated their effectiveness, and recent
reports continue to demonstrate their effectiveness. Why have Inspections not
taken a firmer root and achieved wider use?
reasons for this vary. I believe this is partially due to views that
Inspections can only be done one way. This book will eliminate at least some of
this misunderstanding. Another reason for the resistance to Inspections is the
view that they are not easy to do well. There are factors, including social and
psychological, that we must consider. Management often views Inspections as an
added cost, when in fact Inspections will reduce costs during a project. We
will see throughout this book how Inspections save both cost and time.
the inception of Inspections, with the advent of each new development tool or
language, the providers and users seem to believe that Inspections do not add
value or are less necessary. This is clearly not true, since programmers still
make defects with these tools and languages. However there often is little
documentation as to how well Inspections work in these new environments, so a
false belief that Inspections do not apply may be propagated by myth. We will see later in the book that Inspections do apply in these
development environments also.
of these and other factors, shortcuts in the Inspection process have been taken
without any proof that the change is an improvement. Some of these home grown
changes cause the Inspection process to be less effective. In turn the value of
what was defined as the Inspection process is diminished. Thus failure becomes
a self-proving “fact.”
may not be the most enjoyable engineering task compared to designing and
coding. Also, programmers are very possessive about artifacts they create.
Inspections are labour intensive and low tech, but they do work.
. Can Inspections Replace Test?
Inspections are low tech, labour intensive,
and rarely fun. These among other factors cause people to question the value of
Inspections. A frequent challenge is put forward that some form of testing;
i.e., unit test, will be just as effective and efficient or that Inspection
cannot catch all defects.
previously discussed that the solution for a defect is usually evident when it
is found during an Inspection, thus the costs for repair are minimized. Tests
after unit test do not make readily identifiable the area requiring repair and
thus the costs increase. The countless attempts to prove that unit test is more
efficient have failed and I know of no study that has been repeated where unit
test has been demonstrated to be as effective as Inspections in removing
is accepted that Inspections have value, the next challenge voiced about
Inspections is that unit test in combination with code Inspections will lead to
better results. Again, every trial I know of has failed in this regard. Russell
RUS91 gives two other reasons for not testing before Inspections:
As Inspections require a motivated team, testing first may lead to
a view that the code is reasonably stable and the team will be less motivated
to perform the best Inspection.
With the investment of test the Producer may be less receptive to
major rework on an “already-stable program image” which will also
found that the savings from defect detection costs in Inspections was 2.2 hours
compared to 4.5 hours in unit test. A two to one savings is a good place to
bank. In another organization he states a 1.4 to 8.5 staff hour relationship in
finding defects with Inspections versus testing. ACK89
WEL93 states that there are disadvantages of inspecting after unit test:
Unit test leads programmers to have
false confidence that the product works, so why inspectIt is a hard decision to inspect a
large batch that has been unit tested and there may be the view that there
is no longer time to inspect
gives reasons to perform Inspections first:
You may actually be able to bypass unit
test if the Inspection results are goodYou can recover earlier with lower cost
to serious design defects found in Inspections versus unit test
this (and other) clear evidence, to this day many will suggest that unit test
should be done before Inspections. Always this has proven to be less efficient.
When I run into people who are hard to convince, I suggest that they try a
simple experiment to see what the data tells them. I remain fully objective and
state, “If the data proves that unit test before a code inspection is cost
effective, then by all means proceed.” Twenty-eight years of requests and
I have not been given proof that unit test is less costly. This does not mean
the experiments should never be tried again. I discuss more on this in Chapter
14. For now I’ll leave the door open suggesting that as technology evolves, so
too might the best way to remove defects.
Inspections Ever Become Obsolete?
I hope so. I believe a clear possibility exists for Low-level design and code,
but not for all work products. The highest cost for Inspections is in Low-level
design, and code, so a reduction in these areas is a good contribution to
reducing COQ. I suspect that for requirements and key design documents we will
need Inspections for quite some time. For other artifacts such as plans, test
cases, documents, I think we will see a reduction in a need for Inspections as
we improve the disciplines of the activities for creating these work products
through training, processes, and tools.
focus we should take is that when an Inspection finds too many defects, this is
a signal to management to do a better job of managing the software processes
and people resources.
Inspections should be chosen?
is the main problem? Why do we have to need Inspections? We need Inspections to
remove software defects due to different reasons like at reduce cost etc. As we
know to remove defects at very early stage in the Software’s Development Life
Cycles are very cheaper than later in the SDLC. It must keep in mind one thing;
it is not a way to prevent defects from occurring.