Why is "Writing validation as a single `IF` statement that displays a message but never re-requests the input." a common mistake in Robust and secure programming?

Why it happens: The `IF` correctly detects the problem and produces an error message, which feels like the whole job — students do not picture what happens on the very next line, where the invalid value is still sitting in the variable. How to avoid it: Validation must **loop**: use `REPEAT … UNTIL ` so the input is requested again until it passes. Then trace your own routine with a deliberately invalid value and follow what happens next — you will see the bad value being used anyway. Detection without re-asking is not validation. Source: AQA 8525 specification 3.2.11 requires students to write simple data validation routines; single-IF 'validation' is the most common fault in this subtopic.

Why is "Giving only two boundary values — 1 and 10 for a range of 1 to 10 — instead of all four." a common mistake in Robust and secure programming?

Why it happens: The limits themselves are the obvious 'edge' values, and it is easy to overlook that the values just **outside** the range are equally part of the boundary test. How to avoid it: Boundary data comes in **pairs around each limit**, so a range with two limits needs **four** values. AQA's own example is explicit: for the range 1 to 10, boundary data is **0, 1, 10, 11**. The pair inside confirms valid values are accepted; the pair outside confirms invalid ones are rejected. Source: AQA 8525 specification 3.2.11 additional information gives 0, 1, 10, 11 as the worked example.

Why is "Classifying a number just outside the allowed range as erroneous data." a common mistake in Robust and secure programming?

Why it happens: Both boundary-outside data and erroneous data get rejected, so they feel like the same category — the classification is based on the outcome rather than on the data itself. How to avoid it: The deciding factor is the **data type**, not whether it is accepted. For a range of 1 to 10, **11 is boundary data** — a perfectly valid whole number that simply falls outside the range. **Erroneous data is the wrong type entirely**, such as the word `'seven'` or an empty entry. Source: Test-data questions frequently ask for one item of each type specifically to test this distinction.

Why is "Listing test data without justifying why each value was chosen." a common mistake in Robust and secure programming?

Why it happens: Producing the correct values feels like the substance of the answer, and the justification looks like restating the obvious — so it gets omitted under time pressure. How to avoid it: The specification requires you to **select and justify** test data. A justification says **what the test would catch**: not '1, because it is a boundary value' but '1, because it is the lowest allowed value, so it would reveal a programmer using `>` instead of `≥`'. Always state the **expected result** too — a test with no expected outcome cannot fail. Source: AQA 8525 specification 3.2.11: 'Be able to select and justify the choice of suitable test data for a given problem.'

Why is "Labelling a wrong operator or a wrong comparison as a syntax error." a common mistake in Robust and secure programming?

Why it happens: The code is visibly wrong to a human reader, so it feels 'broken' — and 'syntax error' is the more familiar term, so it becomes the default label for anything faulty. How to avoid it: Ask one question: **would the program run?** If it runs and simply gives the wrong answer, it is a **logic error**, however obviously mistaken the line looks. A syntax error means the code is not valid in the language at all, so the translator refuses to process it and execution never begins. Source: AQA 8525 specification 3.2.11 requires students to identify and categorise errors as syntax or logic.

Why is "Writing an authentication check as `username = STORED_USER OR password = STORED_PASS`." a common mistake in Robust and secure programming?

Why it happens: Read aloud, 'if the username or the password matches' sounds reasonable, and because the routine grants access to a correct login it appears to work during casual testing. How to avoid it: **Both** credentials must match, so the operator is `AND`. Test the faulty version deliberately with a correct username and a wrong password: the `OR` version grants access, which is a serious security flaw. If either half alone is enough, the password is doing no work at all. Source: Authentication routines are named in 3.2.11, and OR-instead-of-AND is a standard fault in error-identification questions.

AQA GCSE Computer Science (8525)

Robust and secure programming

0% Complete

Detailed Study Notes

Detailed notes on Programming for AQA GCSE Computer Science, covering key concepts, explanations, examples, and exam-focused revision points.

Robust and Secure Programming — AQA GCSE Computer Science 8525 (3.2.11)

The subtopic that ties the whole of Unit 3.2 together, and one of the most reliably examined. AQA names three specific validation routines (minimum length, empty string, range), requires plain-text authentication only, and defines three types of test data — normal, boundary and erroneous — with a worked example: for the range 1 to 10, boundary data is 0, 1, 10, 11. You must also select and justify test data, and categorise errors as syntax or logic. Every one of those is a named, examinable item.

At a glance

Validation checks that entered data is sensible and allowed before the program uses it.
AQA names three validation routines: minimum length, empty string, and range (e.g. between 1 and 10).
Validation must loop — detecting bad input without re-asking achieves nothing.
Authentication uses a username and password. AQA requires plain text only — encryption is NOT needed at GCSE.
Three types of test data: normal (typical), boundary (extreme), erroneous.
Boundary data sits either side of each limit — for the range 1 to 10, that is 0, 1, 10, 11.
Erroneous data is data of the wrong type or form that should be rejected — e.g. letters where a number is expected.
You must select and justify suitable test data for a given problem.
Syntax error = breaks the rules of the language; the program will not run.
Logic error = the program runs but produces the wrong result — far harder to find.

What you’ll learn

Mapped to the AQA GCSE 8525 syllabus (2027-2029).

Be able to write simple data validation routines, including checking minimum string length, checking if a string is empty, and checking data lies within a given range.
Be able to write simple authentication routines using a username and plain text password (encryption is not required).
Understand what is meant by testing in the context of algorithms and programs, and be able to correct errors.
Understand what test data is and describe normal (typical), boundary (extreme) and erroneous test data.
Be able to select and justify the choice of suitable test data for a given problem.
Understand that there are different types of error — syntax and logic — and be able to identify and categorise errors within algorithms and programs.

Data validation routines

Three named checks — and every one of them must loop until the input is valid.

Validation checks that data entered by a user is sensible and allowed before the program uses it.

⚠️ Validation cannot tell whether data is correct. If a user types their age as 35 when they are really 34, no validation rule can detect it — 35 is a perfectly reasonable age. Validation checks that data is plausible, not that it is true. Making that distinction is a strong AO3 point.

The three routines AQA names

The specification lists these three explicitly as examples of simple validation routines:

1. Minimum length check

REPEAT
    OUTPUT 'Enter a password of at least 8 characters'
    password ← USERINPUT

    IF LEN(password) < 8 THEN
        OUTPUT 'Too short — must be at least 8 characters'
    ENDIF
UNTIL LEN(password) ≥ 8

2. Empty string check

REPEAT
    OUTPUT 'Enter your name'
    name ← USERINPUT

    IF LEN(name) = 0 THEN
        OUTPUT 'You must enter something'
    ENDIF
UNTIL LEN(name) > 0

3. Range check — the specification's own example is "between 1 and 10"

REPEAT
    OUTPUT 'Enter a number between 1 and 10'
    num ← STRING_TO_INT(USERINPUT)

    IF num < 1 OR num > 10 THEN
        OUTPUT 'Invalid — must be between 1 and 10'
    ENDIF
UNTIL num ≥ 1 AND num ≤ 10

The rule that carries the most marks: validation must LOOP

# WRONG — detects the error, then uses the bad value anyway
IF mark < 0 OR mark > 100 THEN
    OUTPUT 'Invalid'
ENDIF
total ← total + mark        # the invalid mark is still added

# RIGHT — keeps asking until the input is valid
REPEAT
    mark ← STRING_TO_INT(USERINPUT)
UNTIL mark ≥ 0 AND mark ≤ 100
total ← total + mark

A single IF detects the problem but never fixes it. Because a value must be obtained before it can be tested, validation naturally uses condition-at-the-end iteration (3.2.2).

AQA tip. Note the two conditions in a validation loop are opposites: the IF inside describes the invalid state (using OR) and the UNTIL describes the valid state (using AND). Inverting a compound condition flips every operator and swaps AND ↔ OR (3.2.5).

Validation checks data is sensible and allowed — not that it is correct.
The three named routines: minimum length, empty string, range check.
Validation must LOOP — a single IF detects but does not fix.
Condition-at-the-end iteration is the natural structure, since input must be obtained before it can be tested.
The inner IF states the invalid condition (OR); the UNTIL states the valid one (AND).

See the full worked example for robust and secure programming →

Authentication routines

Username and password, plain text only. Encryption is explicitly not required.

Authentication checks that a user is who they claim to be, normally with a username and password.

The specification is unusually explicit about the boundary:

"Students will only be required to use plain text usernames and passwords (ie students will not need to encrypt the passwords)."

So at GCSE, comparing a typed password directly against a stored one is exactly what is expected.

A basic authentication routine

CONSTANT STORED_USER ← 'admin'
CONSTANT STORED_PASS ← 'letmein'

OUTPUT 'Enter username'
username ← USERINPUT

OUTPUT 'Enter password'
password ← USERINPUT

IF username = STORED_USER AND password = STORED_PASS THEN
    OUTPUT 'Access granted'
ELSE
    OUTPUT 'Access denied'
ENDIF

Note the AND. Both the username and the password must match. Using OR would grant access to anyone who got either one right — a catastrophic security flaw and a favourite exam fault.

With a limited number of attempts

This is the version that appears in higher-tariff questions:

attempts ← 0
access   ← False

WHILE attempts < 3 AND access = False
    OUTPUT 'Enter username'
    username ← USERINPUT
    OUTPUT 'Enter password'
    password ← USERINPUT

    attempts ← attempts + 1

    IF username = STORED_USER AND password = STORED_PASS THEN
        access ← True
    ELSE
        OUTPUT 'Incorrect — attempt ', attempts, ' of 3'
    ENDIF
ENDWHILE

IF access = True THEN
    OUTPUT 'Access granted'
ELSE
    OUTPUT 'Locked out'
ENDIF

The compound loop condition attempts < 3 AND access = False is doing two jobs: it stops after three failures and exits immediately on success. With AND, either part becoming false ends the loop.

Why real systems do more (worth a sentence in evaluation questions)

Storing passwords in plain text means anyone who reads the file can see every password. Real systems store an encrypted or hashed version instead. You are not required to know encryption here — but noting the limitation shows genuine understanding, and links to 3.6 cyber security.

AQA tip. Keep the case-sensitivity point in mind: 'Admin' and 'admin' are different strings (3.2.4). For a username that is usually undesirable; for a password it is deliberate and correct.

Authentication checks a user is who they claim to be, using a username and password.
AQA requires PLAIN TEXT only — encryption is explicitly not needed.
Both username AND password must match — using OR is a serious security flaw.
Attempt-limited versions use a compound condition: attempts < 3 AND access = False.
Plain-text storage is a real weakness worth noting in evaluation answers.

See the full worked example for robust and secure programming →

Testing and the three types of test data

Normal, boundary and erroneous — with AQA's own worked example of boundary data.

Testing means running a program with chosen data to check it behaves as expected, so that errors can be found and corrected.

The three types

Type	What it is	Should the program…
Normal (typical)	Sensible data the program will meet in ordinary use	Accept it and process it correctly
Boundary (extreme)	Values at the very edges of what is allowed, and just outside	Accept those inside, reject those outside
Erroneous	Data of the wrong type or form entirely	Reject it without crashing

Boundary data — AQA's own example

The specification states it directly:

"If the allowed range is 1 to 10, then boundary data is 0, 1, 10, 11, ie either side of the allowed boundary."

Boundary data always comes in pairs around each limit, which is why a range with two limits needs four boundary values.

Why boundary data matters most. It is precisely the data that exposes a < written where ≤ was needed (3.2.4). Testing with 5 would pass under either version; only testing 1 and 10 reveals the error.

Erroneous data is not the same as boundary data

This is the distinction most often confused:

Boundary: a number just outside the allowed range — 0 or 11. Still the right type, just not permitted.
Erroneous: the wrong type or form entirely — the word 'seven', an empty entry, a symbol.

For a range of 1 to 10, 11 is boundary data, not erroneous data — it is a perfectly valid integer that simply falls outside the range.

AQA tip. When asked to give test data, present it as a table with three columns: the value, its type, and the expected result. That structure earns the marks and makes omissions obvious.

Testing runs a program with chosen data to check it behaves as expected.
Normal (typical) data should be accepted; boundary and out-of-range should be handled correctly.
For the range 1 to 10, boundary data is 0, 1, 10, 11 — either side of each limit.
Erroneous data is the wrong TYPE (e.g. 'seven'); 11 is boundary, not erroneous.
Boundary data is what exposes < versus ≤ errors.

See the full worked example for robust and secure programming →

Selecting and justifying test data

An explicit requirement: choose the data AND say why each value was chosen.

The specification requires students to "select and justify the choice of suitable test data for a given problem." The justification is what most answers omit.

The structure that scores

