Program Testing and Maintenance — errors, testing methods, test strategies, maintenance types

Syntax errors — violate language rules

• Detected by compiler/interpreter before execution
• Examples: missing semicolon, misspelled keyword, unmatched bracket, wrong parameter count
• Prevent program from running at all

Logic errors — program runs but produces wrong results

• Algorithm flaw, wrong formula, off-by-one loop, incorrect condition
• No error message — must be found by testing
• Often subtle (e.g., <= instead of <)

Run-time errors — crash during execution

• Division by zero, array index out of bounds, null pointer, file not found, stack overflow
• Valid syntax, but invalid operation at that moment
• Produce error message/exception at crash point

Static testing (code not executed):

• Dry run — manually trace through code with test data, recording variable values in a trace table. Finds logic errors.
• Walkthrough — author explains code to peers; team reviews logic, style, standards. Collaborative, informal.
• Inspection — formal, checklist-driven review by trained moderators (beyond syllabus scope).

Dynamic testing (code executed):

• White-box (glass-box) — test internal structure: paths, branches, conditions, loops. Requires code knowledge. Aim: statement/branch coverage.
• Black-box — test against specification only; inputs → expected outputs. No code knowledge needed. Techniques: equivalence partitioning, boundary value analysis.
• Integration testing — test modules combined. Strategies: big bang (all at once), top-down (stubs), bottom-up (drivers), sandwich.
• Stubs — dummy modules that simulate called modules (return fixed values) for top-down integration testing.
• Drivers — test harnesses that call modules for bottom-up testing.

User-facing testing:

• Alpha testing — internal users (developers, QA) test in controlled environment
• Beta testing — external users test in real environment; feedback on usability, compatibility
• Acceptance testing — customer validates against requirements; formal sign-off

Test strategy — high-level approach

• Scope: what to test (features, modules, interfaces)
• Methods: which techniques (white-box, black-box, etc.)
• Levels: unit → integration → system → acceptance
• Resources: tools, environments, personnel
• Schedule: when each level occurs
• Risk: what could go wrong, mitigation

Test plan — detailed execution document

• Test cases: ID, description, preconditions, steps, expected result, actual result, pass/fail
• Test data: specific values for each case
• Schedule: who, when, where
• Entry/exit criteria: when to start/stop testing

Test data categories (must know):

• Normal — valid, expected inputs within range (e.g., age=25 for 0-120)
• Abnormal (invalid) — inputs that should be rejected (e.g., age=-5, age="abc", age=200)
• Extreme/boundary — values at edges of valid range (e.g., age=0, age=120; also 1 and 119 for off-by-one)

Process:

1. Reproduce — consistent steps to trigger the error
2. Locate — trace, logs, debugger, print statements, binary search (comment out halves)
3. Understand — why does it happen? (root cause, not symptom)
4. Fix — minimal change addressing root cause
5. Verify — re-run failing case; run regression tests (related functionality)
6. Document — what, why, fix; update test cases

Common debugging techniques:

• Trace tables (dry run)
• Print/console logging at key points
• Debugger: breakpoints, step through, watch variables
• Rubber ducking — explain aloud to find logic gaps
• Binary search — disable half the code, narrow down

Corrective maintenance — fix defects found in use

• Bug fixes, patches, hotfixes
• Reactive: triggered by failure reports

Adaptive maintenance — modify for changed environment

• New OS version, hardware, browser, API, regulation, data format
• Proactive (planned) or reactive (forced)

Perfective maintenance — enhance without fixing a defect

• Performance optimisation, new features, UI improvements, refactoring, usability
• Often largest category over system lifetime

Preventive maintenance (beyond syllabus) — refactor to prevent future issues

Key point: Maintenance starts at delivery and continues until retirement. Design for maintainability (modularity, documentation, tests) reduces long-term cost.