Program Testing and Maintenance — FAQ

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.

Studies often show that perfective maintenance consumes the largest portion of the maintenance budget over a software's lifetime, as there is a constant demand for new features and improvements. However, emergency corrective maintenance can be extremely costly in the short term due to its urgency and potential impact on business operations.