Put it all together. Read a full scenario, plan it, and write a complete answer — then check it against the requirements and the things a good answer shows. Six scenarios, four modes, and your code is run on test data.
Everything from the Read Lab and the Build Lab comes together here. The scenario question at the end of Paper 2 is worth 15 marks — about a fifth of the paper. With 75 marks in 1 hour 45 minutes, plan on about 20–25 minutes for it.
You can answer in pseudocode or in program code (Python, Java or Visual Basic). The Scenario Bench on this page reads pseudocode.
In our own words — the kinds of thing the mark scheme looks for:
| Term | Meaning |
|---|---|
| Full answer | A complete program that meets every requirement in a scenario |
| Requirement coverage | How many of the listed requirements your program actually does |
| Techniques | Selection, iteration, counting, totalling, input and output |
| Method 1 — IPO table | Read → Inputs / Processes / Outputs → code |
| Method 2 — walk-through | Try the program with sample data, note each step, then turn the steps into code |
| Test data | Example values used to check a program does what it should — the Scenario Bench uses it to check your code |
Best for scenarios that take data, work on it and output results — most scenarios. Build the IPO table, then turn each row into code.
Best for menu-driven scenarios, where the program repeats and branches on the user's choice. Walk through each choice with sample data ("the user picks 1, so…"), note the steps, then turn them into code.
These timings are a guide, not a rule — they add up to a fair share of the paper for 15 marks.
Cover every requirement in a simple form first, then improve. A short attempt at each requirement, with comments and messages, is better than a perfect answer to some of them.
For every "output the name(s)…" requirement, ask: could more than one item match? If so, find the value first, then output every item that matches. A Cambridge examiner report (2025) noted that only a few candidates output the names of all the competitors with the highest score.
Paper 2 style · TeamName[] (1D) and TeamPoints[] (2D) · four requirements.
Paper 2 style · StudentName[] (1D) and ScreenTime[] (2D).
Paper 2 style · Video[] (2D: title, format), Results[] and Count · menu with Add, Search and End.
WHILE Choice <> 3 DO … ENDWHILE, with the menu choice validated inside it.Video[Count, 1] and Video[Count, 2].Starting to code straight away is how requirements get missed. Read twice, plan (IPO table or walk-through), then code.
If time runs out, they get left out — and both are expected in a good answer.
Twenty minutes on a perfect validation loop leaves the last requirement with no code.
In our own words — the kinds of thing the mark scheme looks for.
Head to Activities. Start with Walk-through for the menu-driven video library, then try Guided on another scenario. Timed and Exam modes unlock as you complete scenarios.
Same logic, different notation. Either can be used in the exam; this page's checker reads pseudocode.
| Pseudocode | Python |
|---|---|
INPUT Name | name = input() |
OUTPUT "Hi ", Name | print("Hi", name) |
Total ← 0 | total = 0 |
FOR i ← 1 TO 10 | for i in range(1, 11): |
IF X = 5 THEN | if x == 5: |
WHILE X <> 0 DO | while x != 0: |
11.1–11.2 Read Lab
11.3 Build Lab
📍 11.4 Ship Lab (this page)
Topic 11 is this site's practice for the 15-mark scenario question at the end of Paper 2. It draws on syllabus Topic 7 (algorithm design and problem-solving) and Topic 8 (programming).
The scenario question is worth 15 of the 75 marks on Paper 2 — the biggest single question. Answering it well is about covering every requirement clearly, not about clever code.
A collector stores video details in Video[] (title and format) and uses Results[] for search matches. The program shows a menu: Add, Search, End. Because it repeats and branches on the user's choice, a walk-through with sample data plans it better than an IPO table alone.
Total ← 0 FOR Index ← 1 TO 10 Total ← Total + Scores[Index] NEXT Index OUTPUT "Total: ", Total
Correct code, but the reader has to work out what each part is for.
// add up the 10 scores Total ← 0 FOR Index ← 1 TO 10 Total ← Total + Scores[Index] NEXT Index // show the total with a label OUTPUT "Total: ", Total
Each part says what it is for. Comments are expected in a scenario answer.
Best for: take data → work on it → output results.
Inputs | Processes | Outputs
scores | total, count | total
| average | averageTurn each row into code. Suits most scenarios.
Best for: menus and repeated choices.
User picks 1 → input title, format → store User picks 2 → input title → search → output User picks 3 → end the loop
Turn each walked step into code.
Tap the thing each piece of code shows. This trains you to check your own answer.
| Habit | In pseudocode | What it shows |
|---|---|---|
| Initialise before adding | Total ← 0 before the loop | Totalling and counting done correctly |
| Validate with a loop | REPEAT … UNTIL or WHILE … DO | The validation requirement |
| A second pass for every match | Find the value, then loop again | The "name(s)" requirement |
| Message every input and output | OUTPUT "Enter the score: " | Messages |
| Comment every part | // find the lowest total | Comments |
| Use the given names | TeamName[], not Teams[] | Data structures as given |
Outputting only the first student with the lowest total when two share it.
The scenario says TeamPoints[]; the answer uses Points[].
One requirement is polished while another has no code.
Comments are left until the end — and the time runs out.
INPUT Score with no prompt; outputs with no label.
An IF only asks again once, so a second wrong value gets through.
REPEAT … UNTIL Score >= 0 AND Score <= 100.Six scenarios, four modes, and your code is run on test data.
Pick a mode and a scenario, write your pseudocode, then press Check my answer. Your whole program is run on test data for each requirement, and checked for the things a good answer shows. This is practice feedback, not an exam mark.
Quick recall on full answers and exam technique. Sprint is for speed — it doesn't change your Mastery.
A scenario counts as completed when the data structures and every requirement pass, without a model answer being shown first.
Data structures, techniques, requirements, messages and comments, and exam technique. Skills you get wrong come back more often. Missed questions are saved to Mistakes.
Paper 2 style questions on full answers. Answer every part, then press Mark my answer. Code answers are run on test data, so any correct version earns the marks. For full scenarios, use the Scenario Bench.
Written in the style of Cambridge Paper 2; the scenarios are made up for practice. Use the names given in each question. Both ← and <- work, and MOD, DIV, LENGTH and CASE are understood.
Read these before your exam. Then look at Mistakes to see the ones you make.
Six one-liners to recite before your exam.
Tick each item as you master it. In the skill grid, tap a status chip to set it yourself. When all 12 are ticked, the Module Mastered banner appears.
Mastered = 3+ attempts and at least 70% accuracy. Tap the status chip to override it.
That's the last topic in the Learning Hub. Head back to the Learning Hub to revise your weakest topics — or start again from Topic 1.
11.1–11.2 Read Lab
11.3 Build Lab
📍 11.4 Ship Lab (this page)
Every wrong Practice, Exam or Scenario Bench answer is saved here automatically.
Your attempts, accuracy and mastery counts in the Ship Lab.
Bookmark an exam question to save it here.
Jot notes as you learn. Everything here is saved on this device only.
Sent mistakes and saved key facts, in one place.