01 | RUNNING ONCE IS NOT ENOUGH

You build a program that receives a mark from zero to fifty. You enter 34 and see “Mark accepted”. Does that prove the program works?

It shows evidence for one accepted input. It does not show whether 500 is rejected, whether an empty entry is handled or whether letters cause the program to crash.

Test data is data deliberately chosen to check a system’s behaviour. Good testing includes both inputs that should be accepted and inputs that should not.

The syllabus distinguishes normal, abnormal, extreme and boundary data. This lesson focuses on normal and abnormal. The next lesson examines the accepted endpoints and nearby rejected values in detail.

The important habit is to predict the required behaviour first, then compare the program’s result with that prediction.

02 | READ THE REQUIREMENTS BEFORE CHOOSING VALUES

A value is not normal or abnormal in isolation. Its category depends on the requirements of the field or task being tested.

For this worked form, the mark must be supplied, must be a whole number and must lie from zero to fifty inclusive. A whole-number mark of 34 is acceptable; 500 is outside the permitted range.

For a temperature system, a negative number may be entirely acceptable. For an order quantity that must be from one to twenty, a negative quantity is unacceptable. Do not assume that negative always means abnormal.

Write down the rule, data type and expected response to failure. If the required behaviour is rejection with another input request, your test should check both the message and the retry, not only that the value was not stored.

When an example’s assumptions are limited to numeric input, non-numeric text is outside that small algorithm’s stated scope. Do not silently treat it as a fully implemented form.

03 | NORMAL DATA: ORDINARY ACCEPTABLE INPUT

Normal test data is valid data within the accepted requirements, used to check ordinary operation. For the mark form, 34 is a useful normal value.

The expected result is that it is accepted and used correctly. If the system stores the mark, it should store 34 against the intended student, not another value or record.

Normal does not mean “whatever people enter most often” or “the average value”. It means a suitable valid input for the task. Several different ordinary valid values may be useful tests.

For an exact six-character code requiring two uppercase letters and four digits, AB1234 is normal data. For an order quantity from one to twenty, 8 is normal data.

Accepted endpoints also meet the rules, but they are more specifically useful as extreme or boundary tests. Use a clearly ordinary interior value when a question asks for a normal example.

04 | ABNORMAL DATA: INPUT THAT SHOULD NOT BE ACCEPTED

Abnormal test data is data that does not meet the specified requirements. It is used to check the system’s handling of unacceptable input.

For the whole-number mark form, 500 violates the range. A value of 12.5 violates the whole-number rule. Text “hello” is not a numeric mark, and an empty required field violates presence.

These are different reasons for rejection. Testing only 500 does not exercise the type or presence handling.

The expected behaviour is a controlled response under the requirements, such as an explanatory message and a request to re-enter. A crash is not a successful rejection.

Choose clearly out-of-range values for introductory abnormal examples. The next lesson specifically examines values just outside the limits as boundary cases.

05 | A TEST CASE NEEDS MORE THAN AN INPUT

A test case describes the situation being checked. It includes the data, any required starting state and the expected result.

For a simple mark form, input 34 with the expected result “accept and store mark 34” may be enough to state the essential case. For a booking system, input alone is insufficient: whether a booking should be accepted depends on existing bookings and capacity.

A test record adds the actual result observed when the program runs and a conclusion such as pass or fail.

Expected results come from the requirements before running the test. Actual results are observations from the test run. They must not be invented or copied from the expectation column.

The table above is a proposed plan. It does not claim the tests have already been performed.

06 | WHY REJECTION CAN MEAN THE TEST PASSED

A test passes when the actual behaviour matches the expected behaviour. That includes correct rejection of abnormal input.

If the form is required to reject 500 and ask again, and it does exactly that, the test passes. “Input rejected” does not mean “test failed”.

If the form accepts 500, the abnormal test fails. If it crashes without the required handling, it also fails.

The actual results in this table are illustrative observations, not a report of a real deployed form.

Be precise about the level you are discussing: an input can fail validation while the system passes its rejection test.

07 | TRACE A RANGE RETRY BEFORE TESTING IT

This small pseudocode component expects every input to be a whole number and checks only the permitted range.

DECLARE Mark : INTEGER
// Assume each entry is a whole number
REPEAT
    INPUT Mark
    IF Mark < 0 OR Mark > 50
      THEN
        OUTPUT "Enter a mark from 0 to 50"
    ENDIF
UNTIL Mark >= 0 AND Mark <= 50
OUTPUT "Accepted: ", Mark

With input 34, the UNTIL condition is true immediately and the algorithm outputs “Accepted: 34”. With 500 followed by 34, the first input produces the retry message; the second meets the condition and is accepted.

