Question 8 of 8

Question 8 (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) — decomposing the system using a Work Breakdown Structure. A WBS (Question 1c/scope management) recursively subdivides the total project deliverable into smaller, more manageable work packages, following the functional decomposition already implied by Question 7's requirements:

Each level-1 package is sized to be independently estimable and assignable to a sub-team: 1.1 Requirements & Project Management covers eliciting/documenting the requirements from Question 7 and ongoing planning; 1.2 Frontend/UI covers the listing, detail, map, search, and login views; 1.3 Backend Services splits further (level 2) into the public listing API, the map/location API, and the authentication/session API, mirroring the three service groupings in Question 7's system-context figure; 1.4 Data Layer covers the adventure and user data stores; and 1.5 Test & Deployment splits into unit/integration testing, an acceptance test covering both the unauthenticated and authenticated user roles, and deployment/release. This decomposition directly supports the incremental process model chosen in Question 7(a): increment 1 can be scoped as 1.1 + 1.2 (listing/map views only) + 1.3.1/1.3.2 + 1.4 + a subset of 1.5, with 1.3.3 (auth API) and the login-dependent parts of 1.2/1.5 forming increment 2.

Part (b) — the test plan. A test plan for this system, organized by test level, would specify:

• Unit testing — each backend service (1.3.1–1.3.3) and each frontend component tested in isolation against its own interface (Question 6c), covering valid inputs, boundary cases (e.g., an adventure with no ratings yet, a trail with no photos), and error handling (e.g., a malformed login request).
• Integration testing — verifying the frontend correctly calls each backend API and correctly renders the API's response, and that the backend services correctly read/write the data layer (1.4); particular attention to the map view, which must correctly integrate location data from potentially many adventures at once.
• System testing — exercising the functional requirements from Question 7(b) end-to-end against a deployed test environment: browse the adventure list, view details, view the master map, log in, and (for a logged-in user) submit/update a rating.
• Acceptance testing — run against BOTH user roles identified in the system context (Question 7's figure): an unauthenticated-user acceptance pass confirming the "main point of the system" (viewing adventures/map without any login friction) works cleanly, and a separate authenticated-user acceptance pass confirming login and any account-gated functionality.
• Non-functional testing — targeted tests against the NFRs from Question 7(c): a load/performance test on the listing and map views under a representative concurrent-visitor count, and a security test of the authentication service (e.g., verifying an unauthenticated request cannot reach an authenticated-only endpoint).

Structuring the plan by test level, rather than as one undifferentiated "testing" phase, mirrors the V-model's own quality argument from Question 3(a): each WBS work package here has a test level explicitly paired with it (unit tests for 1.3.x components, integration tests for their collaborations, system/acceptance tests for the end-to-end functional requirements), so no level of the decomposition is left unverified.