Present the Mars Climate Orbiter disaster. NASA's spacecraft was destroyed because one team used metric units and another used imperial. Show the scale of consequences from simple errors. Ask: 'If professional engineers at NASA can make these mistakes, what hope do the rest of us have?' Let students discuss in pairs what went wrong and how it could have been prevented.

Define defensive design as programming with the assumption that things will go wrong. Use analogy of defensive driving - you don't just follow the rules, you anticipate what others might do wrong. Introduce the core principle: 'Never trust the user.' Discuss two categories of misuse: accidental (typos, confusion, mistakes) and deliberate (hackers, trolls, malicious users). Students brainstorm examples of each for a social media app.

Provide students with a simple calculator program (or age-checker/password-checker) that has NO defensive design. In pairs, students compete to find as many ways to break it as possible. Categories: inputs that cause errors, inputs that produce wrong results, inputs that could be security risks. Each pair lists their 'attacks' on a shared document. Class compiles a master list of vulnerabilities.

Brief introduction to bug bounty programs. Show real examples of payouts (Google has paid over $50 million to security researchers). Discuss the ethics: why is it legal when companies invite you to hack them, but illegal otherwise? Mention UK careers in cybersecurity and penetration testing.

Return to the vulnerability list from the activity. For each type of attack found, students propose a defence strategy (we'll learn the specifics next lesson). Exit ticket: 'Name one thing a user might do to break a login system, and suggest how a programmer might prevent it.'

Show the famous XKCD 'Bobby Tables' comic. Explain (simply) what happened: a parent named their child something that, when typed into a school database, deleted all records. Ask: 'How could the school's software have prevented this?' Reveal the answer: input validation - checking what users type before using it.

Define input validation as checking user input before processing it. Introduce the validation toolkit: presence check (is it empty?), type check (is it the right kind of data?), range check (is it within acceptable limits?), length check (is it the right size?), format check (does it match a pattern like email or postcode?). Use real examples: age must be 0-150, email must contain @, password must be 8+ characters.

Demonstrate (or have students follow along) building input validation for an age checker. Start with no validation (crashes on non-numbers), add type checking (try/except or try/catch), add range checking (0-150), add presence checking (not empty). Show the difference in user experience between a crash and a helpful error message.

Groups receive different scenarios: online shopping (quantity, card number), social media signup (username, email, age), school system (student ID, grade). For each input field, groups must specify: what type of data is expected, what validation checks are needed, what error messages should be shown. Groups present their validation plans to the class.

Students implement validation for one of the scenarios from the previous activity. They choose their programming language. Challenge: handle at least 3 different types of invalid input with clear error messages.

Class collaboratively creates a 'validation checklist' that could be used for any input field. Exit ticket: Given a postcode input field, list 3 validation checks needed and explain why each matters.

Show the most common passwords list (123456, password, qwerty, etc.). Discuss: why do people choose these? What's wrong with them? Show how quickly these can be cracked (instantly). Ask: 'If you were building a login system, how would you stop people using these terrible passwords?'

Define authentication as confirming identity - proving you are who you claim to be. Distinguish from authorisation (what you're allowed to do once identity is confirmed). Discuss the three factors: something you know (password), something you have (phone/key), something you are (fingerprint). Explain why username/password is 'something you know' authentication.

Live code a simple login system together. Start basic (hardcoded username/password), then improve: add input validation, limit login attempts, give appropriate error messages (not 'incorrect password' - why?). Discuss why we don't store passwords in plain text (preview, not detail).

Show two versions of the same working program - one with terrible style (no comments, single-letter variables, no indentation) and one well-written. Challenge: which would you rather have to fix or extend? Introduce the four pillars of maintainability: naming conventions, indentation, commenting, and sub programs.

Provide students with working but messy code. Their task: improve it WITHOUT changing functionality. Apply: meaningful variable names, proper indentation, helpful comments, break into sub programs where appropriate. Peer review: swap with a partner and see if they can understand your improved version.

Create a class 'code quality checklist' combining authentication best practices and maintainability standards. Exit ticket: 'Look at this code snippet. Identify two maintainability issues and explain how you would fix them.'

Tell the Cyberpunk 2077 story: massive budget, years of development, unprecedented hype, disastrous launch. Show clips of bugs (cars flying, characters T-posing). Discuss: what went wrong? Lead to the idea that testing was rushed due to deadline pressure. Ask: 'How should testing work in software development?'

Discuss the purpose of testing: finding bugs before users do, ensuring software works correctly, building confidence before release. Introduce the testing spectrum: from informal checking to formal verification. Key insight: testing can prove bugs exist but can never prove they don't.

Define iterative testing: testing during development, checking each module as you build. Define terminal testing: testing at the end, checking the complete program. Discuss advantages of each. Use Cyberpunk example: they relied too heavily on terminal testing. Class discussion: why might teams skip iterative testing? (Time pressure, overconfidence, poor planning.)

Define syntax errors: breaking the grammar rules of the language (missing brackets, typos in keywords). These stop programs running at all. Define logic errors: program runs but produces wrong output. These are harder to find. Show examples of each. Key distinction: computers catch syntax errors; humans must catch logic errors.

Provide programs with deliberate bugs - some syntax, some logic. Students work in pairs to find, categorise, and fix as many as possible within the time limit. Competitive element: teams score points for each bug found and correctly categorised. Debrief: share strategies for finding different types of bugs.

Quick-fire round: show error messages and code snippets, students classify as syntax or logic. Discuss any disagreements. Exit ticket: 'Write one example of a syntax error and one example of a logic error, and explain how you would find each one.'

Display a simple password validation rule: 'Password must be 8-20 characters.' Challenge the class: how many different tests would you need to thoroughly test this one rule? Collect suggestions. Reveal: professional testers might use 15+ tests just for this. Introduce the four types of test data as the framework for systematic testing.

Teach each type with the password example: Normal (valid passwords like 'Secure123'), Boundary (exactly 8 characters, exactly 20 characters - testing the edges), Invalid (7 characters, 21 characters - wrong length but right type), Erroneous (numbers only, empty input, special characters - wrong type entirely). Key insight: boundary testing finds the most bugs because programmers often make 'off by one' errors.

Groups receive different scenarios: age verification (13-120), exam mark input (0-100), temperature sensor (-50 to 60). For each, identify at least 2 examples of each test data type. Groups share and peer-assess: did they cover boundaries correctly? Any edge cases missed?

Introduce the test plan format: Test ID, Description, Input Data, Expected Output, Actual Output, Pass/Fail. Model creating a test plan for the password validation. Discuss: why do we write down expected output BEFORE testing? (Prevents us fooling ourselves that wrong output is 'close enough'.)

Students create a complete test plan for a given program (e.g., a grade calculator that takes a mark 0-100 and outputs a grade A-F). Must include at least 10 tests covering all four data types with particular attention to boundaries. Then they run the tests on provided code and record actual results.

Discuss: what do you do when a test fails? Introduce the debugging and refinement cycle: identify the bug, understand why it happens, fix it, re-run ALL tests (not just the failing one). Explain why: fixing one bug can accidentally create another. Show how the test plan becomes a safety net for changes.

Swap test plans with another student. Peer review: are all four data types represented? Are boundaries tested correctly? Would this test plan catch a bug? Exit ticket: 'A program accepts ages 18-65. Write four test cases: one normal, one boundary, one invalid, one erroneous, with expected outputs.'