Testing and maintenance
Testing and maintenance
- Finding errors — and keeping software working after release — is most of its lifetime cost.
- We classify errors, choose testing methods, and pick good test data.
- Then we maintain and safely amend the program.
Types of error
- Syntax error — breaks the language's grammar (missing bracket); caught at translation, so the program won't run.
- Run-time error — happens while running (divide by zero, file not found); the program crashes — fix by adding checks.
- Logic error — the program runs but gives wrong results (off-by-one, wrong operator); the hardest to find — only careful testing reveals it.
A program runs without crashing but produces the wrong answer. This is a:
A logic error gives wrong output even though the program runs — the hardest type to find.
A missing bracket or misspelled keyword is a:
Syntax errors break the grammar and are caught by the translator before the program runs.
Testing methods
- Dry run — trace the code on paper, recording each variable's value.
- White-box — designed from the code's internal structure (cover every statement/branch).
- Black-box — designed from the specification only (inputs → expected outputs).
- Alpha (in-house) then beta (limited real users); acceptance testing by the customer. A stub stands in for a module not yet written.
Black-box testing designs test cases from:
Black-box uses only the spec; white-box uses the code's internal structure to cover statements and branches.
Choosing test data
- Normal — typical valid values (marks 0–100:
50,75). - Abnormal — values that should be rejected (
-10,200,"abc"). - Boundary — the edges, where off-by-one bugs hide (
0,100, and just outside:-1,101).
For a field that accepts marks 0–100, which are the boundary test values?
Boundary data sits at the edges of the valid range (and just outside) — where off-by-one errors hide.
Maintenance and amending
- Perfective — improve features/performance even though it works; adaptive — keep it working in a changing environment (new OS/law); corrective — fix bugs found in use.
- To amend a program: read the code, make the change small, update all callers, then regression test (check you broke nothing) and document it.
Fixing a bug reported by users after release is which kind of maintenance?
Corrective maintenance fixes faults. Perfective improves; adaptive keeps it working in a changed environment.
After changing a program, regression testing checks that:
Regression testing re-runs old tests to confirm existing behaviour still works after a change.
You've got it
- syntax (won't run) · run-time (crashes) · logic (runs, wrong output — hardest)
- black-box = from the spec; white-box = from the code; alpha/beta/acceptance stages
- test data: normal, abnormal, boundary (edges catch off-by-one)
- maintenance: perfective / adaptive / corrective; always regression test after a change