Test data	Type	Reason for choosing it	Expected result
5	Normal	A typical value in the middle of the allowed range	Accepted
1	Boundary	The lowest allowed value — checks `≥` was used, not `>`	Accepted
10	Boundary	The highest allowed value — checks `≤` was used, not `<`	Accepted
0	Boundary	Immediately below the lower limit	Rejected
11	Boundary	Immediately above the upper limit	Rejected
'seven'	Erroneous	The wrong data type — a word, not a number	Rejected without crashing

A justification explains what the test would catch. Compare:

❌ "1, because it is a boundary value." (states the type, explains nothing)
✅ "1, because it is the lowest value that should be accepted — if the programmer wrote > 1 instead of ≥ 1 this test would reveal it."

Choosing test data for a specific problem

For a program accepting a percentage (0–100):

Normal: 45, 78 — ordinary values that should be accepted.
Boundary: −1, 0, 100, 101 — either side of each limit.
Erroneous: 'fifty', '', '50%' — wrong type or form.

Note −1 rather than just 0: the lower limit is 0, so the value immediately below it is −1.

Why you cannot test everything

You cannot try every possible input, so test data is chosen to represent categories of input while keeping the number of tests manageable. Boundary values are prioritised because they are where errors cluster.

AQA tip. Always state the expected result alongside each value. A test with no expected outcome cannot fail — you would have nothing to compare the actual behaviour against.

You must select AND justify test data — the justification is what most answers miss.
A justification says what the test would catch, not just what type it is.
Present test data as a table: value, type, reason, expected result.
For a 0–100 range the lower boundary values are −1 and 0.
Always state the expected result — a test with no expected outcome cannot fail.

See the full worked example for robust and secure programming →

Syntax errors and logic errors

Syntax = it will not run. Logic = it runs but is wrong. Be able to categorise both.

The specification requires you to understand the two types of error and to identify and categorise errors within algorithms and programs.

Syntax error

An error that breaks the rules (grammar) of the programming language, so the program will not run at all.

The translator (compiler or interpreter, 3.4.4) detects it and reports it before execution.

IF x > 5                    # missing THEN
OUTPUT 'Hello               # missing closing quotation mark
FOR i ← 1 TO 10             # missing ENDFOR
prnt('Hello')               # misspelled keyword

Key point: the program cannot run. You are told where the problem is, which makes syntax errors comparatively easy to fix.

Logic error

An error where the program runs successfully but produces the wrong result.

The syntax is perfectly legal, so nothing is reported — the program simply does the wrong thing.

average ← a + b / 2              # precedence — should be (a + b) / 2
IF age > 18 THEN                 # should be ≥ 18 — excludes exactly 18
FOR i ← 0 TO LEN(a)              # off-by-one — reads past the end
IF mark ≥ 0 OR mark ≤ 100 THEN   # should be AND — accepts everything
total ← total - price            # should be + — wrong operator

The comparison table

	Syntax error	Logic error
Cause	Breaks the language's rules	The instructions are legal but wrong
Does the program run?	No	Yes
Reported by the translator?	Yes	No
How it is found	The error message tells you	Testing and tracing
Difficulty	Easier — you are told where	Much harder — you must notice the output is wrong

Why logic errors are more dangerous. A syntax error stops you immediately. A logic error lets a program run for months producing subtly wrong results — an incorrect grade boundary, a slightly wrong total — with nothing to draw attention to it. Making that point is a strong AO3 observation.

Categorising errors in an exam

Ask one question: would the program run?

No → syntax error.
Yes, but the answer is wrong → logic error.

IF x = 5 THEN
    OUTPUT 'Five'
# no ENDIF                        → SYNTAX (will not run)

IF x = 5 THEN
    OUTPUT 'Four'
ENDIF                             → LOGIC (runs, wrong output)

AQA tip. A third category, the runtime error (such as dividing by zero or an out-of-range array index), causes a crash during execution. The specification names only syntax and logic, so use those two terms — but if a question describes a crash mid-run, an out-of-range index is usually a logic error in the loop bounds.

Syntax error = breaks the language's rules; the program will not run; the translator reports it.
Logic error = the program runs but gives the wrong result; nothing is reported.
To categorise, ask: would the program run at all?
Logic errors are far more dangerous because nothing draws attention to them.
The specification names only syntax and logic — use those two terms.

See the full worked example for robust and secure programming →

Quick recap

Validation checks entered data is sensible and allowed — it cannot check the data is true.
The three named routines: minimum length, empty string, and range check.
Validation must loop until the input is valid; a single IF detects but does not fix.
Authentication uses a username and PLAIN TEXT password — encryption is not required.
Both username AND password must match; using OR is a serious security flaw.
Test data types: normal (typical), boundary (extreme), erroneous.
For the range 1 to 10, boundary data is 0, 1, 10, 11 — either side of each limit.
Erroneous data is the wrong type; a number just outside the range is boundary data.
You must select AND justify test data, stating what each test would catch.
Syntax error = will not run; logic error = runs but produces the wrong result.

Memorise this

Verbatim phrases and definitions Cambridge mark schemes credit.

The three validation routines: minimum string length, empty string, range check (e.g. between 1 and 10).
Validation must LOOP — use REPEAT…UNTIL so the input is re-requested.
Authentication: username and PLAIN TEXT password. Encryption is NOT required.
Username AND password must both match — never OR.
Three types of test data: normal (typical), boundary (extreme), erroneous.
For the range 1 to 10, boundary data is 0, 1, 10, 11.
Erroneous = wrong TYPE. A number just outside the range is BOUNDARY, not erroneous.
Syntax error: breaks the rules of the language, the program will NOT run.
Logic error: the program RUNS but gives the WRONG result.

How it’s examined

3.2.11 is assessed on Paper 1 and appears in every series, both as standalone questions and woven through longer algorithm tasks. Five shapes recur. (1) Recall, 1–2 marks: define validation, authentication, or the difference between syntax and logic errors (AO1). (2) Give test data, 2–4 marks: state normal, boundary and erroneous values for a stated range — AQA's own example of 0, 1, 10, 11 for the range 1 to 10 is the template (AO2). (3) Select and justify, 4–6 marks: choose test data and explain what each value would catch — the justification is where most marks are lost (AO3). (4) Categorise errors, 2–4 marks: identify faults in a printed program and label each as syntax or logic; the test is simply whether the program would run (AO2/AO3). (5) Write validation or authentication routines, 4–12 marks: the highest-tariff use, requiring a loop, a correct condition and a specific error message (AO3). Two boundaries are worth banking: passwords are plain text only, and the specification names only syntax and logic errors. The single most common fault is writing validation as one IF — detecting the error, then using the invalid value anyway.

Sources: AQA GCSE Computer Science 8525 specification (v1.3, 16 June 2025) — 3.2.11 Robust and secure programming; AQA GCSE Computer Science 8525 standard pseudo-code reference document; AQA GCSE Computer Science Paper 1 past papers, mark schemes and examiner reports. Last reviewed 2026-07-28.

Take this whole topic with you

Step-by-step worked examples — Robust and secure programming

Step-by-step solutions to past-paper-style questions on robust and secure programming, written exactly the way a tutor would explain them at the board.

Question type:

1Distinguish syntax errors from logic errors (4 marks)
Getting startedIdentify & classify• Paper 1 style — 4 marks (AO1/AO2)• syntax-error, logic-error, categorise
Question
(a) State the difference between a syntax error and a logic error. (b) Categorise each of the following as a syntax error or a logic error:

(i) OUTPUT 'Hello (missing closing quotation mark) (ii) average ← a + b / 2 when the intention was (a + b) / 2 (4 marks)
Step-by-step solution
1. Step 1
  (a) Syntax error breaks the rules of the programming language, so the program will not run — the translator reports it before execution begins.
2. Step 2
  Logic error means the program runs successfully but produces the wrong result, because the instructions are legal but do not do what was intended.
3. Step 3
  (b)(i) A missing quotation mark breaks the language's rules, so the program cannot run — a syntax error.
4. Step 4
  (b)(ii) The line is perfectly legal and runs, but operator precedence divides b by 2 before adding a, giving the wrong average — a logic error.
Answer
(a) A syntax error breaks the rules of the programming language, so the program will not run at all and the translator reports it (1). A logic error means the program runs successfully but produces the wrong result, because the instructions are legal but do not achieve what was intended, and nothing is reported (1).

(b)(i) Syntax error — the missing quotation mark breaks the language's rules so the program cannot run (1). (b)(ii) Logic error — the line runs perfectly, but because division is evaluated before addition it calculates a + (b / 2) rather than the intended average (1). (4)
Examiner tip
The test for categorising is a single question: would the program run? If no, it is a syntax error; if yes but the answer is wrong, it is a logic error. Candidates often label an obviously-wrong line as a syntax error because it 'looks broken', but legality is what decides it, not whether a human can see the mistake.
2Give normal, boundary and erroneous test data (4 marks)
Getting startedIdentify & classify• Paper 1 style — 4 marks (AO2)• test-data, boundary, erroneous
Question
A program accepts a whole number between 1 and 10 inclusive.

(a) Give one item of normal test data. (b) Give all four items of boundary test data. (c) Give one item of erroneous test data. (d) Explain why 11 is boundary data rather than erroneous data. (4 marks)
Step-by-step solution
1. Step 1
  (a) Normal data is a typical value comfortably inside the range — for example 5.
2. Step 2
  (b) Boundary data sits either side of each limit. The limits are 1 and 10, so the four values are 0, 1, 10, 11 — exactly the specification's own example.
3. Step 3
  (c) Erroneous data is of the wrong type or form entirely — the word 'seven', an empty entry, or a symbol.
4. Step 4
  (d) 11 is a perfectly valid whole number — the right type — that simply falls outside the permitted range, which makes it boundary data. Erroneous data is data the program could not sensibly interpret at all.
Answer
(a) 5 — a typical value within the allowed range (1). (b) 0, 1, 10 and 11 — the values either side of each limit (1). (c) 'seven' (or an empty entry, or a symbol such as '£') — data of the wrong type (1). (d) 11 is boundary data because it is a valid whole number of the correct data type, which simply lies just outside the permitted range. Erroneous data is of the wrong type or form entirely, such as a word where a number is expected, which the program could not interpret as a number at all (1). (4)
Examiner tip
Part (b) matches AQA's own worked example in the specification: 'If the allowed range is 1 to 10, then boundary data is 0, 1, 10, 11.' All four values are needed — giving only 1 and 10 misses the pair just outside. Part (d) tests the distinction most often confused, and the deciding factor is the data type, not whether the value is accepted.
3Write a range validation routine (4 marks)
Getting startedMulti-step problem• Paper 1 style — 4 marks (AO3)• validation, range-check, loop
Question
Write a validation routine using pseudo-code that keeps asking the user for a number until they enter one between 1 and 10 inclusive, giving a helpful message each time an invalid number is entered. (4 marks)
Step-by-step solution
1. Step 1
  Choose the loop. A number must be obtained before it can be tested, so this needs condition-at-the-end iteration — REPEAT…UNTIL.
2. Step 2
  Prompt and convert. USERINPUT returns a string, so it must be converted before a numeric comparison.
3. Step 3
  The invalid test uses OR: num < 1 OR num > 10 — failing either limit makes it invalid.
4. Step 4
  The UNTIL states the valid condition using AND: num ≥ 1 AND num ≤ 10. Note 'inclusive' means both 1 and 10 must be accepted.
Answer
REPEAT OUTPUT 'Enter a number between 1 and 10' num ← STRING_TO_INT(USERINPUT) IF num < 1 OR num > 10 THEN OUTPUT 'Invalid — the number must be between 1 and 10' ENDIF UNTIL num ≥ 1 AND num ≤ 10

Marks: REPEAT…UNTIL used so the input is obtained before being tested (1); input prompted and converted (1); correct invalid test using OR with a specific error message (1); correct UNTIL condition using AND with ≥ and ≤ so 1 and 10 are both accepted (1). (4)
Examiner tip
Two details carry marks. The loop is essential — a single IF would detect the error and then use the invalid value anyway. And 'inclusive' requires ≥ and ≤, so testing with the boundary values 1 and 10 must both succeed; writing > and < would reject them.
4Write an authentication routine with limited attempts (5 marks)
Building confidenceMulti-step problem• Paper 1 style — 5 marks (AO3)• authentication, password, loop, boolean-flag
Question
Write an authentication routine using pseudo-code. The user has a maximum of three attempts to enter the correct username and password. On success the program outputs 'Access granted' and stops asking immediately; after three failures it outputs 'Locked out'. The correct details are stored in STORED_USER and STORED_PASS. (5 marks)
Step-by-step solution
1. Step 1
  Initialise a counter and a Boolean flag before the loop: attempts ← 0 and access ← False.
2. Step 2
  Use a compound loop condition — attempts < 3 AND access = False — so the loop ends either when the attempts run out or as soon as access is granted.
