Software QA / Basic: reasoning and test design / Lesson 2
Requirements, acceptance, and testability
Replace ambiguous wishes with examples, observable results, and explicit assumptions. Design testability into a course enrollment feature before implementation makes uncertainty expensive.
On this page
Lesson goals
- Review requirements for missing decisions and contradictions.
- Create acceptance examples and a traceability chain.
- Explain controllability and observability.
Find decisions hidden by adjectives
“Enrollment should be fast and user friendly” gives no reliable pass condition. Ask which users, which action, under what workload, and what outcome matters. Split functional behavior from quality constraints: one learner may hold one active enrollment per course; a successful enrollment appears in the learner’s list; an agreed response-time target applies under a specified load. Do not invent the target on behalf of stakeholders. Record unresolved questions as decisions with owners, because silently guessing produces apparently precise tests for the wrong product.
Worked case: acceptance by example
For a workshop with one remaining seat, establish that a confirmed enrollment consumes that seat and an unsuccessful enrollment consumes nothing. Use examples to resolve questions about simultaneous attempts and cancellations. The following cases make both the result and side effects visible. A written example is still a proposal until the responsible people agree. It supplements the rule rather than replacing it: a handful of examples cannot describe every permitted account state, so retain the general constraint and its rationale alongside the examples.
Given | Action | Expected evidence
1 seat, no enrollment | enroll learner A | confirmation; seats=0; one row
0 seats, no enrollment | enroll learner B | capacity message; no row
A already enrolled | enroll A again | existing enrollment; no extra rowEach row identifies a precondition and checks both a message and persisted state.
Make the result observable
A toast saying “Saved” is weak evidence if the underlying enrollment cannot be inspected. Observability provides safe ways to see relevant state: an enrollment identifier, a read-only status view, a correlation identifier in test logs, or a query against an isolated database. Avoid exposing passwords or personal records for convenience. Controllability lets tests set the clock, provision a full course, or simulate a provider timeout. These design choices reduce reliance on fragile manual preparation and make difficult failures reproducible rather than mysterious.
Worked case: trace a missing rule
Suppose requirement ENR-4 prohibits duplicate active enrollment, but the current test checks only a second button click in the same browser. Map ENR-4 to a service-level duplicate request and a database uniqueness check, then retain one browser example for feedback. A second browser or delayed retry can bypass a disabled button. The trace exposes the missing path without demanding identical tests at every layer. Link evidence to a requirement version so a later change to cancellation semantics triggers review of the relevant examples.
Review requirements as a team activity
Run a short review with the author, implementer, tester, and a representative of users. Read for feasibility, consistency, missing negative outcomes, and accessibility. Ask what happens when capacity changes between viewing and submission, when a message fails to send, and when an account is suspended. Keep review findings distinct from executed test results. The review may prevent defects cheaply, but agreement is not proof of implementation. Close the loop by checking the delivered behavior against the agreed version and recording deliberate departures as decisions.
Common errors and fixes
Writing exact tests for an unsettled rule
- Why it happens
- A tester silently supplies a missing product decision.
- How to fix it
- Mark the assumption and obtain an owner’s decision.
- Prevent it next time
- Review ambiguous terms before detailed test design.
Using only a success message as evidence
- Why it happens
- The interface can acknowledge a write that never persisted.
- How to fix it
- Verify the relevant stored state through a safe observation path.
- Prevent it next time
- Include persistence evidence in acceptance criteria.
A traceability spreadsheet becomes stale
- Why it happens
- Requirements change without linked evidence review.
- How to fix it
- Link requirement versions to maintained cases.
- Prevent it next time
- Make impact review part of changing a rule.
Check your understanding
1. Rewrite “The report loads quickly” into a testable proposal.
Show worked solution
Propose: for an agreed dataset of 10,000 records and a specified device/network, 95 of 100 measured report openings display the first usable result within an agreed threshold. Name the measurement start and end. The threshold needs stakeholder agreement; the proposal is not yet an accepted requirement.
2. Design a testability change for a booking that expires after 15 minutes.
Show worked solution
Inject a clock and expose booking status in the test environment. Create a booking at time T, inspect before T+15 minutes, then at expiry. Expect the agreed active/expired transition without waiting in real time, and verify whether the seat is released according to the rule.
Key takeaways
- Examples reveal missing decisions; they do not authorize invented rules.
- Design safe observation and control paths before they become urgent.