Requirements: turning a wish into a testable statement
Requests such as fast, fair or easy need agreed checks. A testable requirement states the expected behaviour or quality and the conditions for checking it. Requirements also record the system's scope and exclusions.
What a learner can do afterwards
- Identify an observable pass criterion and the missing details in a vague requirement
- Separate functional requirements from qualities such as speed or availability
- Choose how to review a requirement with no linked need against the agreed release scope
1 · Read
A testable requirement gives the team an agreed way to check an expected result. For 'make checkout easy', ask which users and task matter, then agree the pass criterion and test conditions. For 'handle many active users quickly', agree the active-user count and response-time limit. A requirement can refer to a recorded test plan for details.
For a search page, plan S fixes the browser, network profile, dataset and 20 test queries. The requirement says: for every query in plan S, all results must be displayed within three seconds of selecting Search. Measure from that selection until all results appear. Each trial passes at three seconds or less and fails above three seconds.
Functional requirements state what the system does, such as returning catalog titles that match search text. Quality requirements state a quality of that service, such as its response time or availability. Record both: correct results do not establish acceptable speed, and speed does not establish correct results.
Some checks need no numbers. For a query known to match no records, a tester can compare the displayed message with the agreed wording. The requirement or its referenced test plan must provide enough information to decide whether the observed result meets the criterion.
A check can include human review with agreed criteria. Suppose a shop requires each product photo to have a text alternative naming the pictured product. Review the words against the photo. A filled field alone does not meet that requirement. This one check does not establish that the whole site is accessible.
Review requirements for conflicts under the same conditions. If two rules set different maximum loan counts for the same guest group at the same time, the team must resolve the limit. Rules for different groups or circumstances may differ without conflicting.
State scope and its reason: 'This release supports borrowing, not online sales, to avoid payment work.' Link requirements to needs, such as user tasks or applicable obligations. Review missing links with stakeholders. For a valid requirement within scope, recording its existing need or repairing its link may be enough. Remove an unsupported proposal. If a justified requirement falls outside scope, agree whether to defer it or change the release scope.
Agree the expected result, check and conditions. Record functions, qualities and scope. Resolve conflicts and review requirements with no linked need.
Lesson, questions and flashcards written for this dataset. Software-engineering textbook records were consulted for concepts; their prose and figures are not reproduced.
The four readings and supporting flashcards were written for this dataset. Textbook records were consulted for concepts; no textbook or library prose is reproduced.
More to read
A requirement and its test plan
A request can identify a real need while leaving its acceptance check unfinished. When someone asks for faster search, ask what they need to complete and which delays matter to them. Agree a criterion rather than choosing a limit without discussion.
For a timing check, record the starting event and the event that stops the timer. Also record the queries, data and environment used in the check. Different data or network conditions can change the result, so an undefined home connection is not a reproducible test setup.
The requirement can refer to a test plan that holds these details. Before testing, check that the reference exists and that the team agrees which version to use. Two testers following the same plan should be applying the same acceptance rule, even if their measured results differ.
Checking a function and its qualities
Consider a catalog search. One requirement can state that entering a title fragment returns the catalog titles that match it. That describes a function. Another requirement can set a response-time limit under an agreed test plan. That describes a quality of the service.
These requirements need different checks. To check matching, use catalog data for which the expected titles are known. Compare the actual results with those expected titles. To check response time, measure between the agreed start and end events under the specified conditions.
A quick response can contain incorrect results. Correct results can arrive too late. Passing one check therefore does not establish that the other requirement is met.
Numeric limits are useful for some qualities, but verification does not always require a number. An agreed message for a search with no matches can be checked by comparing its wording with the required message.
Reviewing limits, needs and release scope
A release boundary helps a team decide which work belongs in the current version. Record an exclusion with its reason. A borrowing service might exclude online sales from its first release because sales would add payment integration work. This decision does not forbid sales in every future release.
When comparing rules, compare their conditions as well as their outcomes. Different loan limits for guests and staff may be consistent. Different maximums for the same guests at the same time need clarification.
Link each requirement to a need. That need may come from a user task or an applicable obligation, rather than from a direct feature request. A missing link calls for review. If a valid requirement already fits the agreed scope, record its existing need or repair the link. The requirement and scope can stay unchanged.
Remove an unsupported proposal. If a justified requirement falls outside the current release boundary, agree whether to defer it or change the release scope. A missing link alone does not settle either decision.
Checking what a text alternative says
Suppose a shop agrees that each product photo in checkout must have a text alternative naming the pictured product. This is a specific project requirement. It gives a reviewer both the objects to inspect and a criterion for deciding whether they meet it.
A check that looks only for a filled text field does not test the full requirement. A field could contain unrelated words or the name of a different product. The reviewer needs to compare the alternative with the photo and check whether it identifies the pictured product.
Human review can be part of verification when the criteria are agreed. Record the pages and photos covered by the check so the review has a defined scope.
Passing this product-photo check does not establish that the whole checkout or site is accessible. Any broader accessibility claim needs its own stated scope, criteria and verification.
2 · Watch
به انگلیسیTake it off screen
Where it sits
Learn first
Nothing; this is a starting point.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.