3. Step 3
  Both credentials must match, so the test uses AND. Using OR would grant access to anyone who got just one of them right.
4. Step 4
  Increment the counter every time round, and set the flag only on a successful match.
5. Step 5
  After the loop, test the flag to decide which message to output — the loop can end for two different reasons.
Answer
attempts ← 0 access ← False WHILE attempts < 3 AND access = False OUTPUT 'Enter username' username ← USERINPUT OUTPUT 'Enter password' password ← USERINPUT attempts ← attempts + 1 IF username = STORED_USER AND password = STORED_PASS THEN access ← True ELSE OUTPUT 'Incorrect — attempt ', attempts, ' of 3' ENDIF ENDWHILE IF access = True THEN OUTPUT 'Access granted' ELSE OUTPUT 'Locked out' ENDIF

Marks: counter and Boolean flag initialised (1); compound loop condition allowing both an attempt limit and an early exit (1); both credentials tested with AND (1); attempts incremented each time round the loop (1); correct message chosen after the loop by testing the flag (1). (5)
Examiner tip
The compound condition attempts < 3 AND access = False is what makes the routine stop immediately on success as the question requires — a plain FOR i ← 1 TO 3 loop cannot exit early. Note the specification requires plain text passwords only, so comparing directly against the stored value is exactly what is expected at GCSE; no encryption is needed.

5Produce a complete test plan (5 marks)

Building confidenceWord problem• Paper 1 style — 5 marks (AO3)• test-data, test-plan, justify

Question

A program accepts a student's percentage score, which must be a whole number between 0 and 100 inclusive.

Produce a test plan giving one item of normal data, all boundary data, and one item of erroneous data. For each, state the expected result. (5 marks)

Step-by-step solution

Step 1
Identify the limits. The lower limit is 0 and the upper limit is 100.
Step 2
Boundary data sits either side of each limit. Lower limit 0 gives −1 and 0; upper limit 100 gives 100 and 101.
Step 3
Note the lower boundary carefully. Because the limit is 0, the value just below it is −1, not 0.
Step 4
Normal data is a typical mid-range value such as 65.
Step 5
Always state the expected result — a test with no expected outcome cannot fail, because there would be nothing to compare the actual behaviour against.

Answer

Test data	Type	Expected result
65	Normal	Accepted — a typical valid score
−1	Boundary	Rejected — just below the lower limit
0	Boundary	Accepted — the lowest allowed value
100	Boundary	Accepted — the highest allowed value
101	Boundary	Rejected — just above the upper limit
`'sixty'`	Erroneous	Rejected without crashing — wrong data type

Marks: normal data with the correct expected result (1); both lower boundary values −1 and 0 (1); both upper boundary values 100 and 101 (1); erroneous data of the wrong type (1); expected result stated for every item (1). (5)

Examiner tip

The lower boundary is the discriminator: because the limit is 0, the value immediately below it is −1, and candidates who write 0 and 1 have used the wrong limit. Note also that erroneous data should be rejected without crashing — a program that terminates with an error message has not handled it robustly.

6Categorise errors in a program (5 marks)
Building confidenceIdentify & classify• Paper 1 style — 5 marks (AO2/AO3)• syntax-error, logic-error, identify-error
Question
For each line below, state whether it contains a syntax error or a logic error, and explain your reasoning.

(a) IF score > 5 — the THEN is missing (b) IF age > 18 THEN — when the rule is 'aged 18 or over' (c) FOR i ← 0 TO LEN(a) — where a has LEN(a) elements indexed from 0 (d) total ← total - price — when items are being added to a basket (e) OUTPUT 'Total: , total — a quotation mark is missing (5 marks)
Step-by-step solution
1. Step 1
  (a) A missing THEN breaks the language's rules, so the program will not run — syntax error.
2. Step 2
  (b) The line is legal and runs, but > excludes exactly 18 when the rule says 18 should be included — logic error (an off-by-one).
3. Step 3
  (c) Legal code that runs, but the loop goes one iteration too far and accesses an index that does not exist — logic error in the loop bounds.
4. Step 4
  (d) Perfectly legal, but subtracting instead of adding gives the wrong total — logic error, the wrong operator.
5. Step 5
  (e) A missing quotation mark breaks the language's rules — syntax error.
Answer
(a) Syntax error — the missing THEN breaks the rules of the language, so the program will not run (1). (b) Logic error — the code runs, but > excludes an age of exactly 18 when the rule states 18 should be accepted; it should be ≥ (1). (c) Logic error — the code runs, but the loop performs one iteration too many and accesses index LEN(a), which does not exist in an array indexed from 0; the bound should be LEN(a) - 1 (1). (d) Logic error — the code runs, but subtracting the price instead of adding it produces a completely wrong total (1). (e) Syntax error — the missing quotation mark means the string is never closed, so the program will not run (1). (5)
Examiner tip
Three of the five are logic errors, which reflects reality: syntax errors are caught immediately by the translator, whereas logic errors survive into working programs. Note that (c) causes a crash during execution — but the underlying fault is a logic error in the loop bounds, and since the specification names only syntax and logic, that is the correct category.

7Select and justify test data (6 marks)

StretchWord problem• Paper 1 style — 6 marks (AO3)• test-data, justify, boundary

Question

A theme park ride requires riders to be at least 130 cm and no more than 200 cm tall.

Select five items of test data for the height validation, stating the type of each and justifying why you chose it. (6 marks)

Step-by-step solution

Step 1
Identify both limits: 130 (lower) and 200 (upper), both inclusive.
Step 2
Boundary values at the lower limit: 129 (just below, must be rejected) and 130 (the lowest allowed, must be accepted).
Step 3
Boundary values at the upper limit: 200 (the highest allowed, must be accepted) and 201 (just above, must be rejected).
Step 4
Add normal data — a typical value such as 165 — to confirm ordinary cases work.
Step 5
Justify by saying what each test would catch, not merely what type it is. 130 catches a > written where ≥ was needed.
Step 6
Consider erroneous data too — a non-numeric entry should be rejected without crashing.

Answer

Test data	Type	Justification	Expected result
165	Normal	A typical rider height comfortably inside the range, confirming ordinary cases are handled	Accepted
129	Boundary	The value immediately below the lower limit — confirms riders just too short are correctly refused	Rejected
130	Boundary	The lowest allowed height — would reveal a programmer writing `> 130` instead of `≥ 130`, which would wrongly refuse a rider of exactly 130 cm	Accepted
200	Boundary	The highest allowed height — would reveal `< 200` written instead of `≤ 200`	Accepted
201	Boundary	The value immediately above the upper limit — confirms riders just too tall are refused	Rejected

(A sixth valuable test is erroneous data such as 'tall', which should be rejected without crashing.)

Marks: normal data included with a reason (1); both lower boundary values 129 and 130 (1); both upper boundary values 200 and 201 (1); expected result stated for every item (1); justifications explain what each test would catch rather than naming the type (2). (6)

Examiner tip

The justification marks are where most candidates lose out. Compare '130, because it is a boundary value' — which merely restates the classification — with '130, because it is the lowest allowed height, so it would reveal a programmer using > instead of ≥'. The second explains what the test is for, which is exactly what 'justify the choice of suitable test data' requires.

8Write a complete robust input routine (8 marks)
StretchMulti-step problem• Paper 1 style — 8 marks (AO3)• validation, subroutine, range-check, empty-string
Question
Write a subroutine called getValidName that repeatedly asks for a name until the entry is not empty and is at least 2 characters long, then returns it. Then write a second subroutine getValidAge that repeatedly asks for an age until it is between 0 and 120 inclusive, then returns it.

Give a specific error message for each type of failure. (8 marks)
Step-by-step solution
1. Step 1
  Both routines need condition-at-the-end iteration, since a value must be obtained before it can be tested.
2. Step 2
  The empty check is LEN(name) = 0, one of the three routines named in the specification.
3. Step 3
  The minimum length check is LEN(name) < 2. 'At least 2' means exactly 2 must be accepted.
4. Step 4
  Separate IF branches allow a different message for each failure rather than one generic 'invalid'.
5. Step 5
  The age routine uses a range check with AND in the UNTIL and OR in the invalid test.
6. Step 6
  Both routines RETURN the validated value, so the calling program receives clean data it can trust.
Answer
SUBROUTINE getValidName() REPEAT OUTPUT 'Enter your name (at least 2 characters)' name ← USERINPUT IF LEN(name) = 0 THEN OUTPUT 'You must enter something' ELSE IF LEN(name) < 2 THEN OUTPUT 'Too short — the name must be at least 2 characters' ENDIF UNTIL LEN(name) ≥ 2 RETURN name ENDSUBROUTINE SUBROUTINE getValidAge() REPEAT OUTPUT 'Enter your age (0-120)' age ← STRING_TO_INT(USERINPUT) IF age < 0 OR age > 120 THEN OUTPUT 'Invalid — the age must be between 0 and 120' ENDIF UNTIL age ≥ 0 AND age ≤ 120 RETURN age ENDSUBROUTINE # Main program userName ← getValidName() userAge ← getValidAge() OUTPUT userName, ' is ', userAge, ' years old'

Marks: getValidName uses REPEAT…UNTIL (1); empty check using LEN(name) = 0 (1); minimum length check using LEN(name) < 2 with a separate message (1); returns the validated name (1); getValidAge uses REPEAT…UNTIL with the input converted (1); correct range check using OR for invalid and AND for valid (1); returns the validated age (1); both subroutines called and their returned values used in the main program (1). (8)
Examiner tip
This question combines 3.2.11 with 3.2.10 subroutines, 3.2.8 string length and 3.2.2 iteration — which is exactly how validation is examined at the top of the tariff. Wrapping validation in a subroutine is the strongest design point: the rule exists in one place, can be tested independently, and can be reused for every name the program needs.
9Find and fix the faults in a validation routine (6 marks)
StretchIdentify & classify• Paper 1 style — 6 marks (AO3)• debugging, validation, identify-error, authentication
Question
The routine below should accept a mark between 0 and 100 and then check a password. It contains three faults. Identify each, state whether it is a syntax or a logic error, explain its effect, and write a corrected version. (6 marks)

1 OUTPUT 'Enter a mark' 2 mark ← STRING_TO_INT(USERINPUT) 3 IF mark < 0 OR mark > 100 THEN 4 OUTPUT 'Invalid' 5 ENDIF 6 total ← total + mark 7 8 OUTPUT 'Enter password' 9 pass ← USERINPUT 10 IF user = STORED_USER OR pass = STORED_PASS THEN 11 OUTPUT 'Access granted' 12 ENDIF
Step-by-step solution
1. Step 1
  Fault 1 — lines 3–6: validation does not loop. The IF detects an invalid mark and prints a message, but line 6 then adds that invalid mark to the total anyway.
2. Step 2
  Category and fix. This is a logic error — the code runs perfectly. It must be replaced with a REPEAT…UNTIL loop that re-requests the input.
3. Step 3
  Fault 2 — line 10 uses OR instead of AND. Anyone who knows either the username or the password alone would be granted access.
4. Step 4
  Category. Also a logic error, and a serious security flaw — the routine runs without any error.
5. Step 5
  Fault 3 — there is no ELSE on the authentication check, so a failed login produces no output at all and the user receives no feedback.
6. Step 6
  Write the corrected version with a validation loop, AND in the credentials test, and an ELSE branch.
Answer
Fault 1 — the validation does not loop (lines 3–6). This is a logic error (1). The IF detects an invalid mark and prints a message, but the program then continues and adds that invalid mark to the total anyway on line 6 — so the validation achieves nothing (1).

Fault 2 — line 10 uses OR instead of AND. Also a logic error (1). With OR, satisfying either condition is enough, so anyone who knew just the username — or just the password — would be granted access, which is a serious security flaw (1).

Fault 3 — there is no ELSE branch for a failed login. A user who enters incorrect details receives no output at all and is given no indication that the attempt failed (1).

Corrected version:

REPEAT OUTPUT 'Enter a mark between 0 and 100' mark ← STRING_TO_INT(USERINPUT) IF mark < 0 OR mark > 100 THEN OUTPUT 'Invalid — must be between 0 and 100' ENDIF UNTIL mark ≥ 0 AND mark ≤ 100 total ← total + mark OUTPUT 'Enter username' user ← USERINPUT OUTPUT 'Enter password' pass ← USERINPUT IF user = STORED_USER AND pass = STORED_PASS THEN OUTPUT 'Access granted' ELSE OUTPUT 'Access denied' ENDIF

(1)
Examiner tip
Both major faults are logic errors — the program runs cleanly and produces no error message, which is exactly what makes them dangerous. Fault 1 is the single most common validation mistake at GCSE: detection without a loop is not validation. Note the original also never asks for a username, which is a further omission worth spotting.

Model Answers — Robust and secure programming

