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.
Selenium WebDriver is a widely used open-source test-automation framework for web applications. It drives a real browser (Chrome, Firefox, Edge) programmatically through an application's user interface — locating page elements, entering data, clicking controls, and asserting on the resulting page state — using client libraries available in Java, Python, C#, and JavaScript, so tests are written in a normal programming language rather than a proprietary scripting format. A Selenium suite is typically organized with the Page Object Model, wrapping each screen's elements and actions behind a class, so a UI change requires updating one page object rather than every test that touches that screen. Suites run headless (no visible browser window) in a continuous-integration pipeline, execute across multiple browsers and operating systems via a Selenium Grid or a cloud device farm, and produce machine-readable pass/fail reports plus screenshots or video on failure, so a broken test is quickly diagnosable without a human re-running it by hand. Selenium automates the interaction layer only — it does not itself decide what to assert — so it is paired with a test framework (JUnit, TestNG, pytest) that supplies structure, assertions, and reporting.
Why this helps agile development. Agile's short sprint cadence (Question 2(b)) depends on being able to re-verify the ENTIRE existing feature set quickly enough to fit inside each iteration — a manual regression pass across a growing application does not scale to that cadence, but an automated Selenium suite wired into continuous integration runs the full regression set on every commit in minutes, giving the team the same "is anything broken" answer a manual QA pass would take days to produce. This lets testers spend their time on genuinely new, exploratory testing of the sprint's new work instead of re-checking old functionality by hand, and it catches a regression the same day it is introduced rather than at a later, more expensive point — directly reinforcing the tightened SQA feedback loop discussed in Question 2(c).
More generally, whichever specific tool a team uses, a version control system (CVS historically, Git today) is itself a foundational SQA tool independent of test automation: it gives every change a permanent, attributable history (who changed what, when, and, via commit messages, why), lets a defect be traced back to the exact commit that introduced it (bisection), and lets a bad change be rolled back instantly rather than hand-repaired — directly supporting the change-control activity identified in Question 2(a) as a core SQA responsibility, and is the substrate that continuous integration (and therefore the Selenium example above) is triggered from on every commit.
