Designing, writing, testing & refining

Good programs are built in stages, not all at once:

Design first: plan with flowcharts or pseudocode before coding. It's far cheaper to fix a mistake in the design than after the whole program is written.

Decomposing into subprograms

Break a big problem into smaller sub-problems, then write each as a subprogram (a function or procedure). This makes the program:

• Easier to write — solve one small piece at a time.
• Easier to test — check each subprogram works on its own.
• Easier to reuse and maintain — call the same subprogram whenever needed.

Example: a "quiz app" decomposes into askQuestion(), checkAnswer(), updateScore() and showResult() — each a separate subprogram doing one job.

Why use subprograms?

Types of error

• Syntax error — the code breaks the rules of the language (a missing colon, bracket or misspelt keyword). The program won't run until it's fixed.
• Logic error — the code runs but gives the wrong result because the logic is wrong (e.g. using + instead of −). The hardest to spot.
• Runtime error — the program crashes while running, e.g. dividing by zero or reading past the end of a list.

Tell them apart: won't run at all = syntax; runs but wrong answer = logic; crashes part-way = runtime.

Which error?

Choosing test data

You test a program with different kinds of data to check it behaves correctly. For a rule like "enter an age from 0 to 120":

• Normal — sensible values well inside the range (e.g. 25). Should be accepted.
• Boundary — values right at the edges (e.g. 0 and 120, and just outside like 121). Tests the limits.
• Erroneous — invalid data that should be rejected (e.g. -5, or letters like "cat").

Boundary bugs are common: off-by-one mistakes mean many bugs hide exactly at the edges — so always test the smallest and largest valid values, and one just beyond each.

Normal, boundary or erroneous?

Rule: a valid age is 0 to 120. Tap a value, then tap the type of test data it is.

Your turn — boundary value

Validation

Validation checks that input is sensible and allowed before the program uses it. Common checks:

• Range check — the value is between limits (e.g. 1–12 for a month).
• Length check — the right number of characters (e.g. a password ≥ 8).
• Presence check — a required field isn't blank.
• Type/format check — the data is the right type or pattern (e.g. an email contains "@").

Validation ≠ correct: validation only checks data is reasonable, not that it's true. "31/02/2020" might pass a format check but is still an impossible date, and a valid-looking name could still be wrong.

Which validation check?

Authentication

Authentication checks a user is who they claim to be before granting access. Methods include:

• Passwords / PINs — something you know.
• Two-factor authentication (2FA) — a password plus a code sent to your phone.
• Biometrics — fingerprint or face (something you are).
• CAPTCHA — checks a real human, not a bot, is submitting the form.

Validation vs authentication: validation checks the data is sensible; authentication checks the person is genuine. They solve different problems.

Validation or authentication?

Writing robust programs

A robust program keeps working sensibly even when things go wrong or users behave unexpectedly. To make code robust:

• Validate all inputs and re-ask if they're wrong, instead of crashing.
• Anticipate errors — handle things like empty input or division by zero.
• Authenticate users where access needs controlling.
• Test thoroughly with normal, boundary and erroneous data.
• Add comments and use clear names so it's easy to maintain.

Golden rule: "never trust the user's input." A robust program assumes people will type the wrong thing and handles it gracefully.

Match the description to the term

Tap a description on the left, then its matching term on the right.

Spot the syntax error effect

Your turn — planning tests

What makes it robust?

The big ideas to know

You've covered the whole of Edexcel Problem solving with programming. Press Finish to see your score.