25-Comp-A6 Software Engineering · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2013 — 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 and function-oriented design, requirements engineering, software testing, software reuse, rapid development and prototyping, client-server architectures, software validation; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design/reuse vocabulary.
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.
Black-box (functional/specification-based) testing derives test cases purely from the component's specified behaviour — its inputs, outputs and stated requirements — with no reference to how it is implemented internally. White-box (structural) testing derives test cases from the component's internal structure, aiming to exercise specific statements, branches, or paths through the code. Black-box testing's strengths are that it can be designed as soon as the specification exists (even before the code is written), that it is independent of implementation details and so survives a refactor of the internals unchanged, and that it directly checks whether the software does what it is supposed to do. Its weakness is that it cannot guarantee any particular code coverage — a path through the code may simply never be exercised by any test derived purely from the spec, and defects arising from unusual internal states invisible at the interface can be missed. White-box testing's strength is the reverse: it can systematically guarantee coverage of statements, branches or paths, catching internal logic errors, dead code, and off-by-one conditions that a black-box view would never reveal. Its weakness is that it is tied to a specific implementation (a refactor with unchanged behaviour still requires new white-box tests), it requires access to source and specialised coverage tooling, and passing every internal path proves nothing about whether the code actually implements the intended requirement — a consistently-wrong implementation can have 100% white-box coverage and still fail every black-box case.
| Test case | Purpose |
|---|---|
| Empty array | Boundary: zero elements |
| Single-element array | Boundary: trivially sorted |
| Already-sorted array | Best-case / no-op behaviour |
| Reverse-sorted array | Worst-case ordering |
| Array with duplicate values | Stability/tie-handling of equal keys |
| Array with negative and positive values | Correct ordering across sign |
| Array with all identical elements | Degenerate case, no distinct ordering |
| Array containing INT_MIN / INT_MAX | Boundary values of the integer type |
| Large random array | General-case correctness at scale |
| Test case | Purpose |
|---|---|
| Empty line | Boundary: zero-length input, expect count 0 |
| Line of all blanks | Expect count 0 |
| Line with no blanks at all | Expect count = line length |
| Line with mixed blank and non-blank characters | General case |
| Line with leading and/or trailing blanks | Blanks at the boundary of the string, not just interior |
| Line containing tab characters | Clarifies whether "blank" means space only or any whitespace |
| Line with punctuation/special characters | Confirms non-space, non-alphanumeric characters are counted as non-blank |
| Single-character line | Boundary: smallest non-empty input |
| Very long line | General-case correctness / buffer handling at scale |
| Operation | Test cases |
|---|---|
| length() | Empty string (0); single character (1); typical string; string containing special/whitespace characters |
| concatenation() | Both operands non-empty; one operand empty (identity check: s + "" = s); both operands empty (result empty); result length equals sum of operand lengths |
| sub-string selection() | Substring at the very start; substring at the very end; the whole string; a zero-length substring; a single-character substring; out-of-range indices (start beyond length, negative start, end before start) to confirm defined error behaviour |