High-scoring sample answers for robust and secure programming on the AQA GCSE 8525 paper, with examiner-style notes mapping each response to the mark scheme and assessment objectives.

Question 1
Paper 1 style — AO13 marks
State the three types of test data described in the specification. (3 marks)
Model answer
Normal (typical) data (1), boundary (extreme) data (1) and erroneous data (1).
Why this scores
The bracketed alternatives — typical and extreme — are the specification's own wording and are equally acceptable. These three are the complete list; 'invalid data' is not a separate named category.
Question 2
Paper 1 style — AO22 marks
A program accepts values in the range 1 to 10. State the boundary test data. (2 marks)
Model answer
0, 1, 10 and 11 (2 marks — 1 for the pair around the lower limit, 1 for the pair around the upper limit).

These are the values either side of each boundary: 0 and 1 at the lower limit, 10 and 11 at the upper limit.
Why this scores
This is AQA's own example from the specification. All four values are required — giving only 1 and 10 misses the values just outside the range, which are what confirm invalid entries are correctly rejected. Boundary data always comes in pairs around each limit.
Question 3
Paper 1 style — AO11 mark
State what the specification says about the passwords used in authentication routines at GCSE. (1 mark)
Model answer
Only plain text usernames and passwords are required — students do not need to encrypt the passwords (1).
Why this scores
This is an explicit boundary in the specification's additional information column. Comparing a typed password directly against a stored one is exactly what is expected, so no hashing or encryption should appear in an answer. Noting that plain-text storage is a real-world weakness is still a valid evaluative comment.
Question 4
Paper 1 style — AO2/AO34 marks
Explain why a validation routine must use a loop rather than a single IF statement. (4 marks)
Model answer
A single IF statement can only detect that the data is invalid and display a message — it has no way of obtaining a replacement value (1). Once the IF has finished, the program simply carries on to the next line with the invalid value still stored in the variable, so it is used anyway and the validation achieves nothing (1).

A loop repeatedly re-requests the input until a valid value is entered (1), so the program cannot proceed until the data is acceptable — which guarantees that everything after the loop is working with valid data (1).

The natural structure is condition-at-the-end iteration (REPEAT…UNTIL), because a value must be obtained before it can be tested.
Why this scores
The decisive point is that after a single IF, the bad value is still there — students often think the message somehow prevents its use. The final observation about REPEAT…UNTIL links to 3.2.2 and shows why validation is the classic application of condition-at-the-end iteration.
Question 5
Paper 1 style — AO24 marks
Explain the difference between boundary test data and erroneous test data, using a program that accepts ages between 5 and 18 as an example. (4 marks)
Model answer
Boundary test data consists of values at the very edges of the allowed range and immediately either side of them (1). For a range of 5 to 18 that would be 4, 5, 18 and 19 — all valid whole numbers of the correct data type, where 5 and 18 should be accepted and 4 and 19 rejected (1).

Erroneous test data is data of the wrong type or form entirely, which the program could not sensibly interpret at all (1) — for example the word 'ten', an empty entry, or a symbol such as '#', none of which is a number, and all of which should be rejected without the program crashing (1).

The key distinction is that 19 is boundary data rather than erroneous data, because it is a perfectly valid number that simply falls outside the permitted range.
Why this scores
The final sentence is the discriminator and is what the question is really testing. The deciding factor is the data type: boundary data is the right type in the wrong place, whereas erroneous data is the wrong type altogether. Note the requirement that erroneous data be rejected without crashing.
Question 6
Paper 1 style — AO34 marks
A program calculates a mean using mean ← total / count. When count is 0 the program crashes. Explain what type of error this is and how it could be prevented. (4 marks)
Model answer
This is a logic error (1). The line is perfectly legal, so the program runs — the translator reports nothing and the fault only appears when count happens to be 0, at which point the program attempts to divide by zero and crashes (1).

It could be prevented by using selection to check the value before dividing (1):

IF count = 0 THEN OUTPUT 'No data entered — cannot calculate a mean' ELSE mean ← total / count OUTPUT 'Mean: ', mean ENDIF

This guard means the division is only ever attempted when it is safe, and the user receives a clear message instead of a crash (1).
Why this scores
Some sources would call the crash itself a runtime error, but the specification names only syntax and logic, and the underlying fault — failing to guard the division — is a logic error. Note the bug is conditional: it appears only for one particular value of count, which is precisely why boundary and erroneous test data matter.

Question 7

Paper 1 style — AO38 marks

A program accepts a username that must be between 5 and 12 characters long, and a PIN that must be a whole number between 1000 and 9999.

Produce a complete test plan covering both inputs, giving normal, boundary and erroneous data with justifications and expected results. (8 marks)

Model answer

Username (5 to 12 characters)

Test data	Type	Justification	Expected
`'amina'` (5)	Boundary	The shortest allowed — reveals `> 5` written instead of `≥ 5`	Accepted
`'abcd'` (4)	Boundary	Immediately below the minimum	Rejected
`'abcdefghijkl'` (12)	Boundary	The longest allowed — reveals `< 12` written instead of `≤ 12`	Accepted
`'abcdefghijklm'` (13)	Boundary	Immediately above the maximum	Rejected
`'student'` (7)	Normal	A typical username comfortably within range	Accepted
`''` (empty)	Erroneous	Nothing entered at all — must not crash	Rejected

PIN (1000 to 9999)

Test data	Type	Justification	Expected
5678	Normal	A typical four-digit PIN	Accepted
999	Boundary	Immediately below the minimum	Rejected
1000	Boundary	The lowest allowed value	Accepted
9999	Boundary	The highest allowed value	Accepted
10000	Boundary	Immediately above the maximum	Rejected
`'abcd'`	Erroneous	Letters where a number is required — must be rejected without crashing	Rejected

Marks: username boundary pair at the lower limit (1); username boundary pair at the upper limit (1); username normal and erroneous data (1); PIN boundary pair at the lower limit (1); PIN boundary pair at the upper limit (1); PIN normal and erroneous data (1); expected result stated throughout (1); justifications explain what each test would catch (1). (8)

Why this scores

Note that the username boundaries are measured in characters (a length check) while the PIN boundaries are numeric values (a range check) — two of the three validation routines named in the specification, tested side by side. The justifications that earn the final mark name a specific fault the test would expose, such as > used in place of ≥.

Question 8
Paper 1 style — AO36 marks
Explain what is meant by robust programming, and discuss why validation alone cannot guarantee that the data a program holds is correct. (6 marks)
Model answer
Robust programming means writing programs that continue to behave sensibly when they receive unexpected or invalid input, rather than crashing or producing nonsense (1). It is achieved through validation routines that check data is acceptable before it is used, loops that re-request input until it is valid, and testing with normal, boundary and erroneous data to confirm the program copes with all three (1).

However, validation checks only that data is plausible, not that it is true. A range check confirms an age lies between 0 and 120, but if a user enters 35 when they are actually 34, the value passes every possible check because 35 is a perfectly reasonable age (1). No validation rule can detect this, because the program has no independent source of truth to compare the entry against (1).

The same applies to any well-formed but incorrect entry — a misspelled name, a transposed pair of digits in a phone number, or a date of birth in the wrong format that still happens to be a valid date (1).

What can help is confirmation: echoing the data back to the user before it is committed, so they can spot their own mistake — which catches a class of error that validation is structurally incapable of finding (1). (6)
Why this scores
The distinction between plausible and true is the top-band idea and should lead the second half of the answer. The strongest supporting point is that the program has no independent source of truth against which to check a well-formed entry, and that confirmation is therefore a genuinely different safeguard rather than just more validation.
Question 9
Paper 1 style — AO1/AO36 marks
Compare syntax errors and logic errors, explaining why logic errors are generally more difficult to find and correct. (6 marks)
Model answer
Syntax errors break the rules of the programming language, such as a missing ENDIF or an unclosed quotation mark (1). Because the code is not valid, the translator cannot process it and the program will not run at all — instead it reports the error, usually identifying the line where it occurred (1).

Logic errors occur where the code is entirely legal but does not do what the programmer intended — using > where ≥ was needed, or subtracting where addition was required (1). The program therefore runs successfully and produces output; it is simply the wrong output (1).

Why logic errors are harder to find. A syntax error announces itself immediately and points you to its location, so it can usually be corrected in seconds (1). A logic error produces no message of any kind: the programmer must first notice that the output is wrong, which may not be obvious if the answer looks plausible, and then trace through the program to work out where the reasoning went astray. A subtly wrong grade boundary or total could go unnoticed for a long time — and some logic errors surface only for particular inputs, such as an off-by-one that fails only at a boundary value, making them harder still to reproduce and diagnose (1). (6)
Why this scores
The strongest closing point is that a logic error may appear only for particular inputs, which explains both why boundary test data matters and why some faults survive extensive testing. Note the neat link: a syntax error is caught by the translator (3.4.4), whereas a logic error can only be caught by testing (3.2.11).

Key Definitions and Keywords — Robust and secure programming

Definitions to memorise and the exact keywords mark schemes credit for robust and secure programming answers — sharpened from recent examiner reports for the 2026 AQA GCSE 8525 sitting.

Validation
Examiner keyword
Checking that data entered by a user is sensible and allowed before the program uses it. Validation confirms data is plausible, not that it is correct.
Example
Checking a mark lies between 0 and 100.
Related: Range check, Length check, Authentication
Length check
Examiner keyword
A validation routine confirming a string has at least a stated number of characters. One of the three routines named in the specification.
Example
IF LEN(password) < 8 THEN OUTPUT 'Too short'
Related: Presence check, Validation
Empty string check
Examiner keyword
A validation routine confirming the user has actually entered something, by testing whether the string's length is 0. One of the three routines named in the specification.
Example
IF LEN(name) = 0 THEN OUTPUT 'You must enter a name'
Related: Length check, Validation
Range check
Examiner keyword
A validation routine confirming a value lies within permitted limits. Requires two comparisons joined with AND. The specification's example is 'between 1 and 10'.
Example
UNTIL num ≥ 1 AND num ≤ 10
Related: Validation, Boundary data
Authentication
Examiner keyword
Checking that a user is who they claim to be, normally with a username and password. At GCSE only plain text passwords are required — encryption is not needed.
Example
IF username = STORED_USER AND password = STORED_PASS THEN
Related: Plain text, Validation
Plain text
Examiner keyword
Data stored or compared in its readable, unencrypted form. The specification requires only plain text usernames and passwords, so encryption is explicitly not needed.
Related: Authentication
Testing
Examiner keyword
Running a program with chosen data to check it behaves as expected, so that errors can be found and corrected.
Related: Test data, Syntax error, Logic error
Test data
Examiner keyword
Data chosen deliberately to check a program works correctly. The three types are normal (typical), boundary (extreme) and erroneous.
Related: Normal data, Boundary data, Erroneous data
Normal (typical) test data
Examiner keyword
Sensible data of the expected type that the program will meet in ordinary use, and which should be accepted and processed correctly.
Example
5 for a program accepting values from 1 to 10.
Related: Boundary data, Erroneous data
Boundary (extreme) test data
Examiner keyword
Values at the very edges of the allowed range and immediately either side of them. For an allowed range of 1 to 10, boundary data is 0, 1, 10, 11.
Related: Normal data, Erroneous data, Off by one error
Erroneous test data
Examiner keyword
Data of the wrong type or form entirely, which the program should reject without crashing. Distinct from boundary data, which is the right type but outside the permitted range.
Example
Entering 'seven' where a number is expected.
Related: Boundary data, Normal data
Syntax error
Examiner keyword
An error that breaks the rules of the programming language, so the program will not run at all. Detected and reported by the translator before execution.
Example
A missing ENDIF, or an unclosed quotation mark.
Related: Logic error, Translator
Logic error
Examiner keyword
An error where the program runs successfully but produces the wrong result, because the instructions are legal but do not do what was intended. Not reported by the translator.
Example
Using > where ≥ was needed, or subtracting instead of adding.
Related: Syntax error, Testing
Robust program
Examiner keyword
A program that continues to behave sensibly when given unexpected or invalid input, rather than crashing or producing nonsense. Achieved through validation, loops and thorough testing.
Related: Validation, Testing
Off-by-one error
Examiner keyword
A logic error where a condition or loop includes or excludes exactly one value more than intended, usually caused by < where ≤ was needed. Exposed by boundary test data.
Related: Logic error, Boundary data

Common Mistakes and Misconceptions — Robust and secure programming

The traps other students keep falling into on robust and secure programming questions — taken from recent AQA GCSE 8525 examiner reports and mark schemes — and how to avoid them.

