19-Soft-A6 Software Quality Assurance · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, December 2013 — 04-Soft-A6, Software Quality Assurance (open book, non-communicating calculator permitted, 3 hours). Per the paper's own notes, FIVE of the EIGHT questions constitute a complete exam and each is of equal value; all eight are answered in full below as a complete study resource.
Reference texts. Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 15 (SQA), Ch. 17–18 (unit/integration/validation/system testing strategy), Ch. 19–20 (white-box basis-path testing, black-box equivalence partitioning & boundary value analysis); Sommerville, Software Engineering, 10th ed., Ch. 8 (Software Testing) and Ch. 24 (Quality Management); SWEBOK v4, Software Quality KA and Software Testing KA; ISO/IEC 25010 (SQuaRE) for the software product quality model referenced in Question 1; ISO/IEC/IEEE 12207 (Software life cycle processes) for the process-standard referenced in Question 1(b).
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.
Verification asks "are we building the product right?" — it confirms that each work product correctly implements the specification or design it was built from, at the phase it was built in, and is largely inward-looking (structural). Validation asks "are we building the right product?" — it confirms that the complete, integrated software actually satisfies the customer's real needs, and is largely outward-looking (functional/black-box).
Illustrated with the Appendix A program from Question 6: basis path testing SearchProps() to confirm every independent path through its own for/if logic executes correctly (Question 6's test set) is verification — it checks the function against its own internal logic and design intent, with no reference to whether a real estate agent actually wants this feature. Running the black-box access-control test of Question 5 — or, in this program's own domain, confirming that a broker who types a property's code genuinely gets back the correct price, address, and commission the way the requirement intends — is validation: it checks the finished behaviour against the real-world need, independent of how SearchProps() is internally structured. A program can pass every basis-path test in Question 6 (fully verified) and still fail validation, e.g. if brokers actually needed to search by address rather than by an opaque code — the code would still be "right" by its own design, just the wrong feature.
System testing exercises the fully integrated software as a whole, together with its real operating environment (hardware, other software, users), under conditions a single module or subsystem cannot exercise alone — commonly broken into recovery testing (does it restart cleanly after a failure), security testing (can protection mechanisms be circumvented, directly relevant to Question 5's access-control unit), stress testing (behaviour under resource limits or abnormal load), and performance testing (does it meet response-time/throughput requirements). It is conducted by the development organization, in a controlled environment, before release.
Alpha testing is conducted at the developer's site, by a representative set of end users, with a developer present to observe and record problems directly — the environment is still controlled/simulated, but real users rather than the test team exercise the software. Beta testing is conducted at one or more end-user sites, in the field, under real operating conditions, with no developer present; the customer uses the software as part of normal work and reports problems back, so beta testing surfaces defects tied to environments, data, and usage patterns the developer could not anticipate or reproduce in-house.
