Program Testing and Maintenance — common mistakes

In exams, when asked to provide test data, always choose a value from each category: normal, boundary, and abnormal. For boundary data, test both the valid limits (e.g., 18 and 25) and the values immediately outside them (e.g., 17 and 26). This demonstrates a thorough understanding.

A dry run is a manual process where a programmer mentally traces the execution of code with a specific set of inputs, often using a trace table. White-box testing is a broader, formal strategy that involves creating specific test cases to execute code paths, which might be automated. A dry run can be a technique used within white-box testing.

Many programming errors occur at the boundaries of input ranges. For example, using $<$ (less than) instead of $<=$ (less than or equal to) is a common mistake that only a boundary test would reliably find. Testing the edges ensures your logic is precise.

Usually, no. When you are asked to create a test plan before writing the code, you only fill in the 'Expected Outcome'. The 'Actual Outcome' column is for when you are actually executing the tests. Read the question carefully; if it asks you to trace code and report the result, that result would be the 'Actual Outcome'.

No, these categories are generally mutually exclusive for clarity. Data is either valid (normal, valid boundary) or invalid. Invalid data is then categorised. Data just outside the valid range (e.g., 101 for a 1-100 range) is considered invalid boundary data. Data of the wrong type (e.g., 'hello') or far outside the range is abnormal. In exams, it's best to stick to the clearest classification.