AlanAbar.com

Requirements Based Testing (RBT)

Defect Prevention

Use of techniques and processes that can help detect and avoid errors before they propagate to later development phases
Most effective during requirements, or in SCRUM, at the beginning of Sprint, or even earlier than that!
Testers can help recognize omissions, discrepancies, ambiguities, and other projects that affect project requirement’s testability, correctness, and other qualities.

Preventation is Cheaper than Cure

Verify the Requirements

Setup “Quality Measures” for each requirement, to measure the quality of requirements defined.
All stakeholders responsible for requirements should verify hat requirements possess the following attributes:
- Correctness
- Completeness
- Consistency
- Testability (or verifiability)
- Feasibility
- Necessity
- Prioritization
- Unambiguousness
- Traceability

1 - Correctness

Correctness is judged based on what the user wants.
- Are the rules & regulations stated correctly?
- Does the requirement exactly reflect the user’s request?
- Are the standards being followed?
Imperative that End User or Representative is involved during the requirements discussions / gathering
Involving SQE in these discussions will be key

2 - Completeness

Completeness ensures that no necessary elements are missing from the requirement
Goal is to avoid omitting requirements simply because no one has asked the right questions
Testers should insist that associated nonfunctional requirements, such as Performance, Security, Usability, Compatibility, and Accessibility are described along w/ each func. requirement

3 - Consistency

Consistency verifies there are no internal or external contradictions among the elements within the work products, or between work products.
By asking the question “Does the specification define every essential subject matter term used within the specification?” we can determine whether the elements used in the req. are clear and precise.
Ex. The term “viewer” may mean different things in certain context.

4 – Testability (verifiability)

Confirms that it is possible to create a test for the requirement, and that an expected result is known and can be programmatically or visually verified
If a requirement cannot be tested or otherwise verified, this fact and its associated risks must be stated, and the requirement must be adjusted if possible so that it can be tested

5 - Feasibility

The feasibility of a requirement ensures that it can be implemented given the budget, schedules, technology, and other resources available

6 – Necessity

Necessity verifies that every requirement in the specification is relevant to the system.
To test for relevance or necessity, the tester checks the requirements against the stated goals for the system
Does this requirement contribute to the goals?
Would excluding this requirement prevent the system from meeting those goals?
Are any other requirements dependant on this requirement?
Some irrelevant requirements are not really requirements, but proposes solutions.

7 - Prioritization

This allows everyone to understand the relative value to stakeholders of the requirement
A simple scale from 1 to 5 can be used to specify the level of reward for good performance and penalty for bad performance on a req.
If a req. is absolutely vital to the success of the system, then it has a penalty of 5 and reward of 5. Overall value = 10
A req. that would be nice to have but is not really vital might have a penalty of 1 and reward of 3. Overall value = 4
This approach needs to balance the perspective of the user against the cost and technical risk associated with a proposed requirement.

8 – Unambiguousness

Ensures that requirements are stated in a precise and measurable way.
Example: “The system must respond quickly to customer inquiries”.
“Quickly” is innately ambiguous and subjective, and therefore renders the req. as untestable.
A customer might thing 5 secs is quick, while a developer might think within 3 minutes is okay.
Requirements should be specific.

9 - Traceability

Ensures that each requirement is identified in such a way that is can be associated with all parts of the system where it is used.
For any change to requirements, is it possible to identify all parts of the system where this change has an effect?
Each requirement should be considered as a separately identifiable, measurable entity.

Summary

As soon as a single requirement is available for review, it is possible to start testing that requirement for the characteristics discussed
Trapping requirements-related defects as early as they can be identified will prevent incorrect requirements from being incorporated in the design and implementation, where they will be more difficult and expensive to find and correct

What Can SQE Team Do Early?

Active Participation in SCRUM Meetings / Attendance to Daily Standup Meetings
Understanding Team Member’s Roles and Responsibilities, working close w/ Team to build Rapport.
Identifying End Users and building a bridge to understand their perspective & needs
Understanding the Sprint Backlog / Contents
Test Planning / Developing Testing Strategy
Capturing and Understanding Project Requirements
Quality Measurements of Requirements / Requirements Based Testing.
Testing requirements for key attributes discussed.
Identifying Testing Requirements / Creating Test Specifications
Identifying Impacted Applications, and Integration points
Test Case development / Test Case Reviews
Identifying any Automation scripts to be implemented
Determining any Performance Requirements, and planning for that
Filing Bugs during Dev & IDE Phase
Sharing and Communicating Impacts to SQE Team, and involving other Leads when required for testing
Executing test cases in DEV environment if applicable, to get a head start!