With more critical business processes being implemented in software, quality problems are a primary business risk. Ill discuss five primary causes of poor software quality and how to mitigate their damaging effects using methods other than brute testing.
Over time they will learn more about the domain, but much of this learning will come through correcting defects caused by their mistaken understanding of the functional requirements. The best way to mitigate this cause is to provide access to domain experts from the business, proactively train developers in the business domain, and conduct peer reviews with those possessing more domain experience.
These tiers include user interface, business logic, and data management, and they may interact through middleware with enterprise resource systems and legacy applications written in archaic languages. Few developers know all of these languages and technologies, and their incorrect assumptions about how other technologies work is a prime source of the non-functional defects that cause damaging outages, data corruption, and security breaches during operation.
The best way to mitigate this cause is to cross-train developers in different application technologies, conduct peer reviews with developers working in other application tiers, and perform static and dynamic analyses of the code.
The few successful outcomes are based on heroics that are rarely repeated on future death marches. When working at breakneck pace, stressed developers make more mistakes and have less time to find them. The only way to mitigate these death march travesties is through enforcing strong project management practices. Controlling commitments through planning, tracking progress to identify problems, and controlling endless requirements changes are critical practices for providing a professional environment for software development.
Unnecessarily complex code is often impenetrable and modifying it leads to numerous mistakes and unanticipated negative side effects. These newly injected defects cause expensive rework and delayed releases. The best way to mitigate this cause is to re-factor critical portions of the code guided by information from architectural and static code analyses.
For various reasons, CMMI levels have not always guaranteed high quality software deliveries. To mitigate the risks of quality problems in externally supplied software, acquiring managers should implement quality targets in their contracts and a strong quality assurance gate for delivered software.
The first two causes distinguish between functional and non-functional quality problems, a critical distinction since non-functional defects are not detected as readily during test and their effects are frequently more devastating during operations.
The third and fourth causes have been perennial, although the fourth problem is exacerbated by the increase in technologies integrated into modern applications.
The final problem is not entirely new, but has grown in effect with growth in outsourcing and packaged software. Just missing this list but deserving of attention are breakdowns in coordination among distributed software teams, a cause that would make the top five in some environments.
In well run software organizations testing is not a defect detection activity. Rather, testing should merely verify that the software performs correctly under a wide range of operational conditions. By understanding and addressing the top five causes of defects, quality can be designed in from the start, substantially reducing both the 40% of project effort typically spent on rework and the risks to which software exposes business.
Dr. Bill Curtis is the SVP & Chief Scientist at CAST Software.