← VCE Data Analytics U4O1

Testing that a security control works

Try a security control with a realistic case, like a wrong password or restricted user, then record whether it behaved as expected.

Part of: VCE Data Analytics - U4O1 - Development and Evaluation — Module 50

Understanding Testing that a security control works in VCE Data Analytics U4O1

What it does: The restricted user is the realistic case, and the expected and actual outcomes are compared before recording Pass. Test a permission with the restricted user. A teacher account has more access, so it cannot show the restriction works. A backup is only proven when a restore works. Seeing that a file exists does not show it can be recovered. Recording the result lets others see what was tried and whether the control behaved as expected. A clear record states the case and the outcome, so it can be checked later. Even a pass should be recorded. It is the evidence that the control was tested.

Common mistakes: A login control is tested with a wrong password, because the expected result is 'Access denied'. A correct password would be allowed in, so it should be: case <- wrong password. A restricted user should not be able to delete the payroll file, so the expected result is 'Access denied'. It should be: expected <- Access denied.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Testing that a security control works to a class →

This module's key terms are also in a printable crossword (Modules 38–62) and word search (Modules 3–62).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
A student tests a login control. Which test is a realistic case?
Read the login page and assume it worksEnter a wrong password and check that access is refused
Matches
Test: log in with the correct password. Result: Pass, so the lockout control works.
↓
Testing with a correct password does not test the control. It needs a realistic failing case such as a wrong password.
Applying
Meanings
Term
control test
Meaning
Try a security control with a realistic case, like a wrong password or restricted user, then record whether it behaved as expected.
Practice
TEST: Restricted user tries to edit file
Testing
Gaps
login(wrongPassword) = "denied" THEN
Check Answer
Spots
1case <- correct password
2expected <- Access denied

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Woodland Hedgehog' badge — Import Master, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. A student tests a login control. Which test is a realistic case?
A. Read the login page and assume it works
B. Enter a wrong password and check that access is refused ✓
A control test uses a realistic case, such as a wrong password, and checks the actual behaviour.
2. A permission is set so Year 9 students can only read a marks file. How do you test it?
A. Log in as a Year 9 student and try to edit the file ✓
B. Log in as the teacher and open the file
Test a permission with the restricted user. A teacher account has more access, so it cannot show the restriction works.
3. Which is the best way to test a backup?
A. Check that the backup file exists on the drive
B. Restore the backup and check the files open and are complete ✓
A backup is only proven when a restore works. Seeing that a file exists does not show it can be recovered.
4. After a control test, what should you record?
A. The test case, the expected result and the actual result ✓
B. Only the word 'done'
Recording the result lets others see what was tried and whether the control behaved as expected.
5. A restricted user could delete a file during a permission test. What does this show?
A. The control failed and needs fixing ✓
B. The control passed because the test ran
Expected: delete refused. Actual: delete allowed. The result does not match, so the control failed.

Match the Pairs

Test: log in with a wrong password. Expected: access denied. Actual: access denied. Result: Pass → A recorded control test: a realistic case was tried, the expected and actual outcomes were compared, and the result was logged.
Restore test: restore backup to a spare folder, then open files. Result: Fail, 3 files corrupt → A backup restore test that found a fault, because the restored files did not work as expected.
Testing a permission: sign in as a read-only user and try to change a file, then check that the change is blocked → user = read_only; action = edit file; expected = denied; actual = denied; result = Pass
Recording the result of a control test so the evidence can be reviewed later → Date: 12 May | Control: MFA | Expected: code required | Actual: code required | Result: Pass
Test: log in with the correct password. Result: Pass, so the lockout control works. → Testing with a correct password does not test the control. It needs a realistic failing case such as a wrong password.
Backup control: backup job ran last night, so it works. Result: Pass (no restore tried) → The backup was never restored, so nobody knows whether the data can be recovered.

Key Term

control test
Try a security control with a realistic case, like a wrong password or restricted user, then record whether it behaved as expected.

Fill in the Blanks

1. IF login(wrongPassword) = "denied" THEN result ← "Pass" ENDIF
Hint: Type the keyword that starts a decision comparing the control's behaviour with what was expected.
2. attempt ← write("restricted", "payroll") expected ← "denied" IF attempt = expected THEN result ← "Pass"
Hint: Type the variable name that holds the outcome the restricted user should get.
3. copy ← restore(backupFile) IF rows(copy) = rows(original) THEN result ← "Pass"
Hint: Type the function name that brings data back from a backup file.
4. IF actual = expected THEN result ← "Pass" ELSE result ← "Fail" OUTPUT testId, result
Hint: Type the keyword for the path taken when the control did not behave as expected.
5. testId ← "T3" result ← "Pass" OUTPUT testId, result
Hint: Type the keyword that writes the test result out so it is recorded.

Spot the Error

Question 1
A case <- correct password
B expected <- Access denied
C actual <- Access denied
D IF actual = expected THEN
E result <- PASS
Line A — A login control is tested with a wrong password, because the expected result is 'Access denied'. A correct password would be allowed in, so it should be: case <- wrong password.
Question 2
A user <- restricted user
B expected <- Access granted
C action <- delete payroll file
D actual <- Access denied
Line B — A restricted user should not be able to delete the payroll file, so the expected result is 'Access denied'. It should be: expected <- Access denied.
Question 3
A backup <- latest backup
B restore backup to live server
C count restored files
D result <- PASS
Line B — A restore test should be done on a separate test server so live data is not overwritten if something goes wrong. It should be: restore backup to test server.
Question 4
A user <- admin account
B action <- open admin page
C expected <- Access denied
D actual <- Access denied
Line A — To test that the permission blocks unauthorised users, the test must use a guest account. An admin is meant to have access, so it should be: user <- guest account.
Question 5
A expected <- Access denied
B actual <- Access granted
C result <- PASS
D log the result and date
Line C — The actual result (Access granted) did not match the expected result (Access denied), so the control failed the test. It should be: result <- FAIL.

Student with a class code? Join your class →