ACARA Digital Technologies Years 9–10 Word Scramble: Testing and Validating Programs (Modules 591–622)
Name:
Date:
Class:
🔤
Word scramble
Unscramble the letters and write each key term on the line.
1
ESTT LANP
A list, made before testing, of normal, boundary and invalid test cases for each requirement, with the expected result for every test.
2
STTE RTIFS
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.
3
UNTIP()
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.
4
ESSTT = [(5, 52), (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.
5
CRNDU(ALTAUO, 2) == TDECEXEP
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.
6
SASETR TNO DA_IL5SV(-I)
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.
7
ETST EAGCVOER
Test cases are enough when they use normal, boundary and invalid data and run every branch and loop. Missing any leaves the program only partly validated, and passing tests never prove no bugs.
8
STTE PREROT
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.
9
IERRESOGSN STNGTEI
After fixing a bug, rerun the failed test and all earlier tests, because a fix can break code that used to pass.
Answer Key
ACARA Digital Technologies Years 9–10 · Modules 591–622
1ESTT LANP → test plan — A list, made before testing, of normal, boundary and invalid test cases for each requirement, with the expected result for every test.
2STTE RTIFS → test 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.
3UNTIP() → input() — 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.
4ESSTT = [(5, 52), (0, 0)] → tests = [(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.
5CRNDU(ALTAUO, 2) == TDECEXEP → round(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.
6SASETR TNO DA_IL5SV(-I) → assert 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.
7ETST EAGCVOER → test coverage — Test cases are enough when they use normal, boundary and invalid data and run every branch and loop. Missing any leaves the program only partly validated, and passing tests never prove no bugs.
8STTE PREROT → test 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.
9IERRESOGSN STNGTEI → regression testing — After fixing a bug, rerun the failed test and all earlier tests, because a fix can break code that used to pass.