Classify a functional, performance, security, or accessibility concern by its actual effect.
Build an acceptance criterion with context, measure, denominator, and threshold without unsupported generalization.
Quality is not a single number. An appointment app might display the correct date yet take too long to confirm. It might be fast while exposing another person's booking details, or prevent a keyboard user from reaching Submit. A product-quality model helps name different concerns, but naming one is not itself a test. Begin with the actual effect: is the functional result wrong, is response slow under a defined workload, is access unauthorized, or is an interaction unavailable to some users? Concerns can overlap. A disclosure is a security and privacy problem that may damage trust, but a response-time check will not reveal it. Select an observation suited to each claim.
Write a testable condition with five elements: initial state, action, observed population, result measure, and acceptable limit. For example, ‘In the defined test environment, for 40 independent valid bookings, each confirmation shows the date entered for that request; the required result is 40 of 40.’ This is a bounded functional criterion, not a promise for every workload. For performance, one might say, ‘With 20 concurrent simulated users for ten minutes, at least 95% of confirmation responses take no more than two seconds.’ Then specify whether failed requests count and whether the denominator includes all attempts. Without the denominator and error rule, excluding failed requests can hide slow or unavailable service. These numerical thresholds are instructional product choices, not universal standards.
Functional access and accessibility may need distinct methods. A keyboard user's ability to reach Confirm requires an observed interaction path: where does focus go, is focus visible, and can the button be activated without a mouse? ‘Is the form easy to understand?’ may require watching and interviewing users; an automated check alone cannot answer that question. Security likewise begins with an explicit access rule and then a negative request in an authorized environment: is someone else's booking request refused? A successful owner request does not show that a non-owner is blocked. A teaching exercise is no permission to probe a live service. Keep specification evidence separate from evidence about usability and protection of users.
Lesson summary
Classify a functional, performance, security, or accessibility concern by its actual effect. Build an acceptance criterion with context, measure, denominator, and threshold without unsupported generalization.