For this component, 500 is abnormal because it violates the range assumption being checked. Letters and fractional text require additional input handling in a complete form, which this snippet does not implement.

A trace predicts what the instructions do. A test run checks the implemented behaviour. Comparing both with the requirements can help reveal whether the code or the intended rule needs attention.

08 | USE DIFFERENT ABNORMAL CASES FOR DIFFERENT RULES

A student code must be supplied and contain exactly two uppercase letters followed by four digits. AB1234 is a normal example.

AB123 has too few characters. AB12C4 puts a letter in a digit position. ab1234 violates the specified uppercase rule. Empty text violates the required-field rule.

These tests exercise different failure conditions. State which rule each case violates rather than simply calling all of them “wrong”.

AB9999 may pass the pattern. Whether it is registered is a separate requirement. It becomes an unacceptable test input for a record-existence check only when you know that it is not a registered code and the system requires a registered code.

09 | STATE MATTERS IN A BOOKING TEST

The club has capacity three and allows each student one booking. Before each independent test, specify its accepted-booking collection.

With S104 and S205 booked, a request from S306 should be accepted. With the same starting records, a request from S104 should be rejected as a duplicate.

With S104, S205 and S306 booked, a request from S407 should be rejected because the session is full.

A rejected request does not necessarily contain abnormal field data. S407 can be a perfectly valid identifier but a booking cannot be accepted in that starting state. Describe this as a rejection-path scenario rather than assuming every rejection is caused by malformed input.

This distinction keeps data categories separate from business decisions. A format check tests the code; booking rules also depend on stored state.

10 | KEEP TESTS INDEPENDENT OR RECORD THEIR SEQUENCE

If accepting S306 fills the club, a later booking test no longer starts from the original two-booking state. That change can alter its expected result.

For independent cases, reset the system to the stated starting records before each run. Alternatively, intentionally test a sequence and record how each step changes the state for the next.

Do not mix these approaches without explanation. A result may look wrong because the starting state differs from the test plan, not because the program’s logic is wrong.

For the mark retry, a test of 500 followed by 34 is deliberately a sequence: the rejection leads to replacement input. The test checks that both actions occur in the right order.

A repeatable test includes enough information for another person to recreate the situation and compare the same required behaviour.

11 | CHOOSE DATA THAT REVEALS MISTAKES

Suppose a total-and-count program receives three inputs of one. The total and count both equal three, so that data can hide an update that adds one instead of the input amount.

Inputs 4, 7 and 2 are more revealing: their total is 13 while their count is 3. These are normal data if they meet the input rules, but they distinguish two possible behaviours.

Likewise, one normal mark tests acceptance but not rejection. Several abnormal marks violating the same upper limit may add less evidence than cases covering range, type, presence and retry separately.

Test data should be selected for a reason. The goal is meaningful coverage of requirements and likely errors, not the largest possible table of repetitive inputs.

12 | CHECK OUTPUTS AND CHANGES TO STORED DATA

An error message is only part of the result. If the form rejects 500 but still saves it, the system has not met the rejection requirement.

For a normal mark, check the accepted value and record association. For an abnormal mark, check that unacceptable data is not used or stored and that the user can supply a replacement as required.

For a booking rejection, confirm that the accepted-booking count and identifiers remain unchanged. A duplicate should not create another accepted record.

A good expected result can therefore include output, data changes and control flow: “Display the range message, leave the stored mark unchanged and request replacement input.”

Use the level of detail appropriate to the system and the question. Do not claim that displaying the right message alone proves all required behaviour.

13 | EXPLAIN AND JUSTIFY YOUR CHOICE

If asked to give normal data, supply a concrete value such as 34 for a whole-number mark from zero to fifty. If asked to explain why it is suitable, state that it meets the type and range and exercises ordinary acceptance.

For abnormal data, give 500 and explain that it exceeds the upper limit, so the system should reject it and request a permitted replacement.

A useful test statement is: “Use 12.5 because the field requires an integer. The expected result is controlled rejection of the fractional entry rather than accepting it as a whole mark.”

Avoid vague examples such as “a normal number” or “incorrect data”. State the rule, the specific input and the expected response.

14 | WHAT NORMAL AND ABNORMAL TESTS DO NOT PROVE

Passing these tests gives evidence for the cases exercised. It does not prove that every possible input and every combination of state will behave correctly.

You still need accepted endpoints, values next to the limits and other relevant paths. Those extreme and boundary cases are the focus of the next lesson.

Testing also differs from validation and verification. Validation checks an input rule during operation; verification checks copying or entry. Testing deliberately supplies cases to check whether the system performs its required behaviour.

You should now be able to choose normal and abnormal data, justify each case and distinguish the validity of the input from the success of the test.