19-Soft-A6 Software Quality Assurance · December 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, December 2014 — 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. 3 (agile and concurrent process models), Ch. 15 (SQA, cost of quality, configuration management), Ch. 17–18 (unit/integration/validation/system testing strategy, verification vs. validation), 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, Software Testing KA, and Software Configuration Management KA; ISO/IEC 25010 (SQuaRE) for the product quality model; ISO/IEC/IEEE 12207 (Software life cycle processes) for the SQA and configuration management process framework referenced in Questions 1 and 8.
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 a work product correctly implements the specification or design it was built from, at the phase it was produced in, and is largely inward-looking/structural (Question 6's basis-path test of fn_delete_element against its own logic is verification). Validation asks "are we building the RIGHT product?" — it confirms the complete, integrated software actually satisfies the customer's real need, and is largely outward-looking/functional (Question 5's black-box test of authorISBN's constraints against the database's real specification is validation). A unit can pass every verification check and still fail validation — fn_delete_element could be re-implemented with none of Question 6's four defects and still be validated as the wrong feature if, say, the real requirement needed a stable deletion that preserved the FIRST occurrence's position semantics rather than the last.
Alpha testing is conducted AT THE DEVELOPER'S site, by a representative set of real end users, with a developer present to observe and record problems directly — still a controlled/simulated environment, but exercised by real users rather than the test team. 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, surfacing defects tied to environments, data, and usage patterns the developer could not anticipate in-house. Pilot testing is a controlled, closely monitored trial DEPLOYMENT of the finished software to a limited subset of the intended user population or sites (e.g. one branch office, one hospital ward) before full-scale rollout — unlike beta testing, which is primarily about finding remaining defects, pilot testing is typically used to validate the DEPLOYMENT and rollout process itself (installation, training, data migration, support readiness) at real scale before committing to a wider release.
System testing exercises the fully integrated software together with its real operating environment, and is conventionally broken into four types. Recovery testing forces the system to fail in various ways (power loss, corrupted data) and verifies it restarts cleanly and correctly within an acceptable time. Security testing attempts to verify that protection mechanisms built into the system actually prevent unauthorised access or corruption (directly relevant to Question 5's access-control style constraints). Stress testing executes the system under abnormal resource levels or load (peak transaction volume, memory pressure) to find the point and manner of failure, so a graceful degradation strategy can be designed around it. Performance testing checks that the integrated system meets its stated response-time and throughput requirements under realistic operating conditions, often run in conjunction with stress testing since performance frequently degrades before an outright failure occurs.
