Question 5 of 8: Use Cases

Question 5: Use Cases (5 points)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

A use case's main success scenario and its alternate/exception flows describe every behaviourally distinct path through a piece of system functionality, from the actor's point of view — and that is exactly the structure a black-box acceptance test suite needs. Each flow becomes at least one test case: the main success scenario yields the “happy path” test, and every alternate or exception flow yields its own test for that specific branch (a cancelled transaction, a rejected input, a fault condition). The use case's stated preconditions become the test's setup/arrange step, and its postconditions become the assertions the test checks. This gives requirements-to-test traceability in both directions: every specified behaviour has at least one test that exercises it, and every test can be traced back to the requirement it verifies, so a change to one is a prompt to review the other. Because use cases are written at the system's external boundary rather than in terms of internal design, the tests they generate are naturally system/acceptance-level tests (what the system must do, observable by an actor) rather than unit tests of internal implementation detail. This is also why use cases are a natural unit for negotiating the “definition of done” with a customer: a use case is complete, from the customer's point of view, only once its acceptance tests — happy path and every stated alternate/exception flow — pass, which gives both sides a concrete, shared, checkable definition of what “this feature works” means rather than a subjective judgement call. The relationship runs both ways in practice: a tester reviewing a use case for testability often discovers an unstated exception flow (what if the actor cancels partway through, what if a precondition silently stops holding), and feeding that discovered gap back into the use case itself improves the specification, not only the test suite — so use-case-driven testing is as much a requirements-quality check as it is a verification activity.