✕Writing validation as a single IF statement that displays a message but never re-requests the input.
AQA 8525 specification 3.2.11 requires students to write simple data validation routines; single-IF 'validation' is the most common fault in this subtopic.
Why it happens
The IF correctly detects the problem and produces an error message, which feels like the whole job — students do not picture what happens on the very next line, where the invalid value is still sitting in the variable.
How to avoid it
Validation must loop: use REPEAT … UNTIL <valid> so the input is requested again until it passes. Then trace your own routine with a deliberately invalid value and follow what happens next — you will see the bad value being used anyway. Detection without re-asking is not validation.
✕Giving only two boundary values — 1 and 10 for a range of 1 to 10 — instead of all four.
AQA 8525 specification 3.2.11 additional information gives 0, 1, 10, 11 as the worked example.
Why it happens
The limits themselves are the obvious 'edge' values, and it is easy to overlook that the values just outside the range are equally part of the boundary test.
How to avoid it
Boundary data comes in pairs around each limit, so a range with two limits needs four values. AQA's own example is explicit: for the range 1 to 10, boundary data is 0, 1, 10, 11. The pair inside confirms valid values are accepted; the pair outside confirms invalid ones are rejected.
✕Classifying a number just outside the allowed range as erroneous data.
Test-data questions frequently ask for one item of each type specifically to test this distinction.
Why it happens
Both boundary-outside data and erroneous data get rejected, so they feel like the same category — the classification is based on the outcome rather than on the data itself.
How to avoid it
The deciding factor is the data type, not whether it is accepted. For a range of 1 to 10, 11 is boundary data — a perfectly valid whole number that simply falls outside the range. Erroneous data is the wrong type entirely, such as the word 'seven' or an empty entry.
✕Listing test data without justifying why each value was chosen.
AQA 8525 specification 3.2.11: 'Be able to select and justify the choice of suitable test data for a given problem.'
Why it happens
Producing the correct values feels like the substance of the answer, and the justification looks like restating the obvious — so it gets omitted under time pressure.
How to avoid it
The specification requires you to select and justify test data. A justification says what the test would catch: not '1, because it is a boundary value' but '1, because it is the lowest allowed value, so it would reveal a programmer using > instead of ≥'. Always state the expected result too — a test with no expected outcome cannot fail.
✕Labelling a wrong operator or a wrong comparison as a syntax error.
AQA 8525 specification 3.2.11 requires students to identify and categorise errors as syntax or logic.
Why it happens
The code is visibly wrong to a human reader, so it feels 'broken' — and 'syntax error' is the more familiar term, so it becomes the default label for anything faulty.
How to avoid it
Ask one question: would the program run? If it runs and simply gives the wrong answer, it is a logic error, however obviously mistaken the line looks. A syntax error means the code is not valid in the language at all, so the translator refuses to process it and execution never begins.
✕Writing an authentication check as username = STORED_USER OR password = STORED_PASS.
Authentication routines are named in 3.2.11, and OR-instead-of-AND is a standard fault in error-identification questions.
Why it happens
Read aloud, 'if the username or the password matches' sounds reasonable, and because the routine grants access to a correct login it appears to work during casual testing.
How to avoid it
Both credentials must match, so the operator is AND. Test the faulty version deliberately with a correct username and a wrong password: the OR version grants access, which is a serious security flaw. If either half alone is enough, the password is doing no work at all.

AQA GCSE Computer Science (8525)

Robust and secure programming

0% Complete

Detailed Study Notes

Detailed notes on Programming for AQA GCSE Computer Science, covering key concepts, explanations, examples, and exam-focused revision points.

Robust and Secure Programming — AQA GCSE Computer Science 8525 (3.2.11)

At a glance

Validation checks that entered data is sensible and allowed before the program uses it.
AQA names three validation routines: minimum length, empty string, and range (e.g. between 1 and 10).
Validation must loop — detecting bad input without re-asking achieves nothing.
Authentication uses a username and password. AQA requires plain text only — encryption is NOT needed at GCSE.
Three types of test data: normal (typical), boundary (extreme), erroneous.
Boundary data sits either side of each limit — for the range 1 to 10, that is 0, 1, 10, 11.
Erroneous data is data of the wrong type or form that should be rejected — e.g. letters where a number is expected.
You must select and justify suitable test data for a given problem.
Syntax error = breaks the rules of the language; the program will not run.
Logic error = the program runs but produces the wrong result — far harder to find.

What you’ll learn

Mapped to the AQA GCSE 8525 syllabus (2027-2029).

Be able to write simple data validation routines, including checking minimum string length, checking if a string is empty, and checking data lies within a given range.
Be able to write simple authentication routines using a username and plain text password (encryption is not required).
Understand what is meant by testing in the context of algorithms and programs, and be able to correct errors.
Understand what test data is and describe normal (typical), boundary (extreme) and erroneous test data.
Be able to select and justify the choice of suitable test data for a given problem.
Understand that there are different types of error — syntax and logic — and be able to identify and categorise errors within algorithms and programs.

Data validation routines

Three named checks — and every one of them must loop until the input is valid.

Validation checks that data entered by a user is sensible and allowed before the program uses it.

The three routines AQA names

The specification lists these three explicitly as examples of simple validation routines:

1. Minimum length check

REPEAT
    OUTPUT 'Enter a password of at least 8 characters'
    password ← USERINPUT

    IF LEN(password) < 8 THEN
        OUTPUT 'Too short — must be at least 8 characters'
    ENDIF
UNTIL LEN(password) ≥ 8

2. Empty string check

REPEAT
    OUTPUT 'Enter your name'
    name ← USERINPUT

    IF LEN(name) = 0 THEN
        OUTPUT 'You must enter something'
    ENDIF
UNTIL LEN(name) > 0

3. Range check — the specification's own example is "between 1 and 10"

REPEAT
    OUTPUT 'Enter a number between 1 and 10'
    num ← STRING_TO_INT(USERINPUT)

    IF num < 1 OR num > 10 THEN
        OUTPUT 'Invalid — must be between 1 and 10'
    ENDIF
UNTIL num ≥ 1 AND num ≤ 10

The rule that carries the most marks: validation must LOOP

# WRONG — detects the error, then uses the bad value anyway
IF mark < 0 OR mark > 100 THEN
    OUTPUT 'Invalid'
ENDIF
total ← total + mark        # the invalid mark is still added

# RIGHT — keeps asking until the input is valid
REPEAT
    mark ← STRING_TO_INT(USERINPUT)
UNTIL mark ≥ 0 AND mark ≤ 100
total ← total + mark

A single IF detects the problem but never fixes it. Because a value must be obtained before it can be tested, validation naturally uses condition-at-the-end iteration (3.2.2).

Validation checks data is sensible and allowed — not that it is correct.
The three named routines: minimum length, empty string, range check.
Validation must LOOP — a single IF detects but does not fix.
Condition-at-the-end iteration is the natural structure, since input must be obtained before it can be tested.
The inner IF states the invalid condition (OR); the UNTIL states the valid one (AND).

See the full worked example for robust and secure programming →

Authentication routines

Username and password, plain text only. Encryption is explicitly not required.

Authentication checks that a user is who they claim to be, normally with a username and password.

The specification is unusually explicit about the boundary:

"Students will only be required to use plain text usernames and passwords (ie students will not need to encrypt the passwords)."

So at GCSE, comparing a typed password directly against a stored one is exactly what is expected.

A basic authentication routine

CONSTANT STORED_USER ← 'admin'
CONSTANT STORED_PASS ← 'letmein'

OUTPUT 'Enter username'
username ← USERINPUT

OUTPUT 'Enter password'
password ← USERINPUT

IF username = STORED_USER AND password = STORED_PASS THEN
    OUTPUT 'Access granted'
ELSE
    OUTPUT 'Access denied'
ENDIF

Note the AND. Both the username and the password must match. Using OR would grant access to anyone who got either one right — a catastrophic security flaw and a favourite exam fault.

With a limited number of attempts

This is the version that appears in higher-tariff questions:

attempts ← 0
access   ← False

WHILE attempts < 3 AND access = False
    OUTPUT 'Enter username'
    username ← USERINPUT
    OUTPUT 'Enter password'
    password ← USERINPUT

    attempts ← attempts + 1

    IF username = STORED_USER AND password = STORED_PASS THEN
        access ← True
    ELSE
        OUTPUT 'Incorrect — attempt ', attempts, ' of 3'
    ENDIF
ENDWHILE

IF access = True THEN
    OUTPUT 'Access granted'
ELSE
    OUTPUT 'Locked out'
ENDIF

Why real systems do more (worth a sentence in evaluation questions)

Authentication checks a user is who they claim to be, using a username and password.
AQA requires PLAIN TEXT only — encryption is explicitly not needed.
Both username AND password must match — using OR is a serious security flaw.
Attempt-limited versions use a compound condition: attempts < 3 AND access = False.
Plain-text storage is a real weakness worth noting in evaluation answers.

See the full worked example for robust and secure programming →

Testing and the three types of test data

Normal, boundary and erroneous — with AQA's own worked example of boundary data.

Testing means running a program with chosen data to check it behaves as expected, so that errors can be found and corrected.

The three types

Type	What it is	Should the program…
Normal (typical)	Sensible data the program will meet in ordinary use	Accept it and process it correctly
Boundary (extreme)	Values at the very edges of what is allowed, and just outside	Accept those inside, reject those outside
Erroneous	Data of the wrong type or form entirely	Reject it without crashing

Boundary data — AQA's own example

The specification states it directly:

"If the allowed range is 1 to 10, then boundary data is 0, 1, 10, 11, ie either side of the allowed boundary."

Boundary data always comes in pairs around each limit, which is why a range with two limits needs four boundary values.

Erroneous data is not the same as boundary data

This is the distinction most often confused:

Boundary: a number just outside the allowed range — 0 or 11. Still the right type, just not permitted.
Erroneous: the wrong type or form entirely — the word 'seven', an empty entry, a symbol.

For a range of 1 to 10, 11 is boundary data, not erroneous data — it is a perfectly valid integer that simply falls outside the range.

AQA tip. When asked to give test data, present it as a table with three columns: the value, its type, and the expected result. That structure earns the marks and makes omissions obvious.

Testing runs a program with chosen data to check it behaves as expected.
Normal (typical) data should be accepted; boundary and out-of-range should be handled correctly.
For the range 1 to 10, boundary data is 0, 1, 10, 11 — either side of each limit.
Erroneous data is the wrong TYPE (e.g. 'seven'); 11 is boundary, not erroneous.
Boundary data is what exposes < versus ≤ errors.

See the full worked example for robust and secure programming →

Selecting and justifying test data

An explicit requirement: choose the data AND say why each value was chosen.

The specification requires students to "select and justify the choice of suitable test data for a given problem." The justification is what most answers omit.

The structure that scores

Test data	Type	Reason for choosing it	Expected result
5	Normal	A typical value in the middle of the allowed range	Accepted
1	Boundary	The lowest allowed value — checks `≥` was used, not `>`	Accepted
10	Boundary	The highest allowed value — checks `≤` was used, not `<`	Accepted
0	Boundary	Immediately below the lower limit	Rejected
11	Boundary	Immediately above the upper limit	Rejected
'seven'	Erroneous	The wrong data type — a word, not a number	Rejected without crashing

A justification explains what the test would catch. Compare:

❌ "1, because it is a boundary value." (states the type, explains nothing)
✅ "1, because it is the lowest value that should be accepted — if the programmer wrote > 1 instead of ≥ 1 this test would reveal it."

Choosing test data for a specific problem

For a program accepting a percentage (0–100):

Normal: 45, 78 — ordinary values that should be accepted.
Boundary: −1, 0, 100, 101 — either side of each limit.
Erroneous: 'fifty', '', '50%' — wrong type or form.

Note −1 rather than just 0: the lower limit is 0, so the value immediately below it is −1.

Why you cannot test everything

AQA tip. Always state the expected result alongside each value. A test with no expected outcome cannot fail — you would have nothing to compare the actual behaviour against.

You must select AND justify test data — the justification is what most answers miss.
A justification says what the test would catch, not just what type it is.
Present test data as a table: value, type, reason, expected result.
For a 0–100 range the lower boundary values are −1 and 0.
Always state the expected result — a test with no expected outcome cannot fail.

See the full worked example for robust and secure programming →

Syntax errors and logic errors

Syntax = it will not run. Logic = it runs but is wrong. Be able to categorise both.

The specification requires you to understand the two types of error and to identify and categorise errors within algorithms and programs.

Syntax error

An error that breaks the rules (grammar) of the programming language, so the program will not run at all.

The translator (compiler or interpreter, 3.4.4) detects it and reports it before execution.

IF x > 5                    # missing THEN
OUTPUT 'Hello               # missing closing quotation mark
FOR i ← 1 TO 10             # missing ENDFOR
prnt('Hello')               # misspelled keyword

Key point: the program cannot run. You are told where the problem is, which makes syntax errors comparatively easy to fix.

Logic error

An error where the program runs successfully but produces the wrong result.

