Nobody likes bugs. They're annoying, messy, unprofessional and embarrassing. Although, when it's someone else's bugs, I do find it amusing. I admit I love it when I see Google or Yahoo throw an error, and the best one yet was a 10ft high by 20ft wide video display in a New York City Sprint store that had a big empty black screen and this lovely message facing Broadway for everyone to see:
 
"Windows could not start because the following file is missing..."
 
So, what's the best way to catch these bugs (or defects) and eliminate them, before they become those irritating problems that frustrate end users? The general strategy needs to be test early and test often. But 'test' doesn't just mean the programmer completes development of the new feature, moves it to a testing site and then the QA team jumps on it and runs their tests. The idea is illustrated beautifully here, with a chart that I've become very fond of and used in an earlier post:
 

This chart, produced by Construx Software, shows the stages in the project where defects are introduced, and the cost of repairing defects at each stage of the project. The color scheme and curves remind me of flames, and if you think about it that way then the later you get in your project the bigger your fires get and the harder (and more expensive) they are to put out. The chart shows that most projects devote their resources to repairing defects at the very late stages of the project, in system test. Repairing defects at the system test stage, or the post launch stage is considerably more difficult and time consuming then if the defect were caught earlier in the project and repaired at that point. Part of the challenge of raising the level of quality and finding and reparing defects early is realizing the potential for defects to be introduced early. It's too easy to blame a bug on a programmer's bad code or missing code (not that the Flightpath programmers ever produce any bad code, that's a hypothetical software firm I am referring to), but what Quality Assurance engineers need to realize is that many defects can be created in the earliest stages of a project, before a programmer even gets involved. Designers and Technical Architects can make mistakes too (but of course Project Managers never make mistakes), and the more of those mistakes that can be caught, the healthier the project will be. Having grown up playing goalkeeper on my soccer team, I like to use an analogy from the game - everyone likes to blame the goalie when the team gets scored on, but people easily forget that there were 10 other people on the field that could have made mistakes before the ball got back to the net. Similar to many software project defects, they can be created anywhere along the process.

 
So, test early and test often:
 

• Review the requirements document with the customer, to confirm that all are on exactly the same page with the goals of the project
  
• Involve the QA engineers early on in the development of the specifications document and testing scripts, to verify that the requirements are met, and as many issues as possible are considered and properly handled
  

 
Frederick Brooks, in The Mythical Man Month, writes:
 
"Long before any code exists, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity. As [V.A.] Vyssotsky [of Bell Telephone Laboratories' Safeguard Project] says, the developers themselves cannot do this: 'They won't tell you they don't understand it; they will happily invent their way through the gaps and obscurities.' "
 
When the project is in the development stages, continue to test early and often:
 

• Incorporate regular programmer peer reviews of code and functionality
  
• Schedule feature reviews & tests whenever possible, for both programming team and QA engineers
  

Ideally if all of these steps are taken (and I'm sure there's much more that can be done that I haven't mentioned), then when the project is ready for system test many of the issues have already been identified and resolved. This is not to say that no defects will be found in system test, but hopefully many less than if these steps weren't taken.
 
A couple of things to keep in mind while in full system test:

• Test the pieces isolated and then test them together. If a piece passed an earlier feature review, test it again and don't just assume that it will work fine with the other pieces
  
• Test thoroughly within the mainline scenarios and don't forget to hit the edges and the outside, as Frederick Brooks writes in his book when discussing test cases for software:
  
  1. Mainline cases that test the program's chief functions for commonly encountered data (the most time will be spent here).
     
  2. Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work.
     
  3. Barely legitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.


• Once a defect has been fixed and verified in the test system, review all other areas tested and confirm they still work properly. This can be the most time consuming task, but critical. When this task can be automated, even better.

I'd be lying if I said that all of my projects launch bug free, but I am trying to incorporate more and more of these processes into my projects and will continue to strive to keep the bug count down.

Happy Bug Hunting!