Robust and secure programming: normal (typical)

The idea

In robust programming, test data is chosen deliberately, and 'normal' data means values a well-written program should accept and process correctly. It sits inside the valid range and matches the expected data type and format: for an age field accepting 11 to 18, a normal value is 14; for a percentage field, 65; for a password field, a string of the required length. Normal data is used to check that the program produces the correct expected output for ordinary, realistic input, so it tests the core logic rather than the error handling. A common method is to pick one or two typical values per input and predict the exact output before running the program, then compare. If normal data is rejected or gives a wrong result, the validation or processing logic is faulty.

What earns the marks

• Normal (typical) data is a value that lies within the accepted range and matches the expected data type and format.
• Normal data is used to confirm the program produces the correct expected output for ordinary, realistic input.
• A normal value for an age field accepting 11 to 18 could be 14, which is inside the range and not at an edge.
• Normal data tests the main processing logic rather than the validation or error handling.
• Normal data is distinct from boundary data (edge values) and erroneous data (values that should be rejected).
• The expected output for a chosen normal value should be predicted before running the program and then compared.

Common mistakes and how to put them right

• Choosing a value at the edge of the range (such as 11 or 18 for an 11 to 18 field) and calling it normal.

  Put it right: , edge values are boundary data, so pick a value clearly inside the range such as 14.

• Thinking normal data tests whether invalid input is rejected.

  Put it right: , normal data should be accepted, so it tests the main processing logic, while erroneous data tests rejection.

• Picking a value of the wrong data type, such as text for a numeric field, and calling it normal.

  Put it right: , normal data must match the expected type and format as well as the range.

• Running the program without predicting the expected output first.

  Put it right: , state the expected result in advance so a wrong output can be identified.

Exam tips

• Always justify why a value is normal by referring to the range and the data type, not just by saying it is a sensible number.
• Predict the exact expected output for your chosen normal value before describing the test, then state what a correct result would look like.
• Contrast your normal value explicitly with a boundary value and an erroneous value so the distinction is clear in your answer.