The syntax is perfectly legal, so nothing is reported — the program simply does the wrong thing.

average ← a + b / 2              # precedence — should be (a + b) / 2
IF age > 18 THEN                 # should be ≥ 18 — excludes exactly 18
FOR i ← 0 TO LEN(a)              # off-by-one — reads past the end
IF mark ≥ 0 OR mark ≤ 100 THEN   # should be AND — accepts everything
total ← total - price            # should be + — wrong operator

The comparison table

	Syntax error	Logic error
Cause	Breaks the language's rules	The instructions are legal but wrong
Does the program run?	No	Yes
Reported by the translator?	Yes	No
How it is found	The error message tells you	Testing and tracing
Difficulty	Easier — you are told where	Much harder — you must notice the output is wrong

Categorising errors in an exam

Ask one question: would the program run?

No → syntax error.
Yes, but the answer is wrong → logic error.

IF x = 5 THEN
    OUTPUT 'Five'
# no ENDIF                        → SYNTAX (will not run)

IF x = 5 THEN
    OUTPUT 'Four'
ENDIF                             → LOGIC (runs, wrong output)

Syntax error = breaks the language's rules; the program will not run; the translator reports it.
Logic error = the program runs but gives the wrong result; nothing is reported.
To categorise, ask: would the program run at all?
Logic errors are far more dangerous because nothing draws attention to them.
The specification names only syntax and logic — use those two terms.

See the full worked example for robust and secure programming →

Quick recap

Validation checks entered data is sensible and allowed — it cannot check the data is true.
The three named routines: minimum length, empty string, and range check.
Validation must loop until the input is valid; a single IF detects but does not fix.
Authentication uses a username and PLAIN TEXT password — encryption is not required.
Both username AND password must match; using OR is a serious security flaw.
Test data types: normal (typical), boundary (extreme), erroneous.
For the range 1 to 10, boundary data is 0, 1, 10, 11 — either side of each limit.
Erroneous data is the wrong type; a number just outside the range is boundary data.
You must select AND justify test data, stating what each test would catch.
Syntax error = will not run; logic error = runs but produces the wrong result.

Memorise this

Verbatim phrases and definitions Cambridge mark schemes credit.

The three validation routines: minimum string length, empty string, range check (e.g. between 1 and 10).
Validation must LOOP — use REPEAT…UNTIL so the input is re-requested.
Authentication: username and PLAIN TEXT password. Encryption is NOT required.
Username AND password must both match — never OR.
Three types of test data: normal (typical), boundary (extreme), erroneous.
For the range 1 to 10, boundary data is 0, 1, 10, 11.
Erroneous = wrong TYPE. A number just outside the range is BOUNDARY, not erroneous.
Syntax error: breaks the rules of the language, the program will NOT run.
Logic error: the program RUNS but gives the WRONG result.

How it’s examined

Take this whole topic with you

Step-by-step worked examples — Robust and secure programming

Step-by-step solutions to past-paper-style questions on robust and secure programming, written exactly the way a tutor would explain them at the board.

Question type:

1Distinguish syntax errors from logic errors (4 marks)
Getting startedIdentify & classify• Paper 1 style — 4 marks (AO1/AO2)• syntax-error, logic-error, categorise
Question
(a) State the difference between a syntax error and a logic error. (b) Categorise each of the following as a syntax error or a logic error:

(i) OUTPUT 'Hello (missing closing quotation mark) (ii) average ← a + b / 2 when the intention was (a + b) / 2 (4 marks)
Step-by-step solution
1. Step 1
  (a) Syntax error breaks the rules of the programming language, so the program will not run — the translator reports it before execution begins.
2. Step 2
  Logic error means the program runs successfully but produces the wrong result, because the instructions are legal but do not do what was intended.
3. Step 3
  (b)(i) A missing quotation mark breaks the language's rules, so the program cannot run — a syntax error.
4. Step 4
  (b)(ii) The line is perfectly legal and runs, but operator precedence divides b by 2 before adding a, giving the wrong average — a logic error.
Answer
(a) A syntax error breaks the rules of the programming language, so the program will not run at all and the translator reports it (1). A logic error means the program runs successfully but produces the wrong result, because the instructions are legal but do not achieve what was intended, and nothing is reported (1).

(b)(i) Syntax error — the missing quotation mark breaks the language's rules so the program cannot run (1). (b)(ii) Logic error — the line runs perfectly, but because division is evaluated before addition it calculates a + (b / 2) rather than the intended average (1). (4)
Examiner tip
The test for categorising is a single question: would the program run? If no, it is a syntax error; if yes but the answer is wrong, it is a logic error. Candidates often label an obviously-wrong line as a syntax error because it 'looks broken', but legality is what decides it, not whether a human can see the mistake.
2Give normal, boundary and erroneous test data (4 marks)
Getting startedIdentify & classify• Paper 1 style — 4 marks (AO2)• test-data, boundary, erroneous
Question
A program accepts a whole number between 1 and 10 inclusive.

(a) Give one item of normal test data. (b) Give all four items of boundary test data. (c) Give one item of erroneous test data. (d) Explain why 11 is boundary data rather than erroneous data. (4 marks)
Step-by-step solution
1. Step 1
  (a) Normal data is a typical value comfortably inside the range — for example 5.
2. Step 2
  (b) Boundary data sits either side of each limit. The limits are 1 and 10, so the four values are 0, 1, 10, 11 — exactly the specification's own example.
3. Step 3
  (c) Erroneous data is of the wrong type or form entirely — the word 'seven', an empty entry, or a symbol.
4. Step 4
  (d) 11 is a perfectly valid whole number — the right type — that simply falls outside the permitted range, which makes it boundary data. Erroneous data is data the program could not sensibly interpret at all.
Answer
(a) 5 — a typical value within the allowed range (1). (b) 0, 1, 10 and 11 — the values either side of each limit (1). (c) 'seven' (or an empty entry, or a symbol such as '£') — data of the wrong type (1). (d) 11 is boundary data because it is a valid whole number of the correct data type, which simply lies just outside the permitted range. Erroneous data is of the wrong type or form entirely, such as a word where a number is expected, which the program could not interpret as a number at all (1). (4)
Examiner tip
Part (b) matches AQA's own worked example in the specification: 'If the allowed range is 1 to 10, then boundary data is 0, 1, 10, 11.' All four values are needed — giving only 1 and 10 misses the pair just outside. Part (d) tests the distinction most often confused, and the deciding factor is the data type, not whether the value is accepted.
3Write a range validation routine (4 marks)
Getting startedMulti-step problem• Paper 1 style — 4 marks (AO3)• validation, range-check, loop
Question
Write a validation routine using pseudo-code that keeps asking the user for a number until they enter one between 1 and 10 inclusive, giving a helpful message each time an invalid number is entered. (4 marks)
Step-by-step solution
1. Step 1
  Choose the loop. A number must be obtained before it can be tested, so this needs condition-at-the-end iteration — REPEAT…UNTIL.
2. Step 2
  Prompt and convert. USERINPUT returns a string, so it must be converted before a numeric comparison.
3. Step 3
  The invalid test uses OR: num < 1 OR num > 10 — failing either limit makes it invalid.
4. Step 4
  The UNTIL states the valid condition using AND: num ≥ 1 AND num ≤ 10. Note 'inclusive' means both 1 and 10 must be accepted.
Answer
REPEAT OUTPUT 'Enter a number between 1 and 10' num ← STRING_TO_INT(USERINPUT) IF num < 1 OR num > 10 THEN OUTPUT 'Invalid — the number must be between 1 and 10' ENDIF UNTIL num ≥ 1 AND num ≤ 10

Marks: REPEAT…UNTIL used so the input is obtained before being tested (1); input prompted and converted (1); correct invalid test using OR with a specific error message (1); correct UNTIL condition using AND with ≥ and ≤ so 1 and 10 are both accepted (1). (4)
Examiner tip
Two details carry marks. The loop is essential — a single IF would detect the error and then use the invalid value anyway. And 'inclusive' requires ≥ and ≤, so testing with the boundary values 1 and 10 must both succeed; writing > and < would reject them.
4Write an authentication routine with limited attempts (5 marks)
Building confidenceMulti-step problem• Paper 1 style — 5 marks (AO3)• authentication, password, loop, boolean-flag
Question
Write an authentication routine using pseudo-code. The user has a maximum of three attempts to enter the correct username and password. On success the program outputs 'Access granted' and stops asking immediately; after three failures it outputs 'Locked out'. The correct details are stored in STORED_USER and STORED_PASS. (5 marks)
Step-by-step solution
1. Step 1
  Initialise a counter and a Boolean flag before the loop: attempts ← 0 and access ← False.
2. Step 2
  Use a compound loop condition — attempts < 3 AND access = False — so the loop ends either when the attempts run out or as soon as access is granted.
3. Step 3
  Both credentials must match, so the test uses AND. Using OR would grant access to anyone who got just one of them right.
4. Step 4
  Increment the counter every time round, and set the flag only on a successful match.
5. Step 5
  After the loop, test the flag to decide which message to output — the loop can end for two different reasons.
Answer
attempts ← 0 access ← False WHILE attempts < 3 AND access = False OUTPUT 'Enter username' username ← USERINPUT OUTPUT 'Enter password' password ← USERINPUT attempts ← attempts + 1 IF username = STORED_USER AND password = STORED_PASS THEN access ← True ELSE OUTPUT 'Incorrect — attempt ', attempts, ' of 3' ENDIF ENDWHILE IF access = True THEN OUTPUT 'Access granted' ELSE OUTPUT 'Locked out' ENDIF

Marks: counter and Boolean flag initialised (1); compound loop condition allowing both an attempt limit and an early exit (1); both credentials tested with AND (1); attempts incremented each time round the loop (1); correct message chosen after the loop by testing the flag (1). (5)
Examiner tip
The compound condition attempts < 3 AND access = False is what makes the routine stop immediately on success as the question requires — a plain FOR i ← 1 TO 3 loop cannot exit early. Note the specification requires plain text passwords only, so comparing directly against the stored value is exactly what is expected at GCSE; no encryption is needed.

5Produce a complete test plan (5 marks)

Building confidenceWord problem• Paper 1 style — 5 marks (AO3)• test-data, test-plan, justify

Question

A program accepts a student's percentage score, which must be a whole number between 0 and 100 inclusive.

Produce a test plan giving one item of normal data, all boundary data, and one item of erroneous data. For each, state the expected result. (5 marks)

Step-by-step solution

Step 1
Identify the limits. The lower limit is 0 and the upper limit is 100.
Step 2
Boundary data sits either side of each limit. Lower limit 0 gives −1 and 0; upper limit 100 gives 100 and 101.
Step 3
Note the lower boundary carefully. Because the limit is 0, the value just below it is −1, not 0.
Step 4
Normal data is a typical mid-range value such as 65.
Step 5
Always state the expected result — a test with no expected outcome cannot fail, because there would be nothing to compare the actual behaviour against.

Answer

Test data	Type	Expected result
65	Normal	Accepted — a typical valid score
−1	Boundary	Rejected — just below the lower limit
0	Boundary	Accepted — the lowest allowed value
100	Boundary	Accepted — the highest allowed value
101	Boundary	Rejected — just above the upper limit
`'sixty'`	Erroneous	Rejected without crashing — wrong data type

Examiner tip

6Categorise errors in a program (5 marks)
Building confidenceIdentify & classify• Paper 1 style — 5 marks (AO2/AO3)• syntax-error, logic-error, identify-error
Question
For each line below, state whether it contains a syntax error or a logic error, and explain your reasoning.

(a) IF score > 5 — the THEN is missing (b) IF age > 18 THEN — when the rule is 'aged 18 or over' (c) FOR i ← 0 TO LEN(a) — where a has LEN(a) elements indexed from 0 (d) total ← total - price — when items are being added to a basket (e) OUTPUT 'Total: , total — a quotation mark is missing (5 marks)
Step-by-step solution
1. Step 1
  (a) A missing THEN breaks the language's rules, so the program will not run — syntax error.
2. Step 2
  (b) The line is legal and runs, but > excludes exactly 18 when the rule says 18 should be included — logic error (an off-by-one).
3. Step 3
  (c) Legal code that runs, but the loop goes one iteration too far and accesses an index that does not exist — logic error in the loop bounds.
4. Step 4
  (d) Perfectly legal, but subtracting instead of adding gives the wrong total — logic error, the wrong operator.
5. Step 5
  (e) A missing quotation mark breaks the language's rules — syntax error.
