Question 6 of 8: Testing Activities, Unit-Testing Techniques, Stubs/Drivers, and System Testing

Question 6: Testing Activities, Unit-Testing Techniques, Stubs/Drivers, and System Testing (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) — technical activities for testing. Test planning — deciding what to test, at what levels, with what resources and schedule. Test-case design — deriving concrete inputs and expected outputs from the specification (black-box) and/or the code structure (white-box). Test execution — running the designed cases against the system under test and recording actual results. Defect logging and tracking — recording every discrepancy between expected and actual behaviour and tracking it through to resolution. Test reporting — summarising coverage, pass/fail status and outstanding defects to inform the release/quality-gate decision (Question 7's configuration/change process depends on this report to decide whether a change is ready to re-baseline).

Part b) — unit testing techniques. Equivalence partitioning (black-box) — dividing the input domain into classes expected to be handled identically, then testing one representative value per class rather than every possible input. Boundary value analysis (black-box) — testing values at and just around the edges of each equivalence class (minimum, maximum, just-inside, just-outside), since defects cluster at boundaries. Basis path / control-flow testing (white-box) — deriving test cases from the unit's control-flow graph so that every independent path (cyclomatic-complexity count) is executed at least once. Condition/branch coverage (white-box) — ensuring every decision outcome (each branch of every if/switch) is exercised by at least one test case.

Part c) — stubs and drivers. A stub is a minimal, dummy replacement for a module that a unit under test calls (a callee not yet integrated), returning a canned response so the caller can be tested in isolation. A driver is a minimal test harness that calls a unit under test (a caller not yet integrated), supplying test inputs and capturing outputs. They are used in the two classic integration strategies: top-down integration tests higher-level modules first, using stubs to stand in for lower-level modules not yet integrated (e.g. testing Dispatcher.allocateResource() against a stub ResourceRegistry that returns a fixed available-resource list); bottom-up integration tests lower-level modules first, using drivers to exercise higher-level modules not yet integrated (e.g. a driver that calls ResourceAssignment.persist() directly before Dispatcher exists).

Part d) — system testing activities. Recovery testing — forcing the system to fail (e.g. mid-allocation) and verifying it recovers correctly without data loss. Security testing — verifying the system resists unauthorised access to incident/personnel data. Stress testing — exercising the system beyond normal load (e.g. a surge of simultaneous emergency reports) to find the point and mode of failure. Performance testing — verifying the system meets its quality/response-time requirements (Question 4a's 2–5-second targets) under expected load. Acceptance/deployment testing — the customer (dispatch authority) exercises the fully-integrated system against real operational scenarios before go-live.