ACARA Digital Technologies Years 9–10 — Testing and Validating Programs Hangman

The 65 key terms

1validate a program

To prove a program gives the correct output for its problem by running or tracing it against test cases. Running without errors is not proof; it is only as validated as its tests.

2test case

A chosen input paired with the output you expect. Run the algorithm, record the actual output, then compare: if actual matches expected it passes, otherwise it fails.

3expected output

The correct result of a test case, worked out by hand from the specification before running the code. Never copy it from the program's own output, or the test proves nothing.

4normal, boundary and invalid data

A good test set uses normal data (typical values), boundary data (values at the edges of a range) and invalid data (values that should be rejected), so every path in an algorithm is checked.

5Normal test data

A typical, valid value well inside the allowed limits, which the program should accept. Example: an age of 30 for a range check of 0 to 120 is accepted.

6Boundary values

Test inputs at the edge of a condition. For age >= 18, test 17 (just below), 18 (exactly on) and 19 (just above) to check the algorithm picks the right path at the edge.

7Abnormal test data

Test data of the wrong type or outside the allowed values, such as -5 or letters for an age, or an empty input. The program should reject it.

8extreme vs boundary data

Extreme data is only the accepted limit values, e.g. 1 and 100. Boundary data has those plus the rejected values next to them: 0, 1, 100 and 101 for a range of 1 to 100.

9Range check test data

Pick one normal, abnormal, extreme and boundary value for the range and say accept or reject. For 0 to 100: 50 normal, -5 abnormal, 100 extreme, 101 boundary.

10test data

Values chosen to test each validation rule: empty for existence, text for type, and values just inside and just outside range limits, each with an expected result.

11LENGTH(Password) >= 8

Test data for a check includes values that pass and fail it: for an 8-character minimum, 8 characters is accepted, 7 is rejected, and an empty string fails a presence check.

12edge case

An unusual but allowed input, such as an empty list, a one-item list, repeated values, or the maximum at the start or end, that you test because it can break code.

13truth table

A table listing every True/False combination of the parts in an and/or/not condition. Use it to pick test inputs that make each part True and False, then check each result.

15test coverage

Testing so that every if/elif/else branch runs at least once and every loop is tried running zero times, once and many times. Any code never run is untested.

16dry run

Working through an algorithm by hand, line by line, using chosen test data as inputs and recording each step in a trace table, to see what it does and find logic errors without running it.

17Trace table

A table that records the value of each variable at every step of an algorithm, used to check its logic by hand.

18one column per variable

To set up a trace table, give each variable its own column in the order they first appear, then add a row each time a value changes. Leave unchanged cells blank.

19Counter ← Counter + 1

When tracing, work out the right side using the current values, then write the result in that variable's column. The old value is used first, then replaced by the new one.

20IF Mark >= 50 THEN

To trace an IF, work out if the condition is TRUE or FALSE for the current values, then follow only the THEN or ELSE path. Skipped statements get no row in the trace table.

21FOR Count ← 1 TO 5

To trace a FOR loop, give the loop variable each value from start to end in turn, run the loop body once for each value, and record every pass in its own row of the trace table.

22WHILE and REPEAT loop trace

Trace a loop by testing its condition each pass: WHILE tests before the body and may never run; REPEAT tests after the body so runs once at least. Stop when the loop ends.

23Count ← Count + 1

Trace table for counting and totalling: Count and Total start at 0 in the first row, change each pass (Count only if the IF is true), and the final values are output after the loop.

24nested loop

A loop inside another loop. When tracing, the inner loop completes all its repeats for each single repeat of the outer loop, so total passes = outer repeats x inner repeats.

25SumSquare(10, 20)

Tracing a call: follow the function's statements to RETURN, then replace the call with the returned value (here 500) and finish evaluating the expression.

27trace a flowchart

Follow a flowchart from Start to Stop using test values, noting each diamond's Yes or No answer in a trace table and following loop arrows back until Stop.

29trace vs output

Run the code with the same input you traced, then compare. If the real output differs from your trace, either the trace or the code has a mistake, so re-trace.

41count += 1

Set count = 0 before a loop, then use count += 1 inside it to add 1 each repeat. Use total += value to build a running total.

44if value.strip() == '':

An existence check tests that a value was actually entered. strip() removes spaces, so this is True for empty or space-only input, and an error message can be shown.

45type check

A check that input is the expected data type, using .isdigit(), try/except around int() or float(), or isinstance(). input() is always text, so check before converting.

461 <= age <= 120

A range check: tests that a number lies between a minimum and a maximum (inclusive here). Values outside the limits, such as 0 or 121, are rejected as invalid.

48while not valid:

A loop that keeps asking for input again until the answer is valid, so bad data (like an age of -5) can't get into your program. Show an error message each time.

49def is_valid_age(text):

