Experts in the software industry have tried everything from new project development lifecycle methodologies, such as Agile, to the latest whiz-bang test and Dev tools that promise greater productivity and suggest a “bug free release.” While many new lifecycle processes and tools can help a project, there are many core fundamental techniques and tools that a Dev/QA team must have in place to improve the chances of shipping a high-quality product or service and employ ways of reducing software defects.
Whether your team is using a waterfall based SDLC or variation, Agile, XP, a mix of both, or something else, it’s a guarantee that the later in the development lifecycle that defects are found, the more costly they will be to resolve. This cost will come in the number of hours required to redesign, the number of people needed to resolve, or the amount of intra-team involvement required to fix. The earlier in the process that bugs are found, no make that the earliest that bugs can be designed-out of a product so they are never introduced in the first place, the less costly they will be to the team.
In recent years developers have been performing more formal requirements, design, and code reviews as part of standard development protocol. In the past, most developers would start writing code and crank out the software to the team to review. It’s been statistically shown that early formal inspections of requirements and design before a project has started or at the onset of a project will increase your success rate of releasing high-quality software. According to Capers Jones, an expert in software design methodology, the requirements phase can have a defect potential of 1.00 per function point on average. This means that for every function point you can expect on average to find one defect originating from the project’s requirements. Since requirements are gathered at the front end of a project it is again typically the least costly place to resolve issues. Putting this in pragmatic terms, this means that you must institute some type of formal requirements review at the beginning of the SDLC and that you had best have not only the project management team and development team on board, but also include the QA team and the QA engineering team if you have one.
Next in importance at resolving defects comes the design phase of a project. Capers Jones rates the defect potential of design at 1.25 defects per function point. Design is actually not only the job of the “design” team, but should also involve core team members across the software development domain, and even include some key management. Yes, I did say management. There’s always something to be learned towards improving a product’s design that even the best software designers or usability engineers can miss. For quite some time I was involved in usability testing of the Norton Utilities for Macintosh. I was well versed in Apple Human Interface Guidelines – the tome that represented Apple’s definition on how usability should be designed into a software product and I was also a big proponent of the book, “The Design of Everyday Things,” by Donald Norman. I soon came to realize that almost everybody has something to contribute to the design phase of a software project, hence why usability lab testing is often so important. You’re bringing the public in to test potential designs and you’ll quickly see them do things that you could in no way have envisioned. The things you’ll learn will often be taken back to the design team and can change original product designs considerably.
Third on the list, in fact the area that has the most potential for introducing defects is the coding phase of the project. Capers Jones says that there are 1.75 defects for each function point introduced during the coding phase. Okay, so you’re undoubtedly wondering how can I reduce the number of bugs in the coding phase.
In our next article we’ll go into the processes, tools, and systems you must have in place for an effective QA coding phase that will reduce the number of bugs in your product.
Source: Software Productivity Research, LLC; “Software Quality in 2008: A Survey of the State of the Art.” Capers Jones