Finding Bugs: No Pain, No
by Pat Craig
From the Fall 1996 issue of the Complexity Management Chronicles
Our last newsletter detailed three reasons that cause staff turnover. Staff losses can
result in software delays and reduced creative capacity. The reasons for staff losses,
cited previously, were:
- Snowballing employee resignations caused by managers who push too hard,
- Shoddy work being shoved from stage to stage in the system development life cycle,
- Balance of power wars between Development and Test.
Wars: In this newsletter we would like to touch upon the balance of power wars
and offer some client tested solutions. We have witnessed some particularly ugly conflicts
revolving around QA¹s role as the institutionalized defender of quality. In one case, a
key tester quit the firm rather than succumb to pressure and lie about the status of an
important bug. In another case, two developers regarded a tester's bug reports as a
personal affront and they retaliated by attacking her professionalism. She was unjustly
put on probation and subsequently resigned. This newsletter also details how a client
solved their Development/QA wars after an important developer and an outstanding tester,
embroiled in a bitter dispute about recording bugs, both quit their jobs within days of
Minimizing Rework Lowers Costs (and Conflict): Coincident with these staff
losses, the President hired a new Development VP. The VP knew about QAI published data
demonstrating that the cost to remove defects increases exponentially throughout the life
cycle. (In February 1994 QAI quoted defect correction costs ranging from less than $10 per
bug to more than $1,000. Costs were strongly correlated with when bugs are found.) Rework
is expensive. The further downstream in the development cycle bugs are found, the more
they cost to correct. To reduce development costs the VP and his staff implemented many
techniques to discover the bugs earlier "upstream" while still in the
requirements, detailed design or coding phases. The added benefit of discovering bugs
earlier was less conflict between Development and Test.
Group Walkthroughs Ensure Deadlines Met: In the 1987 IEEE Transactions on
Software Engineering, the computer scientists V. Basili, R. Selby, and F. Baker published
bug removal research results. Their research assessed the merit of "testless"
testing techniques: code reading, inspection, and group walkthroughs. They had
experimental groups of developers using "testless" techniques only. To ensure
scientific validity, they also had control groups using traditional methods. The study
affirmed "testless" techniques. A full 100% of the experimental teams met their
deliverable dates, while only 40% of the control groups did as well. (The IBM Systems
Journal, Vol. 29, No 1, 1990, authors Mays et al. also discusses the value of these
The VP used the Basili study to drive home his statement, "Software development is
tough. We are going to make it a part of our corporate culture that developers enlist
their friends on bug finding missions." Group walkthroughs became the norm.
"Zero Defects" to Test Mean Less Bugs Installed: Dave Moore, Development
Director for Microsoft writes in S. Maguire's book "Writing Solid Code" that
test groups can only find about 60% of all bugs. To ship cleaner code Microsoft has made
Development responsible for turning over zero defect code to Test. Microsoft still has a
test group and beta tests, to catch what Development misses.
We hope this brief review of bug discovery ideas will help minimize conflict between
your Development and Test groups.
©Complexity Management 1996
Located in Metropolitan Boston
Complexity Management Chronicles, a newsletter for software quality assurance
professionals, is published in print form four times a year. Send your name and snail-mail
address to the e-mail address below if you would like to be on the mailing list - at no
cost to USA mailing addresses.
Return to Complexity Management Home
Contact Pat Craig at email@example.com .