A validation function that runs the existence, type and range checks in order and returns True or False, so the same checks can be reused for many inputs and tested.

50test table

A table with one row per test case. Its columns are test number, purpose, input, expected result, actual result and pass or fail.

51Pass or Fail

Copy the actual result exactly as the program gave it, then mark Pass only if it matches the expected result, otherwise Fail. Never change the expected result to fit, and add a note for fails.

52test plan

A list, made before testing, of normal, boundary and invalid test cases for each requirement, with the expected result for every test.

53test first

Write test cases and expected results from the requirements before coding, so they check what the program should do, not what your code does. Rerun them as it grows.

55input()

Pauses a program so you can type a test value; it returns text. Test by typing each planned input in order, then compare the printed output with the expected result.

56tests = [(5, 25), (0, 0)]

A list of (input, expected) tuples. Each tuple is one test case, so a loop can run many tests stored in one variable. Add a new tuple to add a new test.

57for value, expected in tests:

Loops over each (input, expected) tuple in tests, unpacking it into two variables. Then you call the function, compare actual to expected, and print PASS, or FAIL with both values.

58assert

Checks a condition is True, like assert add(2, 3) == 5. If the result is not what you expected, it raises an AssertionError, so test cases can run automatically.

59round(actual, 2) == expected

Floats can be slightly inexact (0.1 + 0.2 is not 0.3), so round the actual result to a set number of decimal places before comparing it with the expected value.

60assert not is_valid(-5)

Tests that bad input is rejected: call the validator with an invalid value and assert it returns False. If an error is expected, use try/except; no error means the test fails.

61unit testing

Testing one function or class on its own, with its own test table, before joining it to the rest of the program, so a failing test points to that module.

63requirements checklist

A list of every functional requirement and success criterion. You test the solution against each one, then record yes or no and note your evidence, such as what you saw or a screenshot.

64test report

A summary of how many tests passed and failed, what was fixed and retested, and a conclusion on whether the program is validated, backed by the results and any limitations.

65error in an algorithm

A mistake that breaks pseudocode rules or gives wrong results. Find it by reading the code, then trace it with test values and compare the actual output with the expected output.

66Traceback (most recent call last):

The start of Python's error report. It names the error type (like NameError) and the line number where it happened, so you know where to start looking for the bug.

67runtime error

An error that stops a program while it runs, shown as a named error like NameError, ValueError or ZeroDivisionError. Read the message to find the problem.

68IndexError

A runtime error raised when code uses an index that is not in the list, such as items[5] in a 5-item list. The last valid index is len(items) - 1.

69TypeError

A runtime error when an operation gets the wrong data types, like '5' + 3 (string plus integer). Fix it by converting with int() or str(), e.g. int(input()).

70ZeroDivisionError

A Python runtime error raised when a number is divided by 0, or a remainder is taken with % 0. Guard against it with an if check or try/except.

71logic error

A mistake that lets a program run with no error message but give the wrong result, caused by a wrong condition, operator (> or >=), range() off by one, or steps in the wrong order.

72Age >= 18

Using > instead of >= (or < instead of <=) is a logic error: the boundary value, such as Age 18, is wrongly rejected. Test the boundary value, then correct the operator.

73off-by-one error

A FOR loop with the wrong start or end value runs one time too many or too few, e.g. TO 9 instead of TO 10, or starting at 0 for a 1-based array. Check the bounds with a trace table.

74Total ← 0

Set a total or counter to 0 before the loop. If you forget, it starts from an unknown value; if you put it inside the loop, it resets every time.

75first wrong value

In a trace table, the first row where a value differs from what you expected points to the faulty line of the algorithm. Look at that line, then suggest a correction.

76print("total =", total)

A debug print. Add a line like this to show a variable's value while the program runs, so you can spot where it goes wrong. Put one inside a loop to watch it change, then remove it once fixed.

77print(variable)

Debugging tool: print a variable at key points, then compare each value with your trace table of what it should be. The first mismatch shows where the bug is.

78breakpoint

A marker set on a line of code (click beside the line number) that pauses the program there in debug mode, so you can inspect variables and step through the code.

79step through

Run paused code one line at a time using step over, step into or step out, while the watch panel shows each variable change, to find where a value goes wrong.

80# (commenting out)

Putting # in front of a line, or a selected block, stops Python running it. Use this to isolate a bug, then remove the # to restore the code.

81Line 3 should be Total ← 0

To suggest a correction, name the wrong line or symbol, say why it is wrong, write the corrected statement, and explain what the fix changes in the algorithm's output.

82corrective action

The fix recorded in a testing table for a failed test, followed by the retest result that shows whether the fix worked (pass or fail).

83regression testing

After fixing a bug, rerun the failed test and all earlier tests, because a fix can break code that used to pass.

84modify code

Read and trace the code first to see what it does, then change one small part at a time and re-run your test cases to check the effect of that change.