Answer
(a) Syntax error — the missing THEN breaks the rules of the language, so the program will not run (1). (b) Logic error — the code runs, but > excludes an age of exactly 18 when the rule states 18 should be accepted; it should be ≥ (1). (c) Logic error — the code runs, but the loop performs one iteration too many and accesses index LEN(a), which does not exist in an array indexed from 0; the bound should be LEN(a) - 1 (1). (d) Logic error — the code runs, but subtracting the price instead of adding it produces a completely wrong total (1). (e) Syntax error — the missing quotation mark means the string is never closed, so the program will not run (1). (5)
Examiner tip
Three of the five are logic errors, which reflects reality: syntax errors are caught immediately by the translator, whereas logic errors survive into working programs. Note that (c) causes a crash during execution — but the underlying fault is a logic error in the loop bounds, and since the specification names only syntax and logic, that is the correct category.

7Select and justify test data (6 marks)

StretchWord problem• Paper 1 style — 6 marks (AO3)• test-data, justify, boundary

Question

A theme park ride requires riders to be at least 130 cm and no more than 200 cm tall.

Select five items of test data for the height validation, stating the type of each and justifying why you chose it. (6 marks)

Step-by-step solution

Step 1
Identify both limits: 130 (lower) and 200 (upper), both inclusive.
Step 2
Boundary values at the lower limit: 129 (just below, must be rejected) and 130 (the lowest allowed, must be accepted).
Step 3
Boundary values at the upper limit: 200 (the highest allowed, must be accepted) and 201 (just above, must be rejected).
Step 4
Add normal data — a typical value such as 165 — to confirm ordinary cases work.
Step 5
Justify by saying what each test would catch, not merely what type it is. 130 catches a > written where ≥ was needed.
Step 6
Consider erroneous data too — a non-numeric entry should be rejected without crashing.

Answer

Test data	Type	Justification	Expected result
165	Normal	A typical rider height comfortably inside the range, confirming ordinary cases are handled	Accepted
129	Boundary	The value immediately below the lower limit — confirms riders just too short are correctly refused	Rejected
130	Boundary	The lowest allowed height — would reveal a programmer writing `> 130` instead of `≥ 130`, which would wrongly refuse a rider of exactly 130 cm	Accepted
200	Boundary	The highest allowed height — would reveal `< 200` written instead of `≤ 200`	Accepted
201	Boundary	The value immediately above the upper limit — confirms riders just too tall are refused	Rejected

(A sixth valuable test is erroneous data such as 'tall', which should be rejected without crashing.)

Examiner tip

8Write a complete robust input routine (8 marks)
StretchMulti-step problem• Paper 1 style — 8 marks (AO3)• validation, subroutine, range-check, empty-string
Question
Write a subroutine called getValidName that repeatedly asks for a name until the entry is not empty and is at least 2 characters long, then returns it. Then write a second subroutine getValidAge that repeatedly asks for an age until it is between 0 and 120 inclusive, then returns it.

Give a specific error message for each type of failure. (8 marks)
Step-by-step solution
1. Step 1
  Both routines need condition-at-the-end iteration, since a value must be obtained before it can be tested.
2. Step 2
  The empty check is LEN(name) = 0, one of the three routines named in the specification.
3. Step 3
  The minimum length check is LEN(name) < 2. 'At least 2' means exactly 2 must be accepted.
4. Step 4
  Separate IF branches allow a different message for each failure rather than one generic 'invalid'.
5. Step 5
  The age routine uses a range check with AND in the UNTIL and OR in the invalid test.
6. Step 6
  Both routines RETURN the validated value, so the calling program receives clean data it can trust.
Answer
SUBROUTINE getValidName() REPEAT OUTPUT 'Enter your name (at least 2 characters)' name ← USERINPUT IF LEN(name) = 0 THEN OUTPUT 'You must enter something' ELSE IF LEN(name) < 2 THEN OUTPUT 'Too short — the name must be at least 2 characters' ENDIF UNTIL LEN(name) ≥ 2 RETURN name ENDSUBROUTINE SUBROUTINE getValidAge() REPEAT OUTPUT 'Enter your age (0-120)' age ← STRING_TO_INT(USERINPUT) IF age < 0 OR age > 120 THEN OUTPUT 'Invalid — the age must be between 0 and 120' ENDIF UNTIL age ≥ 0 AND age ≤ 120 RETURN age ENDSUBROUTINE # Main program userName ← getValidName() userAge ← getValidAge() OUTPUT userName, ' is ', userAge, ' years old'

Marks: getValidName uses REPEAT…UNTIL (1); empty check using LEN(name) = 0 (1); minimum length check using LEN(name) < 2 with a separate message (1); returns the validated name (1); getValidAge uses REPEAT…UNTIL with the input converted (1); correct range check using OR for invalid and AND for valid (1); returns the validated age (1); both subroutines called and their returned values used in the main program (1). (8)
Examiner tip
This question combines 3.2.11 with 3.2.10 subroutines, 3.2.8 string length and 3.2.2 iteration — which is exactly how validation is examined at the top of the tariff. Wrapping validation in a subroutine is the strongest design point: the rule exists in one place, can be tested independently, and can be reused for every name the program needs.
9Find and fix the faults in a validation routine (6 marks)
StretchIdentify & classify• Paper 1 style — 6 marks (AO3)• debugging, validation, identify-error, authentication
Question
The routine below should accept a mark between 0 and 100 and then check a password. It contains three faults. Identify each, state whether it is a syntax or a logic error, explain its effect, and write a corrected version. (6 marks)

1 OUTPUT 'Enter a mark' 2 mark ← STRING_TO_INT(USERINPUT) 3 IF mark < 0 OR mark > 100 THEN 4 OUTPUT 'Invalid' 5 ENDIF 6 total ← total + mark 7 8 OUTPUT 'Enter password' 9 pass ← USERINPUT 10 IF user = STORED_USER OR pass = STORED_PASS THEN 11 OUTPUT 'Access granted' 12 ENDIF
Step-by-step solution
1. Step 1
  Fault 1 — lines 3–6: validation does not loop. The IF detects an invalid mark and prints a message, but line 6 then adds that invalid mark to the total anyway.
2. Step 2
  Category and fix. This is a logic error — the code runs perfectly. It must be replaced with a REPEAT…UNTIL loop that re-requests the input.
3. Step 3
  Fault 2 — line 10 uses OR instead of AND. Anyone who knows either the username or the password alone would be granted access.
4. Step 4
  Category. Also a logic error, and a serious security flaw — the routine runs without any error.
5. Step 5
  Fault 3 — there is no ELSE on the authentication check, so a failed login produces no output at all and the user receives no feedback.
6. Step 6
  Write the corrected version with a validation loop, AND in the credentials test, and an ELSE branch.
Answer
Fault 1 — the validation does not loop (lines 3–6). This is a logic error (1). The IF detects an invalid mark and prints a message, but the program then continues and adds that invalid mark to the total anyway on line 6 — so the validation achieves nothing (1).

Fault 2 — line 10 uses OR instead of AND. Also a logic error (1). With OR, satisfying either condition is enough, so anyone who knew just the username — or just the password — would be granted access, which is a serious security flaw (1).

Fault 3 — there is no ELSE branch for a failed login. A user who enters incorrect details receives no output at all and is given no indication that the attempt failed (1).

Corrected version:

REPEAT OUTPUT 'Enter a mark between 0 and 100' mark ← STRING_TO_INT(USERINPUT) IF mark < 0 OR mark > 100 THEN OUTPUT 'Invalid — must be between 0 and 100' ENDIF UNTIL mark ≥ 0 AND mark ≤ 100 total ← total + mark OUTPUT 'Enter username' user ← USERINPUT OUTPUT 'Enter password' pass ← USERINPUT IF user = STORED_USER AND pass = STORED_PASS THEN OUTPUT 'Access granted' ELSE OUTPUT 'Access denied' ENDIF

(1)
Examiner tip
Both major faults are logic errors — the program runs cleanly and produces no error message, which is exactly what makes them dangerous. Fault 1 is the single most common validation mistake at GCSE: detection without a loop is not validation. Note the original also never asks for a username, which is a further omission worth spotting.

Model Answers — Robust and secure programming

High-scoring sample answers for robust and secure programming on the AQA GCSE 8525 paper, with examiner-style notes mapping each response to the mark scheme and assessment objectives.

Question 1
Paper 1 style — AO13 marks
State the three types of test data described in the specification. (3 marks)
Model answer
Normal (typical) data (1), boundary (extreme) data (1) and erroneous data (1).
Why this scores
The bracketed alternatives — typical and extreme — are the specification's own wording and are equally acceptable. These three are the complete list; 'invalid data' is not a separate named category.
Question 2
Paper 1 style — AO22 marks
A program accepts values in the range 1 to 10. State the boundary test data. (2 marks)
Model answer
0, 1, 10 and 11 (2 marks — 1 for the pair around the lower limit, 1 for the pair around the upper limit).

These are the values either side of each boundary: 0 and 1 at the lower limit, 10 and 11 at the upper limit.
Why this scores
This is AQA's own example from the specification. All four values are required — giving only 1 and 10 misses the values just outside the range, which are what confirm invalid entries are correctly rejected. Boundary data always comes in pairs around each limit.
Question 3
Paper 1 style — AO11 mark
State what the specification says about the passwords used in authentication routines at GCSE. (1 mark)
Model answer
Only plain text usernames and passwords are required — students do not need to encrypt the passwords (1).
Why this scores
This is an explicit boundary in the specification's additional information column. Comparing a typed password directly against a stored one is exactly what is expected, so no hashing or encryption should appear in an answer. Noting that plain-text storage is a real-world weakness is still a valid evaluative comment.
Question 4
Paper 1 style — AO2/AO34 marks
Explain why a validation routine must use a loop rather than a single IF statement. (4 marks)
Model answer
A single IF statement can only detect that the data is invalid and display a message — it has no way of obtaining a replacement value (1). Once the IF has finished, the program simply carries on to the next line with the invalid value still stored in the variable, so it is used anyway and the validation achieves nothing (1).

A loop repeatedly re-requests the input until a valid value is entered (1), so the program cannot proceed until the data is acceptable — which guarantees that everything after the loop is working with valid data (1).

The natural structure is condition-at-the-end iteration (REPEAT…UNTIL), because a value must be obtained before it can be tested.
Why this scores
The decisive point is that after a single IF, the bad value is still there — students often think the message somehow prevents its use. The final observation about REPEAT…UNTIL links to 3.2.2 and shows why validation is the classic application of condition-at-the-end iteration.
Question 5
Paper 1 style — AO24 marks
Explain the difference between boundary test data and erroneous test data, using a program that accepts ages between 5 and 18 as an example. (4 marks)
Model answer
Boundary test data consists of values at the very edges of the allowed range and immediately either side of them (1). For a range of 5 to 18 that would be 4, 5, 18 and 19 — all valid whole numbers of the correct data type, where 5 and 18 should be accepted and 4 and 19 rejected (1).

Erroneous test data is data of the wrong type or form entirely, which the program could not sensibly interpret at all (1) — for example the word 'ten', an empty entry, or a symbol such as '#', none of which is a number, and all of which should be rejected without the program crashing (1).

The key distinction is that 19 is boundary data rather than erroneous data, because it is a perfectly valid number that simply falls outside the permitted range.
Why this scores
The final sentence is the discriminator and is what the question is really testing. The deciding factor is the data type: boundary data is the right type in the wrong place, whereas erroneous data is the wrong type altogether. Note the requirement that erroneous data be rejected without crashing.
Question 6
Paper 1 style — AO34 marks
A program calculates a mean using mean ← total / count. When count is 0 the program crashes. Explain what type of error this is and how it could be prevented. (4 marks)
Model answer
This is a logic error (1). The line is perfectly legal, so the program runs — the translator reports nothing and the fault only appears when count happens to be 0, at which point the program attempts to divide by zero and crashes (1).

It could be prevented by using selection to check the value before dividing (1):

IF count = 0 THEN OUTPUT 'No data entered — cannot calculate a mean' ELSE mean ← total / count OUTPUT 'Mean: ', mean ENDIF

This guard means the division is only ever attempted when it is safe, and the user receives a clear message instead of a crash (1).
Why this scores
Some sources would call the crash itself a runtime error, but the specification names only syntax and logic, and the underlying fault — failing to guard the division — is a logic error. Note the bug is conditional: it appears only for one particular value of count, which is precisely why boundary and erroneous test data matter.

Question 7

Paper 1 style — AO38 marks

A program accepts a username that must be between 5 and 12 characters long, and a PIN that must be a whole number between 1000 and 9999.

Produce a complete test plan covering both inputs, giving normal, boundary and erroneous data with justifications and expected results. (8 marks)

Model answer

Username (5 to 12 characters)

Test data	Type	Justification	Expected
`'amina'` (5)	Boundary	The shortest allowed — reveals `> 5` written instead of `≥ 5`	Accepted
`'abcd'` (4)	Boundary	Immediately below the minimum	Rejected
`'abcdefghijkl'` (12)	Boundary	The longest allowed — reveals `< 12` written instead of `≤ 12`	Accepted
`'abcdefghijklm'` (13)	Boundary	Immediately above the maximum	Rejected
`'student'` (7)	Normal	A typical username comfortably within range	Accepted
`''` (empty)	Erroneous	Nothing entered at all — must not crash	Rejected

