NivaarExam PrepOfficial exam papers ↗

19-Soft-A6 Software Quality Assurance · Undated paper

Question 6 of 8

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

04-Soft-A6, Software Quality Assurance — National Exams, May 2019 (3 hours, open book, 8 questions of equal value; FIVE constitute a complete exam paper, and the first five as they appear in the answer book are marked — all eight are solved here as a study resource).

Reference texts: Pressman, Software Engineering: A Practitioner's Approach, 9th ed. (SQA planning, review, testing strategies/techniques, software metrics, reliability & safety); Sommerville, Software Engineering, 10th ed. (software process, configuration management, project monitoring); ISO/IEC 25010 SQuaRE and its predecessor ISO/IEC 9126 (software quality characteristics); ISO/IEC 12207 (life-cycle/configuration-management processes).

Question 6 (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) — activities of a mature test process.

  1. Test planning. A documented test plan defines scope, objectives, resources, schedule, and the entry/exit criteria for each test level, agreed before test execution begins (not written after the fact to match whatever was actually done).
  2. Test design, derived from requirements/design via traceability. Test cases are systematically derived using documented techniques (equivalence partitioning, boundary-value analysis, state-based design) and are traceable back to the requirement or design element they verify (Question 3c).
  3. Test environment management. A controlled, repeatable test environment (data, configuration, tools) is established and version-controlled so results are reproducible test run to test run.
  4. Test execution and defect logging. Tests are executed per the plan, and every failure is logged with enough detail (steps to reproduce, expected vs. actual) to be triaged and fixed without re-investigation.
  5. Regression testing on every change. A maintained regression suite re-verifies previously passing functionality after every fix or new feature, ideally automated, so a change cannot silently reintroduce a previously fixed defect.
  6. Metrics collection and process feedback. Defect density, defect discovery rate, and test-coverage metrics are collected and fed back to improve future test planning and to catch when the test process itself is not converging (defect rate not dropping as expected).

A mature test process is distinguished from an immature one primarily by items 2, 5 and 6: an ad hoc process can still execute tests (item 4), but only a mature one designs tests systematically with traceability, automates regression, and closes the loop with metrics.

Part (b) — a testing tool: JUnit (unit-test automation framework). JUnit is a framework for writing and automatically running unit tests for Java code: a developer writes a test method per unit of behaviour, using assertion calls (assertEquals, assertTrue, etc.) to state the expected outcome, and the framework's test runner executes every test method, reporting pass/fail for each without any manual comparison of output.

AdvantagesDrawbacks
Fully automated re-execution makes regression testing (part a, item 5) practically free after the first investment, so it runs on every build/commit.Only exercises what the developer thought to assert — a missing test case for an untested code path gives false confidence, not actual coverage.
Tests double as executable documentation of a unit's intended behaviour, readable by any developer.Tests units in isolation, so integration-level and system-level defects (interactions between classes/services) are not caught by JUnit alone — it must be paired with integration/system testing.
Fast feedback (seconds) lets developers catch a regression immediately after introducing it, before it reaches a shared branch.Writing and maintaining good unit tests is itself an engineering effort; poorly designed tests (over-mocked, brittle to refactoring) can slow development down rather than speed it up.