This is part two of my walk-through of the June 2025 Paper 1 (0417/11). The three topics here — testing a new system, staying safe around ICT equipment, and telling phishing apart from pharming — are all "explain and apply" topics rather than "recall a fact" ones. That's where marks are won and lost, so I'll focus on the reasoning examiners are looking for, not just the answers.
📄 The original question paper and mark scheme are on the Cambridge International past papers page. Below I've paraphrased the questions and written the explanations in my own words.
Testing a new system (and documenting it)
One question asked why particular parts of a system are tested, what "abnormal test data" means, why technical documentation matters, and what else it contains.
The big idea. When a new system is built, testing isn't a single step — it's checking each part does its job before real users depend on it. Examiners want you to connect each element to the problem it prevents:
- File structure is tested so data is stored and retrieved correctly. Get it wrong and records corrupt or the system slows to a crawl.
- Validation routines are tested to confirm they actually trap unreasonable data — a range check is useless if it lets an age of 200 through.
- Output format is tested so results are clear, correctly laid out, and easy for the user to read. Right answer, unreadable presentation, still a fail.
Know your test data types
This is where you can pull ahead of other candidates. There isn't just "good" and "bad" data — there are four kinds, and naming them precisely scores well:
| Type of data | What it is | Example (age field 11–16) |
|---|---|---|
| Normal | Sensible data the system should accept | 13 |
| Abnormal | Data outside the limits that should be rejected | 200, or "cat" |
| Extreme | Values at the very edge of what's allowed | 11 and 16 |
| Boundary | One acceptable and one unacceptable value either side of a limit | 16 (accept) and 17 (reject) |
So when a question asks about abnormal test data, it means values deliberately chosen because they should be refused — the whole point is to prove validation catches them.
Two kinds of documentation — don't mix them up
The classic trap here is confusing the two documents produced with a system:
- Technical documentation is written for developers so they can maintain, repair or upgrade the system later. It typically includes algorithms, flowcharts, variable lists, program listings, input/output formats, hardware and software requirements, and sample test runs.
- User documentation is written for the people who use the system — manuals, help files, "how to load the program" guides.
If a question says "technical," every example you give must be developer-facing. Listing "a user guide" loses the mark instantly.
✏️ Practice it: "A school has commissioned a new library system. Describe one piece of normal test data and one piece of abnormal test data the developer could use to test the field that stores how many books a student has borrowed (maximum 5)."
Staying safe around ICT equipment
Another question asked for three ways each to reduce the risk of two specific hazards: electrocution and trailing leads.
Why students lose easy marks here. The mark scheme rewards specific, realistic actions — writing "be careful" or "don't touch wires" earns nothing. Think like a workplace health-and-safety inspector: every point should be something you could actually do to the room or the equipment.
| Hazard | How it happens | Practical ways to reduce the risk |
|---|---|---|
| Electrocution | Exposed or frayed wires, faulty sockets, liquids near devices | Fit circuit breakers (RCDs); check and replace damaged cables regularly; keep drinks away from equipment; don't overload sockets |
| Trailing leads | Cables running across walkways | Use cable ducts or trunking; tuck cables under carpets or along skirting; bundle them with cable ties; switch to wireless devices to remove cables altogether |
Notice each solution is concrete and different from the others — if a question wants three different ways, three versions of "tidy the cables" won't all score. Vary the approach.
✏️ Practice it: "A computer room has just been refitted. Identify one other safety hazard not mentioned above and describe two ways the school could reduce it."
Phishing vs pharming — the difference that matters
The final question asked candidates to compare and contrast phishing and pharming, then give precautions against each.
The core distinction. Both are scams that end with you on a fake website designed to steal personal data — and that shared goal is what trips students up, because they sound similar. The difference is entirely in how you end up on the fake site:
| Phishing | Pharming | |
|---|---|---|
| Trigger | You receive a fake email or message and click a link | Malicious code redirects you automatically |
| User action needed? | Yes — you have to be tricked into clicking | No — it can happen even if you type the correct address |
| Where the attack sits | In the message sent to you | In code on your device or a DNS server |
| Shared outcome | Fake site → stolen data → fraud / identity theft | Fake site → stolen data → fraud / identity theft |
That middle row is the heart of a "compare and contrast" answer: a 6-mark question wants both similarities and differences, so state what they have in common and what separates them. A one-sided answer caps your marks no matter how detailed.
A frequent misconception is calling them "viruses." They're scams/attacks, not viruses — the mechanism is deception (and, for pharming, redirection), not self-replicating code.
Sensible precautions follow logically from how each one works:
- Against phishing, because it relies on you clicking: don't click links in unexpected emails, check the sender's address carefully, and use a spam/email filter.
- Against pharming, because it relies on malicious code and redirection: keep anti-malware software installed and updated, check the URL in the address bar before entering details, and stick to trusted, secure (HTTPS) sites.
✏️ Practice it: "A user receives an email from their 'bank' asking them to log in via a link. Explain whether this is phishing or pharming, and justify your answer."
Quick recap
- System testing links each element to the failure it prevents — and knowing normal, abnormal, extreme and boundary data sets you apart.
- Technical documentation is for developers; user documentation is for users — never swap the examples.
- ICT safety answers must be specific, realistic actions, and different from each other.
- Phishing needs a click; pharming redirects you automatically — but both end at a fake site, so a top answer gives similarities and differences.
