Question 3 of 8

Question 3 (10 marks)

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.

Part (a) — why development and testing are usually separated. The developer who wrote a module has an inherent psychological investment in seeing it work and a mental model of the code shaped by how they built it, which makes it hard for them to imagine the inputs or paths their own design did NOT anticipate — they tend to test the way they think, not the way a user or an adversary would act, and they may unconsciously avoid inputs that would expose a design flaw they'd have to fix. An independent tester (or independent test team) has no such attachment: they read the specification, not the code, so they naturally probe boundary conditions, error paths and misuse cases the author never considered, and they can report defects without the awkwardness of criticizing their own work. This is precisely why an FTR (Q2) is also conducted by peers rather than the author reviewing themself.

Part (b) — requirements/design specifications driving test-case creation. A specification states WHAT the system must do (requirements) and HOW it is structured to do it (design), and both are the raw material test cases are derived from without needing to read the implementation code at all (this is exactly the black-box principle of Q5a/Q7). Each requirement statement becomes at least one test case that would fail if that requirement were not met; each design specification exposes structural elements — classes, states, interactions, deployment nodes — that in turn suggest concrete test scenarios (which object collaborations to exercise, which states/transitions to cover, which component boundaries to test across). Without the specification, a tester has no independent basis for "what should happen" and can only check that the code does what the code does — which proves nothing.

Part (c) — a sequence diagram example. Consider a login use case specified with a UML sequence diagram: User → LoginForm: submit(username, password); LoginForm → AuthService: validate(username, password); AuthService → Database: lookup(username); Database --> AuthService: storedHash; AuthService --> LoginForm: result; LoginForm --> User: success/failure message. This single diagram directly suggests a family of test cases without looking at any code: a valid-credentials happy path (every message fires, success returned); an invalid-password path (AuthService returns failure after the lookup succeeds); a nonexistent-username path (Database returns no record, and the diagram implies AuthService must still respond rather than hang); and a Database-unavailable path (the lookup message never returns, exercising the timeout/error-handling behaviour the diagram's structure implies must exist even though it isn't drawn). Each lifeline interaction on the diagram becomes a distinct scenario to verify.