Introduction to Requirement Driven Testing Approach for Agile and Waterfall Methodology

Software testing is a process of finding defects to ensure that the system being developed meets the requirements. In most cases it is likely that some of the requirements are changed or become obsolete. Therefore it is very important to always work from requirement to select which test to execute. Quite often not all test cases are up to date. Working from requirement will ensure that the they are reviewed regularly. Existing requirement and test cases may be updated, removed or added during each review. Requirement Driven Testing (RDT) is project methodology independent test approach that can be used in any project methodologies such as the Waterfall, Agile and SCRUM and focusses on the following:

1. Building business requirement list;
2. Requirement is used to select test case (s) and;
3. Report pass / fail on business requirements.

Building Requirement List

As the name suggests, RDT work is around building and refining requirements. The process continues through the project life cycle involving everyone in the team especially project owner, subject matter experts and / or application vendors.

RDT's success is based on the fact that without well defined and testable requirements, test executions became subjective and are based on unsubstantiated assumptions

Having an up to date and testable list of requirements will make testing process much easier and productive. It is important to keep reviewing existing requirement especially during the following activities:

1. Executing tests
2. Creating defects
3. Regression testing
4. Reviewing business requirement documentation
5. Retesting defects

Requirement is used to select test case (s) to execute

In most cases, the number of requirements will grow over time but it does not mean that the time required for testing will increase the same way. Priority classifications (High, Medium, Low) will be used to select what to test first and to manage time effectively. The priority classification also changes throughout the project life cycle as what is currently critical might not be the same in the following iteration (s). The classification can also change when defects are detected during testing.

Although it is not mandatory, in general RDT follows the following guidelines:

1. Each scenario should have at least one business requirement
2. Each business requirement should have at least one test case
3. A test case can be derived from business scenario
4. Each defect should have one requirement and test case
5. Each business requirement should have priority classification
6. Each defect should have severity classification
7. A separate test case should be created for each scenario

Report on Business Requirements

Closely coupled with the RDT approach is reporting on requirements. It focuses on providing up-to-date test results, test progress, test statistics in requirement term. The test reports can be as simple as manual update excel worksheet to a real-time online reports.

Imagine a business owner wants to know the progress of the software being developed, it makes more sense if there are 10 out of 100 requirements still not tested than 10 out of 100 test cases not tested. In other words, RDT emphasis on the "what" factor rather than the "how" factor.

The quality of reports depends on the quality of inputs that have been provided. It is very important to plan what information is to be included to produce different reports. Some of the useful reports for monitoring and managing progress are:

1. How many requirements without test case
2. How many test cases without requirement
3. How mane defects created without requirement and / or test case
4. How many scenarios without requirement


RDT is a test approach that focuses on building requirement list, use the list to prioritize test execution to manage time efficiently and report on requirement status. RDT is project methodology independent and can be used in Waterfall, Agile or SCRUM project methods.

Source by Patrick S Rusli