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.
Software Quality Assurance (SQA) is the planned, systematic set of activities that provide management, developers, and customers with objective confidence that a software product and the process used to build it conform to established requirements, standards, and procedures. It is a management-and-engineering discipline layered over the whole development effort, not a single test at the end.
Regardless of the specific model or standard adopted, the activities common to virtually every SQA framework are: applying technical methods (structured reviews, static analysis, walkthroughs) to work products as they are produced; conducting formal technical reviews at defined milestones; enforcing a defined multi-tier testing strategy; controlling and auditing change through configuration management; measuring and reporting the impact of change and defects; and maintaining SQA records that are reported up to management so deviations are visible and actionable.
ISO/IEC 25010 (SQuaRE — Systems and software Quality Requirements and Evaluation). Defines a product quality model of eight characteristics (functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability); its purpose is to give SQA a common, measurable vocabulary for specifying and evaluating what "quality" means for a given product, replacing ad-hoc quality claims with characteristics that can be assessed.
ISO/IEC/IEEE 12207 (Software life cycle processes). Defines the full set of processes — including a dedicated Quality Assurance process and separate Verification and Validation processes — that an organization applies across a software product's entire life cycle; its purpose is to give SQA a common process framework so that quality activities are planned, resourced, and audited consistently from acquisition through retirement, rather than left to individual project judgement.
SQA is an umbrella activity, applied throughout the entire software development process, not a phase confined to one point in it (e.g. not simply "the testing phase" at the end). Reviews, standards enforcement, change control, and measurement recur in every phase from requirements through maintenance; treating SQA as a single late phase is precisely the failure mode SQA planning exists to prevent, because defects injected early (e.g. in requirements) are cheapest to fix when caught early, and only an umbrella activity that is present at every phase can catch them there.
