Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2015 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Part (a) — strategy vs. technique. A testing strategy is the roadmap that describes the steps to be conducted as part of testing, when those steps are planned, and how much effort/time/resources will be required — it incorporates test planning, test-case design, execution, and resulting data collection/evaluation, and it moves outward from unit → integration → validation → system testing. A testing technique (or method) is a specific procedure used to design individual test cases within one of those steps — e.g. equivalence partitioning, boundary value analysis, or basis path testing are techniques applied inside a unit-testing strategy. In short: strategy = the "when/what order/how much" plan across the whole project; technique = the "how do I derive this specific test case" method used at a given step.
Part (b) — integration testing approaches.
Big-bang integration — all modules are combined at once and the entire program is tested as a whole; simple to schedule but defect isolation is very hard and interface errors surface all at once.
Top-down integration — modules are integrated by moving downward through the control hierarchy, starting at the main control module; lower-level modules not yet integrated are replaced by stubs. Major control decisions are tested early, but low-level utility logic is exercised late.
Bottom-up integration — construction and testing begin with atomic (leaf) modules, combined into clusters ("builds") driven by temporary drivers; low-level processing is validated early, but the overall program isn't executable until near the end.
Sandwich (hybrid) integration — combines top-down for upper levels with bottom-up for lower levels, meeting in the middle; reduces the stub/driver burden of the pure strategies.
Regression testing (re-run as each new module is integrated) and smoke testing (a fast, broad daily build-and-test) are typically layered on top of whichever integration order is chosen.
Part (c) — regression testing in agile development. Yes — it is not just reasonable, it is essential. Agile relies on very short iterations with continuous, incremental changes to a growing code base; without regression testing after every change, there is no way to know that new/changed functionality has not broken previously-working features. Agile teams make this practical by automating the regression suite (unit tests run in continuous integration on every commit/build) so the otherwise-prohibitive cost of manually re-running a growing test suite every iteration is avoided; frameworks such as JUnit and CI pipelines exist specifically to make this "test early, test often, test automatically" loop affordable within a one-to-four-week sprint.
