Requirements-Driven Quality Management Takes Discipline

June 16, 2015

ALI, ALM: HP ALM, ALM: Quality Assurance Best Practice, Performance Testing

Requirements-Driven Quality Management Takes Discipline

By: Matt Angerer

Whether your organization is completely new to testing or you’re just looking to improve testing organization, it is essential to develop an understanding of associated risks. By making critical testing decisions earlier in the development lifecycle, your organization gains the ability to reduce risk while improving product quality. Most software defects are introduced early in the development cycle. Unfortunately, such defects are typically found much later, which can affect costs, delivery times, and even overall product quality.

According to the National Institute of Standards and Technology (NSIT), 70% of software defects are introduced in the requirements phase. The same study indicates that the cost to fix a defect after delivery is 100 times more than in the requirements definition or design phase. Of course, this statistic takes into account the impact a bug has on your business operations if released into your live productive environment without detection. But also consider the haste in trying to fix this “urgent incident” after it’s detected by one of your end users. Often times, your development team is rushed to “band-aid” the defect to ensure continuity of business operations, thus introducing more complexity into your code base.

Utopia on earth would be the detection of defects in the Requirement and Design phase of your project. After all, according to many studies, that is where most of your defects are introduced into the system delivery lifecycle. NSIT published the bar charts below, showing where the ‘Introduction of Defects’ typically occurs in your system delivery lifecycle vs. where the ‘Detection of defects’ usually occurs. Powerful application lifecycle management (ALM) tools like HP Quality Center and ALM are beginning to change this historical evidence.

Assessing Relevant Cost

Clearly, there is a strong need for collaboration, as well as clear requirement-driven quality management throughout the duration of the application lifecycle. In order to succeed, your requirements driven quality management discipline must be, well… disciplined. The process of managing requirements throughout development, testing, and release requires leadership and teamwork. In order to ensure that all requirements are met, we recommend that business analysts follow these tenets:

Define all requirements, including those that might be less than clear
Determine the business value for all relevant requirements
Quantify the amount of risk related to all requirements
Understand related and dependent elements for all requirements

As a Test Manager, you should always ask yourself the following questions for each requirement:

Are the project requirements realistic?
Can the requirements be verified?
How will the requirements be implemented and tested?
How can risk be reduced through testing resources?

Taking a Disciplined Approach to Requirement Driven Testing

Before risk-based testing can be implemented, it is important to determine whether such integration is even beneficial and feasible. This requires comparing the estimated resources of the project with the performance of risk management to determine whether such testing even makes sense. It is also important to define a testing integration schedule, while making sure to allocate the necessary resources. You’ll have to identify relevant risk items and important stakeholders who should be involved in the testing and evaluation process.

There is no “cure all” approach to your software quality and testing woes, but when properly implemented, risk-based testing provides the potential for improved software development and optimized resource allocation… if you have the discipline!