25-Comp-A6 Software Engineering · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — May 2014 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: nine questions, candidates answer any five of the nine (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All nine questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented design, formal methods, real-time systems, software testing, project management, critical/dependable systems, software quality, distributed systems; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing/quality coverage; IEEE 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.
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 test suite exercises the program on a finite, chosen subset of its (typically astronomically large or infinite) input space. If any test in that subset fails, the program is provably incorrect — a single failing test is a valid proof of a defect. But if every chosen test passes, that only shows the program behaves correctly on the inputs actually tried; it says nothing about the inputs that were never tried, any one of which could still trigger a defect. Since it is generally infeasible to test every possible input (or every possible execution path/state), passing all tests can never be used to conclude the program is defect-free — only that no defect has yet been found by this particular finite sample.
For developers testing their own code: they have the deepest knowledge of the implementation, so they can efficiently target the boundary conditions and internal branches most likely to be wrong, and testing while writing (unit-level, incremental) catches defects at the cheapest possible point — before the code is ever integrated. It also builds a habit of designing for testability from the start.
Against: a developer's mental model of what the code "should do" is exactly the model that produced the bug in the first place — if a developer misunderstood a requirement, their own tests will typically encode the same misunderstanding and so will not catch it. Developers can also unconsciously avoid stressing the parts of the code they are least confident in, and there is a natural incentive (even if unintentional) to write tests the code is known to pass rather than tests designed to break it. An independent test team, working from the specification rather than the implementation, brings a different, adversarial perspective and is not blind to the same assumptions.
The two are not mutually exclusive: the standard practice (and the one implied by asking for arguments "for and against" rather than a single answer) is that developers perform unit testing of their own components as they are written, while an independent team performs integration, system, and acceptance testing against the requirements — each catches classes of defect the other is structurally poor at catching.
Treating cutWhiteSpace as a black box specified purely by its stated behaviour ("replace sequences of blank characters with a single blank character"), test cases are chosen to cover the input-space partitions and boundary conditions a specification-based (equivalence partitioning + boundary-value) approach would identify.
| # | Input paragraph text | Expected output | Partition being tested |
|---|---|---|---|
| 1 | "" (empty paragraph) | "" | Boundary: empty input, no characters at all |
| 2 | "Hello" | "Hello" | No blanks present — must be a no-op |
| 3 | "Hello World" | "Hello World" | Single interior blank (already minimal) — must be left unchanged, not corrupted |
| 4 | "Hello World" (3 blanks) | "Hello World" | One interior run of >1 blank — the core case |
| 5 | " Hello World" (leading blanks) | " Hello World" | Boundary: run at the very start of the paragraph |
| 6 | "Hello World " (trailing blanks) | "Hello World " | Boundary: run at the very end of the paragraph |
| 7 | "A B C D" (multiple runs, varying length) | "A B C D" | Several independent runs in one call — must not stop after the first |
| 8 | " " (blanks only) | " " | Boundary: the whole paragraph is a single run |
| 9 | "A" followed by a tab character followed by "B" (not a plain space) | implementation-defined — clarify whether "blank" means space-only or all whitespace | Ambiguity in the spec's own definition of "blank character" |
Test 9 is included deliberately: the specification says "blank characters" without defining whether tabs, newlines, or other whitespace count, which is exactly the kind of requirements ambiguity Question 3(b)/Question 4(b) elsewhere in this paper discuss — a good test derivation surfaces the ambiguity as a test case rather than silently guessing one interpretation.
