Chapter 5. Defect Prevention


A focus on defect prevention over defect detection is an important principle of sustainable development. Defect detection follows what is probably the most common method used today to develop software: the code-then-fix mindset, where features are developed, testing is done (by users, a testing group, or Quality Assurance), and then defects are fixed. In this approach, there is a noticeable time lag between when defects are introduced and when they are actually fixed. Defect prevention by contrast follows the code-then-fix mindset, where features are developed using automated tests and related practices that catch the vast majority of defects when they are introduced so they can be fixed immediately when it is cheapest to do so. A profile that illustrates the difference between a defect prevention culture and a defect detection culture is shown in Figure 5-1.

Figure 5-1. In a culture predominantly oriented around defect detection (left), the main burden for finding defects is placed on a quality assurance (or testing) organization, and quite a few defects are shipped to customers. However, in a defect prevention culture (right) the largest numbers of defects are found at the earliest possible moment, before the product reaches quality assurance, and very few defects. are shipped to customers.


Cheaper or Easier?

I've had some developers tell me, "It's cheaper to fix defects after they're found than it is to prevent them." These developers are deluding themselves and confusing cheaper with easier: It certainly seems easier to concentrate on getting features out the door, then worrying about fixing them up later. But what these people miss is that customers find many of the defects, and that is extremely expensive for your company and for your customers. Even more important, however, is that having to fix defects later causes the team to lose control of the project, and this loss of control directly impacts the ability to be agile.

Defect prevention in a chemical manufacturing plant is taking the pumps offline periodically to perform preventive maintenance. Pumps that are regularly maintained are less prone to breaking down, and by pro-actively maintaining their equipment, the plant employees are able to avoid running from one crisis to another. They are in control of the situation, not victims of circumstance. A defect prevention mindset in software development should also result in being more in control than purely responding to events.

Defect prevention has real return on investment. Let's assume that the same number of design and coding errors are produced in a defect detection and prevention culture. In a defect detection culture, the majority of defects are found through manual testing and after code has been integrated into the product. On the other hand, in a defect prevention culture, the emphasis is on finding defects before integration into the product. The predominance of low-value manual testing and elaborate defect tracking systems in defect detection have a very real cost, as does the fact that there is a time delay between when a defect is introduced and when it is fixed. By contrast, in a defect prevention environment, the result of thorough automated testing, high-value manual testing, and fewer defects that reach customers more than offsets the cost of spending extra time in team collaboration and writing automated tests. An elaborate financial model could be developed, but hopefully a quick mental exercise should do.


Unfortunately, most software organizations emphasize defect detection and do very little in the way of defect prevention. There are some obvious symptoms of a defect detection oriented culture:

  • Developers rely on testers/Quality Assurance/users to find defects in their products. Developers work on the software for a while, then they "toss it over the wall" to testers/QA, who toss it back when problems are found.

  • A noticeable number of regressions are found by people (users or QA), where features that already existed stop working as expected when new changes are made. Regressions are a strong indicator that there is not enough testing and also that the product may need refactoring due to unexpected interdependencies, another indicator of technical debt.

  • People believe that many tasks, including testing, are "beneath" highly paid programmers and are best done by lower paid help, so the developers can work on features (i.e., write code). While the features get done in the short term, the products these people work on get on the unsustainable development curve and quickly become more expensive to maintain and enhance over time.

  • A backlog of defects that is carried over from release to release of the product. Defect backlogs are an indicator that technical debt is accumulating in the product, and they should be avoided at all costs. Once a team is faced with a backlog, the ongoing pressures to develop more features mean that the backlog is going to stay and will almost always continue to grow.

  • Project team members spend inordinate amounts of time prioritizing, sorting, and viewing defect-related information. Defect backlogs are a huge drain on the time available to a project team. The less time spent doing the administrative chores in defect tracking, the better.

  • An emphasis on the importance of bug tracking tools as strategic tools. Bug tracking tools are important, but they aren't strategic to your success. There are plenty of perfectly adequate systems available.

Another way to look at the type of culture is to ask your team the following question:

How would you prefer to find out about a serious defect?

  1. From your customer.

  2. From your QA department.

  3. Find it yourself.

In a defect prevention culture, your answer would be (c); in a defect detection culture it would be (b), with (a) as an outcome . . .

In a defect detection culture, developers have abdicated the responsibility of testing and product quality to other groups, usually QA. This is wrong, because developers control the processes and practices used to produce the product and because control is essential to agility.

The primary difference between a defect detection and defect prevention culture is the attitude of developers and management toward testing (once again, mindset). Developers must be expected to do everything in their power to prevent defects and to catch them before the software reaches QA and customers. It should be a point of pride that customers do not encounter defects and that defects found by QA are fixed as rapidly as possible. This does not mean that developers spend the bulk of their time doing manual testing, but it does mean that developers need to look at the task of software development as more than just writing code. The practices in this chapter are intended to help build a defect prevention culture, which is an important part of developing a professional attitude to software development.




Sustainable Software Development. An Agile Perspective
Sustainable Software Development: An Agile Perspective
ISBN: 0321286081
EAN: 2147483647
Year: 2005
Pages: 125
Authors: Kevin Tate

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net