PIN (1000 to 9999)

Test data	Type	Justification	Expected
5678	Normal	A typical four-digit PIN	Accepted
999	Boundary	Immediately below the minimum	Rejected
1000	Boundary	The lowest allowed value	Accepted
9999	Boundary	The highest allowed value	Accepted
10000	Boundary	Immediately above the maximum	Rejected
`'abcd'`	Erroneous	Letters where a number is required — must be rejected without crashing	Rejected

Why this scores

Question 8
Paper 1 style — AO36 marks
Explain what is meant by robust programming, and discuss why validation alone cannot guarantee that the data a program holds is correct. (6 marks)
Model answer
Robust programming means writing programs that continue to behave sensibly when they receive unexpected or invalid input, rather than crashing or producing nonsense (1). It is achieved through validation routines that check data is acceptable before it is used, loops that re-request input until it is valid, and testing with normal, boundary and erroneous data to confirm the program copes with all three (1).

However, validation checks only that data is plausible, not that it is true. A range check confirms an age lies between 0 and 120, but if a user enters 35 when they are actually 34, the value passes every possible check because 35 is a perfectly reasonable age (1). No validation rule can detect this, because the program has no independent source of truth to compare the entry against (1).

The same applies to any well-formed but incorrect entry — a misspelled name, a transposed pair of digits in a phone number, or a date of birth in the wrong format that still happens to be a valid date (1).

What can help is confirmation: echoing the data back to the user before it is committed, so they can spot their own mistake — which catches a class of error that validation is structurally incapable of finding (1). (6)
Why this scores
The distinction between plausible and true is the top-band idea and should lead the second half of the answer. The strongest supporting point is that the program has no independent source of truth against which to check a well-formed entry, and that confirmation is therefore a genuinely different safeguard rather than just more validation.
Question 9
Paper 1 style — AO1/AO36 marks
Compare syntax errors and logic errors, explaining why logic errors are generally more difficult to find and correct. (6 marks)
Model answer
Syntax errors break the rules of the programming language, such as a missing ENDIF or an unclosed quotation mark (1). Because the code is not valid, the translator cannot process it and the program will not run at all — instead it reports the error, usually identifying the line where it occurred (1).

Logic errors occur where the code is entirely legal but does not do what the programmer intended — using > where ≥ was needed, or subtracting where addition was required (1). The program therefore runs successfully and produces output; it is simply the wrong output (1).

Why logic errors are harder to find. A syntax error announces itself immediately and points you to its location, so it can usually be corrected in seconds (1). A logic error produces no message of any kind: the programmer must first notice that the output is wrong, which may not be obvious if the answer looks plausible, and then trace through the program to work out where the reasoning went astray. A subtly wrong grade boundary or total could go unnoticed for a long time — and some logic errors surface only for particular inputs, such as an off-by-one that fails only at a boundary value, making them harder still to reproduce and diagnose (1). (6)
Why this scores
The strongest closing point is that a logic error may appear only for particular inputs, which explains both why boundary test data matters and why some faults survive extensive testing. Note the neat link: a syntax error is caught by the translator (3.4.4), whereas a logic error can only be caught by testing (3.2.11).

Key Definitions and Keywords — Robust and secure programming

Definitions to memorise and the exact keywords mark schemes credit for robust and secure programming answers — sharpened from recent examiner reports for the 2026 AQA GCSE 8525 sitting.

Validation
Examiner keyword
Checking that data entered by a user is sensible and allowed before the program uses it. Validation confirms data is plausible, not that it is correct.
Example
Checking a mark lies between 0 and 100.
Related: Range check, Length check, Authentication
Length check
Examiner keyword
A validation routine confirming a string has at least a stated number of characters. One of the three routines named in the specification.
Example
IF LEN(password) < 8 THEN OUTPUT 'Too short'
Related: Presence check, Validation
Empty string check
Examiner keyword
A validation routine confirming the user has actually entered something, by testing whether the string's length is 0. One of the three routines named in the specification.
Example
IF LEN(name) = 0 THEN OUTPUT 'You must enter a name'
Related: Length check, Validation
Range check
Examiner keyword
A validation routine confirming a value lies within permitted limits. Requires two comparisons joined with AND. The specification's example is 'between 1 and 10'.
Example
UNTIL num ≥ 1 AND num ≤ 10
Related: Validation, Boundary data
Authentication
Examiner keyword
Checking that a user is who they claim to be, normally with a username and password. At GCSE only plain text passwords are required — encryption is not needed.
Example
IF username = STORED_USER AND password = STORED_PASS THEN
Related: Plain text, Validation
Plain text
Examiner keyword
Data stored or compared in its readable, unencrypted form. The specification requires only plain text usernames and passwords, so encryption is explicitly not needed.
Related: Authentication
Testing
Examiner keyword
Running a program with chosen data to check it behaves as expected, so that errors can be found and corrected.
Related: Test data, Syntax error, Logic error
Test data
Examiner keyword
Data chosen deliberately to check a program works correctly. The three types are normal (typical), boundary (extreme) and erroneous.
Related: Normal data, Boundary data, Erroneous data
Normal (typical) test data
Examiner keyword
Sensible data of the expected type that the program will meet in ordinary use, and which should be accepted and processed correctly.
Example
5 for a program accepting values from 1 to 10.
Related: Boundary data, Erroneous data
Boundary (extreme) test data
Examiner keyword
Values at the very edges of the allowed range and immediately either side of them. For an allowed range of 1 to 10, boundary data is 0, 1, 10, 11.
Related: Normal data, Erroneous data, Off by one error
Erroneous test data
Examiner keyword
Data of the wrong type or form entirely, which the program should reject without crashing. Distinct from boundary data, which is the right type but outside the permitted range.
Example
Entering 'seven' where a number is expected.
Related: Boundary data, Normal data
Syntax error
Examiner keyword
An error that breaks the rules of the programming language, so the program will not run at all. Detected and reported by the translator before execution.
Example
A missing ENDIF, or an unclosed quotation mark.
Related: Logic error, Translator
Logic error
Examiner keyword
An error where the program runs successfully but produces the wrong result, because the instructions are legal but do not do what was intended. Not reported by the translator.
Example
Using > where ≥ was needed, or subtracting instead of adding.
Related: Syntax error, Testing
Robust program
Examiner keyword
A program that continues to behave sensibly when given unexpected or invalid input, rather than crashing or producing nonsense. Achieved through validation, loops and thorough testing.
Related: Validation, Testing
Off-by-one error
Examiner keyword
A logic error where a condition or loop includes or excludes exactly one value more than intended, usually caused by < where ≤ was needed. Exposed by boundary test data.
Related: Logic error, Boundary data

Common Mistakes and Misconceptions — Robust and secure programming

The traps other students keep falling into on robust and secure programming questions — taken from recent AQA GCSE 8525 examiner reports and mark schemes — and how to avoid them.

✕Writing validation as a single IF statement that displays a message but never re-requests the input.
AQA 8525 specification 3.2.11 requires students to write simple data validation routines; single-IF 'validation' is the most common fault in this subtopic.
Why it happens
The IF correctly detects the problem and produces an error message, which feels like the whole job — students do not picture what happens on the very next line, where the invalid value is still sitting in the variable.
How to avoid it
Validation must loop: use REPEAT … UNTIL <valid> so the input is requested again until it passes. Then trace your own routine with a deliberately invalid value and follow what happens next — you will see the bad value being used anyway. Detection without re-asking is not validation.
✕Giving only two boundary values — 1 and 10 for a range of 1 to 10 — instead of all four.
AQA 8525 specification 3.2.11 additional information gives 0, 1, 10, 11 as the worked example.
Why it happens
The limits themselves are the obvious 'edge' values, and it is easy to overlook that the values just outside the range are equally part of the boundary test.
How to avoid it
Boundary data comes in pairs around each limit, so a range with two limits needs four values. AQA's own example is explicit: for the range 1 to 10, boundary data is 0, 1, 10, 11. The pair inside confirms valid values are accepted; the pair outside confirms invalid ones are rejected.
✕Classifying a number just outside the allowed range as erroneous data.
Test-data questions frequently ask for one item of each type specifically to test this distinction.
Why it happens
Both boundary-outside data and erroneous data get rejected, so they feel like the same category — the classification is based on the outcome rather than on the data itself.
How to avoid it
The deciding factor is the data type, not whether it is accepted. For a range of 1 to 10, 11 is boundary data — a perfectly valid whole number that simply falls outside the range. Erroneous data is the wrong type entirely, such as the word 'seven' or an empty entry.
✕Listing test data without justifying why each value was chosen.
AQA 8525 specification 3.2.11: 'Be able to select and justify the choice of suitable test data for a given problem.'
Why it happens
Producing the correct values feels like the substance of the answer, and the justification looks like restating the obvious — so it gets omitted under time pressure.
How to avoid it
The specification requires you to select and justify test data. A justification says what the test would catch: not '1, because it is a boundary value' but '1, because it is the lowest allowed value, so it would reveal a programmer using > instead of ≥'. Always state the expected result too — a test with no expected outcome cannot fail.
✕Labelling a wrong operator or a wrong comparison as a syntax error.
AQA 8525 specification 3.2.11 requires students to identify and categorise errors as syntax or logic.
Why it happens
The code is visibly wrong to a human reader, so it feels 'broken' — and 'syntax error' is the more familiar term, so it becomes the default label for anything faulty.
How to avoid it
Ask one question: would the program run? If it runs and simply gives the wrong answer, it is a logic error, however obviously mistaken the line looks. A syntax error means the code is not valid in the language at all, so the translator refuses to process it and execution never begins.
✕Writing an authentication check as username = STORED_USER OR password = STORED_PASS.
Authentication routines are named in 3.2.11, and OR-instead-of-AND is a standard fault in error-identification questions.
Why it happens
Read aloud, 'if the username or the password matches' sounds reasonable, and because the routine grants access to a correct login it appears to work during casual testing.
How to avoid it
Both credentials must match, so the operator is AND. Test the faulty version deliberately with a correct username and a wrong password: the OR version grants access, which is a serious security flaw. If either half alone is enough, the password is doing no work at all.

Robust and secure programming

Detailed Study Notes

At a glance

What you’ll learn

Data validation routines

The three routines AQA names

The rule that carries the most marks: validation must LOOP

Authentication routines

A basic authentication routine

With a limited number of attempts

Why real systems do more (worth a sentence in evaluation questions)

Testing and the three types of test data

The three types

Boundary data — AQA's own example

Erroneous data is not the same as boundary data

Selecting and justifying test data

The structure that scores

Choosing test data for a specific problem

Why you cannot test everything

Syntax errors and logic errors

Syntax error

Logic error

The comparison table

Categorising errors in an exam

Quick recap

Memorise this

How it’s examined

Take this whole topic with you

1Distinguish syntax errors from logic errors (4 marks)

2Give normal, boundary and erroneous test data (4 marks)

3Write a range validation routine (4 marks)

4Write an authentication routine with limited attempts (5 marks)

5Produce a complete test plan (5 marks)

6Categorise errors in a program (5 marks)

7Select and justify test data (6 marks)

8Write a complete robust input routine (8 marks)

9Find and fix the faults in a validation routine (6 marks)

Validation

Length check

Empty string check

Range check

Authentication

Plain text

Testing

Test data

Normal (typical) test data

Boundary (extreme) test data

Erroneous test data

Syntax error

Logic error

Robust program

Off-by-one error

✕Writing validation as a single IF statement that displays a message but never re-requests the input.

✕Giving only two boundary values — 1 and 10 for a range of 1 to 10 — instead of all four.

✕Classifying a number just outside the allowed range as erroneous data.

✕Listing test data without justifying why each value was chosen.

✕Labelling a wrong operator or a wrong comparison as a syntax error.

✕Writing an authentication check as username = STORED_USER OR password = STORED_PASS.

Robust and secure programming

Detailed Study Notes

At a glance

What you’ll learn

Data validation routines

The three routines AQA names

The rule that carries the most marks: validation must LOOP

Authentication routines

A basic authentication routine

With a limited number of attempts

Why real systems do more (worth a sentence in evaluation questions)

Testing and the three types of test data

The three types

Boundary data — AQA's own example

Erroneous data is not the same as boundary data

Selecting and justifying test data

The structure that scores

Choosing test data for a specific problem

Why you cannot test everything

Syntax errors and logic errors

Syntax error

Logic error

✕Writing validation as a single `IF` statement that displays a message but never re-requests the input.

✕Writing an authentication check as `username = STORED_USER OR password = STORED_PASS`.