Test Case Design

Testing is not the same as trying random inputs. A good test case is chosen because it checks a specific requirement or likely failure.

You can read this note directly if you know Boolean functions and basic assertions. The central idea is that expected behaviour should be decided before the program is trusted.

Each test case should state:

• the input data;
• the expected output or behaviour;
• the reason for choosing the case.

Caption: A complete test case states one input, its expected result, and why the case was chosen.

Test Data Versus Test Case

Test data is only the input. A test case is the complete planned check.

Item	Example
test data	"101"
expected result	rejected
reason	above the permitted mark range

A useful test record may also include the actual result and whether the test passed.

Input	Expected	Actual	Pass?
"101"	rejected	rejected	yes

In exam answers, always include the expected result. Otherwise it is unclear what the test is meant to prove.

Normal Data

Normal data is valid, typical data that should be accepted.

For a mark validator with a valid range from 0 to 100:

50

is normal data.

More examples:

Rule	Normal data
mark from 0 to 100	50
8-digit phone number	"81234567"
required name	"Aisha"

A normal case shows that the program handles ordinary valid input.

Extreme Data

Extreme data is valid data at the edge of an allowed range.

If the valid mark range is 0 to 100 inclusive, the extreme values are:

0 and 100

Extreme cases are important because boundary conditions are often implemented incorrectly.

Rule	Extreme valid data	Abnormal data just outside
0 to 100 inclusive	0, 100	-1, 101
1 to 10 inclusive	1, 10	0, 11

The values just outside the range are useful abnormal cases, but they are not extreme data because they are invalid.

Abnormal Data

Abnormal data is invalid data that should be rejected or handled safely.

Examples for a mark entered as text include:

"-1"
"101"
"abc"
""
"   "

Abnormal input should not be expected to crash a well-designed program. The expected behaviour should state how the program rejects or handles it.

Different abnormal cases test different risks:

Input	Risk tested
"-1"	below valid range
"101"	above valid range
"abc"	wrong type or format
""	missing input
" "	whitespace-only input

Worked Example: Mark Validation

Function under test:

def valid_mark_text(text):
    text = text.strip()
 
    if text == "":
        return False
 
    try:
        mark = int(text)
    except ValueError:
        return False
 
    return 0 <= mark <= 100

Test table:

Test type	Input	Expected	Reason
normal	"50"	True	typical valid mark
extreme	"0"	True	lower valid boundary
extreme	"100"	True	upper valid boundary
abnormal	"-1"	False	below valid range
abnormal	"101"	False	above valid range
abnormal	"abc"	False	cannot be converted to an integer
abnormal	""	False	no input
abnormal	" "	False	whitespace-only input

This version deliberately uses try and except because str.isdigit() rejects signed integer text such as "-1" before a range check can be applied.

Assertions as Executable Tests

assert valid_mark_text("50") is True
assert valid_mark_text("0") is True
assert valid_mark_text("100") is True
assert valid_mark_text("-1") is False
assert valid_mark_text("101") is False
assert valid_mark_text("abc") is False
assert valid_mark_text("") is False

Assertions make the expected result explicit. If one fails, Python stops at that line and helps locate which requirement is not satisfied.

Choosing Tests Systematically

For an inclusive numeric range, choose:

• one typical valid value;
• the lower valid boundary;
• the upper valid boundary;
• one value just below the lower boundary;
• one value just above the upper boundary;
• wrong-format or missing input when the input is received as text.

For a format requirement, choose:

• a correctly formatted value;
• too few characters;
• too many characters;
• a wrong separator;
• invalid characters;
• blank input.

For a length requirement, test:

• a typical valid length;
• the minimum valid length;
• the maximum valid length;
• one below the minimum;
• one above the maximum.

Worked Example: Password Length

Rule:

A password must contain from 8 to 12 characters inclusive.

Test type	Input	Expected	Reason
normal	"secure10"	accepted	typical valid length
extreme	"12345678"	accepted	minimum valid length
extreme	"123456789012"	accepted	maximum valid length
abnormal	"1234567"	rejected	one character too short
abnormal	"1234567890123"	rejected	one character too long
abnormal	""	rejected	blank input

Matching function:

def valid_password_length(password):
    return 8 <= len(password) <= 12

From Testing to Debugging

When a test fails:

1. compare the actual result with the expected result;
2. reproduce the failure consistently;
3. trace the relevant variables and conditions;
4. correct the cause;
5. rerun the failed case and related cases.

A test case is therefore not only evidence of correctness. It is also a tool for locating faults.

Paper 1 and Paper 2 Emphasis

For written questions, explain why each value is normal, abnormal, or extreme and state the expected result.

For practical work, construct a test table, run the program, record actual results, and investigate failures.

Common Mistakes

• Giving input values without expected results.
• Testing only normal data.
• Treating valid extreme data as invalid.
• Calling values just outside the range “extreme.”
• Forgetting blank or wrong-format input.
• Choosing several test values that all check the same condition.
• Writing tests only after the program appears finished.

Check Your Understanding

1. What is normal test data?
2. What are the extreme values for a range of 1 to 10 inclusive?
3. Is 0 normal, abnormal, or extreme for a valid range of 0 to 100?
4. Why should a test table include expected output?

Answers:

1. Valid data typical of ordinary use.
2. 1 and 10.
3. Extreme, because it is a valid boundary.
4. The expected output provides the standard used to decide whether the program passed the test.

Related Notes

• Data Validation, Testing, and Debugging
• Validation and Verification
• Errors and Debugging