Question 3 of 8: Integration Testing Strategies and Regression Testing

Question 3: Integration Testing Strategies and Regression Testing (10 marks)

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.

(a) Top-down vs. bottom-up integration testing

Top-down integration begins with the main control module and integrates downward, one level of the call hierarchy at a time, replacing modules not yet integrated with stubs. Its advantage is that the program's major control and decision logic is validated first, giving a "working skeleton" very early — useful for demonstrating progress and for catching architectural/interface defects while they are still cheap to fix. Its cost is the stub-writing effort itself, which grows with the number of low-level modules a large system has, and low-level processing (arithmetic, data manipulation, I/O formatting) is not exercised with real code until late in the integration sequence.

Bottom-up integration begins at the leaves — already unit-tested atomic modules — and combines them upward into progressively larger clusters ("builds"), using a driver to supply test-case input at each cluster's current top, removing that driver as the next real caller is added above it. Its advantage is that no stubs are ever needed and low-level, often numerically or logically intricate processing is validated with real code from the very start. Its cost is the mirror image of top-down's: the program's own top-level control logic is not exercised as an integrated whole until the very last module is added, so an architectural defect in that control logic surfaces late.

For a relatively small project — few modules, a shallow call hierarchy, and where correctness concentrates in low-level computation — bottom-up's driver overhead is small and its early validation of that low-level logic is the more valuable property, so bottom-up (as Question 6 uses, testing each of fn_delete_element's own leaf-level basis paths directly) is usually preferred. For a relatively large project with a deep, complex call hierarchy and significant architectural risk, top-down (or a sandwich/hybrid strategy combining both directions, meeting in the middle) is usually preferred despite its heavier stub cost, because it is far more valuable to know the overall control architecture works before investing further integration effort beneath it.

(b) Purpose and conduct of regression testing

Purpose. Regression testing re-executes a subset of already-passed tests after a change (a bug fix, a new feature, a refactor) to confirm the change has not introduced a NEW defect into functionality that previously worked correctly — i.e. that the software has not "regressed" to a previously defective state. It exists because fixing or extending one part of a system frequently has unintended side effects elsewhere, especially where modules share data or call each other.

Conduct. A regression test suite is maintained as a growing subset of the tests already run against the software, since re-running every test ever written after every change is usually prohibitively expensive. A representative sample is selected using three overlapping criteria: tests that exercise the software's major functions broadly (a general safety net); tests that focus specifically on the module(s) actually changed; and tests that focus on components identified by impact/traceability analysis as likely affected by the change even though they were not directly modified. In an agile/CI environment (Question 8), this suite is automated and executed on every commit or build, so a regression is caught the same day it is introduced rather than being discovered much later, when it is both harder to diagnose and more expensive to fix.