19-Soft-A6 Software Quality Assurance · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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) — the six ISO 9126 quality characteristics.
| Characteristic | What it measures |
|---|---|
| Functionality | Whether the software provides the functions that satisfy stated and implied needs when used under specified conditions — suitability, accuracy, interoperability, security, and compliance with functional standards. |
| Reliability | The capability of the software to maintain a specified level of performance over a stated period — maturity (freedom from failure), fault tolerance, and recoverability after a failure. |
| Usability | The effort needed to learn, operate, prepare input for, and interpret output from the software — understandability, learnability, operability, and attractiveness to the end user. |
| Efficiency | The relationship between the level of performance delivered and the resources consumed (CPU time, memory, I/O, network) under stated conditions — time behaviour and resource utilization. |
| Maintainability | The effort needed to make specified modifications — analysability (diagnosing deficiencies), changeability, stability (avoiding unexpected side effects of a change), and testability. |
| Portability | The ability of the software to be transferred from one environment to another — adaptability, installability, co-existence with other software, and replaceability of a component. |
Each characteristic is further decomposed into sub-characteristics in the full ISO 9126 model, and each sub-characteristic can be assessed with internal metrics (static analysis of the product) or external metrics (measured during execution/use), which is what makes the model usable as a practical quality-planning checklist rather than just a list of adjectives.
Part (b) — software quality control. Software Quality Control (SQC) is the set of activities that verify the delivered work products themselves — requirements documents, designs, code, test results — actually meet their defined quality requirements, using techniques such as walkthroughs, formal technical reviews/inspections, and testing at all levels (unit, integration, system, acceptance). SQC includes: defining measurable acceptance/exit criteria for each work product before it is checked; applying review and testing techniques appropriate to the product's stage in the lifecycle; recording and tracking every defect found to closure; and statistically analysing defect data (defect density, defect trends by phase) to judge whether the product is converging on an acceptable quality level before release. SQC is product-focused and reactive in the sense that it finds problems already present in a work product, which is what distinguishes it from Software Quality Assurance (part c and Question 2).
Part (c) — inspections vs. testing. A software inspection is a static, manual technique: a small trained team reads through a work product (most often source code, but also requirements or design documents) line by line against a checklist of known defect types, without executing the software at all. Testing is a dynamic technique: the software is actually executed with chosen input data and its observed behaviour is compared against the expected behaviour. The two are complementary rather than substitutes — inspections are effective earlier in the lifecycle (they can be applied to a requirements or design document that cannot yet be "run"), tend to find a different class of defect (missing logic branches, standards violations, unclear specifications) than testing does, and are typically cheaper per defect found because no environment or test data is needed; testing, by contrast, is the only technique that can confirm the software's actual run-time behaviour, including timing, resource use, and interactions with real external systems that a static read-through cannot reveal.
