Testing, Debugging and Documentation
Errors and testing
Three error types matter. A syntax error breaks the rules of the language, so the program will not run at all. A runtime error occurs while running, such as dividing by zero or reading past the end of an array, and usually stops the program. A logic error lets the program run but produce the wrong output. Testing can show that errors exist, but never proves that none remain.
Test data and test plans
Choose normal data (typical valid input), boundary or extreme data (the smallest and largest acceptable values, plus values just outside the range) and erroneous data (wrong type, empty, negative where not allowed). A test plan records the test number, the data used, the expected result and the actual result. Dry runs and trace tables follow the code by hand, recording each variable's value line by line. Levels of testing include unit, integration, system and acceptance testing; black-box testing uses only inputs and outputs, white-box testing uses knowledge of the code.
Debugging
Debugging is finding and fixing the cause. Tools include breakpoints, single-stepping, watching variable values, and temporary print statements; desk checking works without a machine. Read the error message, reproduce the fault reliably, then isolate it.
Documentation
User documentation explains installing, using and troubleshooting the software, in plain language. Technical documentation covers design, data structures, algorithms, APIs and maintenance notes, including in-code comments that explain why rather than what.
Traps
- Boundary data is valid at the edge of the range; erroneous data is invalid.
- Testing and debugging are different activities: testing finds faults, debugging fixes them.
- Validation checks input is sensible; verification checks it matches the original source.
Rule of thumb
For every condition you test, use at least one value below, at and above the limit.