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.
Preparing an SQA plan at project start that identifies evaluations, audits, reviews, and standards to be applied, and assigns responsibility for each. Participating in and facilitating formal technical reviews of requirements, design, and code, so defects are caught by peers before they propagate downstream. Enforcing a defined, multi-tier testing strategy (unit → integration → validation → system) rather than leaving test scope to individual discretion. Applying process and product standards agreed for the project (coding standards, documentation templates, the applicable quality model). Enforcing change control so every modification is assessed, approved, and traceable, and measuring/reporting the impact of change. Maintaining SQA records and periodically auditing them so management has objective visibility into project quality rather than developer self-report.
Agile software development is an iterative, incremental approach to building software in short, time-boxed cycles (sprints/iterations), guided by the Agile Manifesto's values — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a fixed plan. Each iteration delivers a working, testable increment, and requirements/priorities are re-evaluated and adapted continuously based on feedback rather than frozen upfront.
Under the Waterfall model, SQA activities are discrete and phase-gated: a formal review or audit occurs at the boundary of each phase (requirements sign-off, design review, code review), documentation is heavy and produced up front, the SQA plan is largely fixed at project start, and testing is concentrated as a distinct, late phase after most or all coding is complete — so a quality problem rooted in an early phase may not surface until much later, when it is far more expensive to fix.
Under Agile development, SQA is continuous and embedded in every sprint rather than gated at phase boundaries: automated unit tests and continuous integration run on every commit, test-driven development pushes verification to the moment code is written, peer/pair code review substitutes for a single formal design review, and sprint retrospectives function as a rolling audit that replaces a project-end quality audit. Documentation is lighter but the feedback loop is far tighter, so defects are typically caught within the same iteration they were introduced rather than phases later. In both models the same underlying SQA activities from part (a) are present — reviews, testing, change control, standards, records — the difference is cadence and granularity: Waterfall applies them in large, discrete blocks per phase, Agile applies them continuously in small increments per sprint.
