Testability

Why it matters

A requirement that no result can fail gives no basis for a verdict. Each person fills the gap with their own reading: the developer builds one behaviour, the tester checks another, the product owner expected a third. The difference surfaces late, as an argument about whether a defect is a defect, when changing the feature costs most.

Low system testability costs time and hides defects. If test data takes ten screens to create, a reminder can only be tested by waiting a day, or a failed request shows only "Something went wrong", tests become slow, get skipped or miss the cause. The ISTQB Foundation syllabus includes assessing the testability of the test basis in test analysis, so testers raise it in reviews and refinement, while change is still cheap.

What makes a requirement testable

A quick check: could you write the expected result of a test case from the requirement today, and would two testers give the same verdict on the same outcome? Three of the defects from the previous lesson, ambiguous, incomplete and contradictory requirements, fail this check; the fourth, a missing requirement, leaves nothing to check at all. A testable requirement is:

• Clear: it has one meaning. The actor, the trigger and the result are named, terms are defined, and each statement describes one behaviour. "The user can cancel an order" is unclear until you know which user, which order states and until when.
• Measurable: each quality word is replaced by an observable result (a message, a state, a stored record, a sent email) or by a target with a unit and conditions. The lesson on non-functional testing showed how to turn "fast" or "easy" into such a target.
• Consistent: it agrees with itself, with other requirements, business rules and the design, and uses the same name for the same thing. When two requirements disagree, every possible result fails one of them.

Testability of the system: controllability and observability

A clear requirement still cannot be tested if the system does not let you set up the situation or see the outcome. Two properties describe this. Controllability is how easily a test can put the system into the state it needs: create data, set the date, switch a feature on, make a payment provider decline. Observability is how easily a test can see what the system did, including results that never reach the screen: the stored record, the email sent, the log entry, the exact error.

Both are design decisions, and they are cheapest when asked for before the feature is built. ISO/IEC 25010:2023 places testability under maintainability: a product that is hard to test is also hard to change safely. Typical requests from testers:

• A way to create and reset test data (a seed script, an API or an admin screen).
• A clock or expiry setting that a test can control, for anything that expires or is scheduled.
• Sandbox (test) modes or test doubles, stand-ins that imitate a real service, for third-party services, so that a declined payment or a timeout can be produced on demand.
• Logs with a correlation id (one id that links every log entry for the same request), specific error codes, and the build version visible in the application.
• Stable identifiers for automation, such as a data-testid attribute that a test uses to find an element even when its text or layout changes.
• Confirmation that control hooks such as a data reset or a clock override are switched off outside test environments: a data-reset endpoint reachable in production is a defect in itself.

Try it: Mock API Response Generator

Rewriting an untestable requirement

A rewrite is a proposal, not a decision. The tester finds what is missing and suggests wording; the owner of the requirement, usually the product owner or a business analyst, decides the values and approves the text. Work in this order:

• Mark every word a test cannot check: quality adjectives (fast, easy, secure), vague amounts (some, large, reasonable), open lists (etc., such as) and weak verbs (support, handle, manage).
• Replace each one with an observable result or a target with a unit and conditions. Propose a value and mark it "to confirm".
• Split compound sentences so that each statement has one pass or fail verdict, and number the statements so that test cases can trace to them.
• Name the actor, the trigger, the preconditions and the error paths.
• Check the rewrite against related requirements and business rules, then note what you need to control and observe to test it.

Try it: AI Requirement Ambiguity Detector Try it: Acceptance Criteria Generator

Worked example: a subscription renewal requirement

A language-learning app sells monthly subscriptions. Its specification says: REQ-21 "Subscribers should be reminded in good time before their subscription renews. If the payment fails, it should be retried a few times before the subscription ends." A business rule says: BR-9 "A paused subscription is not charged."

Review: "in good time" and "a few times" are not measurable; "reminded" and "should" are not clear (by which channel, saying what, and is it mandatory?); and REQ-21 is silent about paused subscriptions, so it may contradict BR-9. The tester proposes the rewrite below, asks the product owner whether "ends" means cancelled or paused, and lists what the test environment must offer:

• A clock that the test environment can move forward, so that the reminder (21.1) and the retries (21.3) can be tested without waiting a week (controllability).
• The payment provider’s sandbox with test cards that are declined on demand, so that one, two or three declined attempts can be produced (controllability, 21.3).
• A capture inbox, so that the reminder and the cancellation email can be read without real mailboxes (observability, 21.1 and 21.3).
• Test data with an active and a paused subscription, and the sandbox list of charge attempts, to confirm that no fourth attempt is made and that the paused subscription is never charged (controllability and observability, 21.3 and 21.4).

REQ-21  Monthly renewal (proposed rewrite; values to be confirmed by the product owner)

21.1  7 days before the renewal date, the subscriber receives one email that states
      the renewal date, the amount and how to pause or cancel.
21.2  On the renewal date, the saved card is charged the price of the plan, and the
      subscription continues for one more month.
21.3  If the charge is declined, it is retried 1 day and 3 days after the renewal
      date. If all three attempts are declined, the subscription is cancelled and
      the subscriber receives an email saying so. No further charge is attempted.
21.4  A paused subscription receives no reminder and is not charged (BR-9).
21.5  Every charge attempt, accepted or declined, appears under "Billing history"
      with its date, amount and result.

Try it: Requirements → Test Cases Try it: AI Acceptance Criteria Reviewer

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.