The Heart of a Tester’s Job

Requirements Management for Testing

The heart of a testers job is to take the specified requirements for a system and to ensure that each and every requirement is delivered and is working correctly. To do this, experienced testers use requirements management, a powerful testing technique that is simple to learn and implement.

Application of the technique greatly enhances test planning, design, execution and reporting. Accurate indications of test effort can be completed within the requirements phase of a project. It is therefore possible to derive good budget, schedule, and staffing estimates for testing at an early stage of a project.

Requirements Management ensures that testable requirements within a specification are identified, marked, and enumerated. These same requirements are then analysed for risk, test effort, and logical test-scenario grouping, using spreadsheet sorting and arithmetic functionality.

The progressive test status of individual or aggregate requirements is monitored and reported on, throughout the project, to provide an accurate and objective measure of test progress.

Requirements Management is key to planning that caters for organised and systematic testing. The initial written existence and quality of requirements is very important for testing, as each test action ought to have a known system response that will either pass or fail under test execution. Take as an example the user requirement for a coffee maker to be made. That in itself directs the production and test teams to what is required, but obviously there are questions such as colour, size, electrical or not, etc. that have to be answered before one can even begin to manufacture OR test this article.

It often happens that products are delivered which do not suit the user's needs because of fundamental differences in perception about the actual user requirements. Obtaining the user's requirements is usually the role of the business analyst, but the testing team need to understand how crucial the requirements are at the early stages of test planning to ensure user satisfaction upon delivery.
Pre-requisites of requirements management:

• The requirements need to exist - they have to be available
• The requirements need to be written down - If they are not in a written form, they need to be documented first, to ensure consistency.
• They need to be of a reasonable quality - preferably the requirements should have exited an Inspection process.
• The requirements need to be in context - the context clarifies each requirement.
• The requirements need to be subject to Configuration control - requirements change, and it is necessary to know which version of requirements is being dealt with.

A TYPICAL SPECIFICATION DOCUMENT

Figure 1 depicts a typical specification document, and common elements for expressing requirements, elements such as sentences, charts, equations and tables. Requirements Management techniques may be practised upon user requirements specifications, system specifications, and/or software specifications.

From a testing viewpoint, each requirement should define a logical testable entity. Each purported requirement must be practically possible to test within the constraints of a project. If it is not possible to conceive a practical test for a requirement then the requirement ought to be deleted or modified, or elevated to all project personnel as a potential system risk.

IDENTIFY AND DELINEATE REQUIREMENTS

Step 1:
Read the specification through twice. The first time just to get an overview of what it contains, and to get the bigger picture in context.

Step2:
Delineate each (testable) requirement in the specification document with square brackets [ ] and in pencil. Ensure that each delineated requirement is in fact, testable.

What is the right size for a requirement? Technically speaking, one could put a square bracket at the beginning of the specification document, and close it off at the end!

This would give one huge requirement for the whole specification to be tested at once. Practically speaking, this would not make it easy to systematically test the details of the specification
thus delineated.

To better understand the sizing of requirements, the analogy of chewing food is helpful. It is a very personal action, and although bite-size may vary, yet no one puts a whole steak into their mouths at once (nor a whole cabbage if you're a
vegetarian).

Large requirements have the result that if any component of them fails, the whole requirement keeps a failed status ...

There are trade-offs on either side. One should not end up with too many small requirements (as this will increase the administrative overhead). Large requirements have the result that if any component of them fails, the whole requirement keeps a failed status, as well as the fact that test detail may be lost if too much is considered at once.

Who does the first round of requirement identification and delineation?: This is an ideal function to pass on to the junior members of the team. A supervisor can then discuss the partitioning, and either refine or combine or change to the requirements as identified. This enhances the mentor relationship and gives a training opportunity as the delineation of requirements is discussed. It helps both the supervisor and junior testers to familiarise themselves with the material being examined from a testing point of view and is also likely to free the time of the senior to some extent.

Remember, like chewing, the correct sizing of requirements is a subjective exercise, and there are no 100 percent correct answers! As actual testing experience grows, the delineation of requirements will improve.

Step 3:
Sequentially number the requirements. The business area or business sub-function name can be used to build an acronym to aid the unique identification of each requirement e.g. FUN-001, FUN-002 etc.

Next month in Test Focus, we will group, organise, divide, process, and generally slice and dice these requirements for test, in the most systematic of ways.

Wayne Mallinson

<< September 2001

November 2001 >>