Nine Ways to Prevent Defects

As a quick treat for today, here’s a list of nine useful ways to prevent defects in applications.

  1. Pair Programming and Testing: Two heads are better than one when writing software. Pairing enables programmers to discuss and react to potential defects as the code is being written. By combining their experience, the programmers are more likely to recognize a problem situation or an opportunity for a new test.
  2. Test Driven Development (TDD): Creating tests and code in tandem results in substantially higher test coverage. TDD also helps evolve the code into smaller, more flexible modules.
  3. Code Reviews: Pair Programming is one method of on-the-fly code review. Additional code reviews can be useful for knowledge sharing and defect prevention. This can be accomplished through on- or off-line code reviews, or by changing who you pair with throughout an iteration. I prefer to change who I work with throughout an iteration as it provides the opportunity to learn not just what others are working on, but how they approach problem solving.
  4. Static Analysis: Static analysis tools automatically look for common defects by reading the code (instead of executing the code). Some defects are easier to find through static analysis than by testing (and vice-versus).
  5. Stop-The-Line Mindset: The stop-the-line mindset says that once a defect is discovered, new production stops until the defect is understood, corrected and prevented from ever happening again. This involves creating tests around the fix, looking for similar problems in the application code and asking how this defect could be prevented in the future.
  6. Exploratory Testing: Exploratory testing is not “random, hacking around in the system hoping to find a bug”. Instead, it is a process through which the tester maps the behavior of the system utilizing heuristics, knowledge of the system and intuition to discover both defects and opportunities for new features.
  7. Risk Analysis: We want to look for areas where the code is most likely to have defects. There are several questions I consider when deciding where to look for defects:
    1. What parts of the code are being updated for frequently for defects? Defects like to hang out together. If you find one, you’ll probably find several more. If there are areas of the code that are constantly being patched, these areas should get immediate attention.
    2. What parts of the code are most complex? Complex code is a nesting ground for defects. It is harder to read, harder to test, and harder to make changes. Using a complexity metric can help identify risky areas.
    3. What parts of the code are not currently well tested? Untested parts of the code are likely to have defects.
  8. Duplicate Code Detection: Duplicated code makes changes more difficult and defects more likely because it raises questions such as: “Are there any other places where I need to make this same change?”, “Is this change appropriate in all places that have this same code?”. Development teams will often forget or be unaware of all the places a change needs to be made. Tools exist for detecting duplicate code in many languages.
  9. Continuous Integration: Building the entire code base and executing test suites on a frequent basis makes it harder to ignore or forget a defect.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  


*