December 2001 Feature Article

The Heart of a Tester’s Job
Part 3 - Requirements Management

The identified requirements may now be sorted into functional areas and allocated to test procedures. For example, in a project with incremental delivery, the login-logout test may precede the cashbook test.

The requirements management method (otherwise known as a requirements validation matrix) is particularly helpful when it comes to test progress and reporting. Close to the start of a project, say within a week of the specifications being delivered, this test planning method can start delivering extremely useful testing reports.

These reports can then be updated regularly based on the progressive updating of our requirements matrix.

Tables 2 and 3 illustrate a typical progression of requirements for functional area FUN-nnn.

In a financial system for example, we might report the statuses of Table 1 one week after the project specifications have been delivered.
Area
No of Requirements
Total and Average Risk
Total and Average Effort
Cash Book
213
520,
2.44
343,
1.61
General
Ledger
145
700,
4.82
464,
3.20
General Journal
52
313,
6.02
72.8,
1.40
Stock Inventory
12
32,
2.67
16.8,
1.40
Totals
422
1565,
3.29
896.6,
2.12

Table 1: Requirements Information Relating to Testing

The information of Table 1 quickly identifies that the general ledger will take more testing effort (and resources) than the cashbook to test, even though it has less requirements for test. The general journal has the highest average risk, and so it will benefit from having a more experienced tester assigned to testing it. The cashbook has a low risk rating and also a low average testing effort, making it ideal to assign to junior testing resources. A senior tester can check any high-risk areas within each of the financial packages.

Pie charts may be drawn to show the relative effort of testing each area in the system to be tested (refer to Figure 1 as an example) or the breakdown of risk within a function etc. (refer to Figure 2 as an example).



Figure 1: Average Testing Effort Per Functional Area in the Financial System

Figure 2: Cashbook Risk Breakdown


Table 2: Project 25% Complete


Table 3: Project 75% Complete

The project test progress planning and reporting can then be derived from the requirements spreadsheet. Referring to Figure 3, it can be seen that it is planned to begin writing test procedures half way through the first reporting period, and to complete these by half way through the project.

Figure 3: Project Test Planning and Progress Reporting

Running of the scripts is planned to start 25 percent into the project and to be completed by 75 percent of the project schedule. Notice that we have calculated the first failure rate of business requirements by reporting period four. If this is a 30 percent failure rate we could predict that in a project of 422 requirements, about 127 will need to be fixed before project delivery! If the average requirement takes 5 hours to repair, this will cost us 635 hours (or 4 months) maintenance before first project delivery!

Knowing the accurate (measured, and objective) testing and quality progress can help the test, project management, and development teams with planning and corrective actions during the project, rather than being surprised about 80 percent through the project.


Wayne Mallinson
<< November 2001
January 2002 >>