Question 5 of 8

Question 5 (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) — testing a large, highly interdependent database, and the effect on the test plan.

1. Model the interdependencies before writing test cases. Build a data dictionary/entity-relationship model that records every field's dependency — derived/calculated fields, foreign-key and referential-integrity constraints, triggers — so the test designer knows which combinations of fields actually matter.
2. Test individual attributes first. Apply equivalence partitioning and boundary-value analysis field-by-field, catching simple single-field defects cheaply before spending effort on combinations.
3. Design interdependency (integration) tests from the model. Build test cases that specifically exercise the dependency rules identified in step 1 — e.g., does updating field A correctly cascade to derived field B, is a referential-integrity violation correctly rejected.
4. Apply risk-based/combinatorial test selection. Exhaustive testing of every combination of interdependent attributes is computationally infeasible, so use pairwise/orthogonal-array or risk-prioritized selection to cover the highest-risk interactions within a feasible number of test cases, and explicitly document the resulting (incomplete) coverage rationale.
5. Add negative and volume/performance testing. Confirm invalid combinations are rejected, and that the database performs acceptably at realistic or peak data volumes, since interdependency defects and performance defects both tend to hide until the database is large.

Effect on the test plan: the plan must budget significant time up front for data modelling and synthetic test-data preparation (before any test execution begins); it must state a risk-based coverage criterion instead of claiming exhaustive combination coverage, with the rationale documented for audit; it needs a realistic (or representative, scaled) copy of the database as a dedicated test environment; and it must add explicit data-integrity and volume/performance test line items with their own pass/fail criteria, since these are easy to omit from a plan written before the database's true complexity was understood.

Part (b) — recovering a delayed schedule with fixed resources.

1. Re-run the risk analysis and re-prioritize scope, not effort. Identify the highest-risk, highest-usage functionality and guarantee it gets full testing within the unchanged hours; lower-risk areas are tested at reduced depth or deferred, so the fixed budget of hours is spent where a defect would matter most.
2. Overlap preparation with the developers' remaining days. Use the delay window productively — finish test-environment setup, test-data preparation, and test-case design/review during the extra days developers are still coding, so execution can start the moment code actually arrives rather than only then beginning preparation.
3. Run a fast smoke/sanity test at delivery. Before committing the full remaining schedule to detailed testing, confirm the delivered build is stable enough to be worth testing at all, avoiding wasted hours against a badly broken delivery.
4. Increase efficiency rather than headcount. Automate regression tests that would otherwise be repeated by hand, and use coverage tooling to steer the fixed hours toward code paths not yet exercised, since resources (hours, staff, tools) cannot be increased.
5. Report residual risk explicitly. If prioritized testing still cannot cover everything in the remaining time, communicate exactly what was not tested to the release decision-makers rather than silently signing off — the schedule pressure is made visible, not absorbed invisibly by the test team.