Cover lesson · Computer Science · Year 11 · Advanced
DCF: Producing → Evaluating and improving digital content
Name: Class: Date:
What this practises: GCSE Computer Science Unit 2: Computer Programming, Section 2.4.1 Testing and Section 2.4.2 Refinement and evaluation: designing test data with typical, extreme and erroneous examples, implementing a test plan, presenting test outcomes with commentaries, and refining code in response to testing and to a change in the requirements. It also uses Section 2.2.1 validation routines. Unit 2 is an on-screen examination. The pool and the program are invented: this is practice only, not the class’s pre-release brief.
Print: this sheet, one per pupil, and the stimulus sheet “Pwll Glan-y-Dŵr: the swimming lesson booking program”, one per pupil if you can, because pupils will keep looking back at the code. No computers are needed: pupils run the program in their heads.
Run: 8 min read the brief and the code · 12 min Step 2, design the test plan · 12 min Step 3, run the tests by hand · 10 min Step 4, find and fix the faults · 10 min Step 5, commentary and the changed requirement · 3 min pupils tick the success criteria. Total 55 minutes.
Collect: this sheet. Pupils should work alone for Steps 2 to 4, because the exam is individual. The worked example has the complete test plan and the corrected code.
A developer says the pool’s booking program “works fine”. Your job is to prove whether it does. You will plan tests before looking for bugs, run every test by tracing the code by hand, fix each fault you find, explain your results to the pool manager, then change the program for a new requirement. This is exactly what Unit 2 asks you to do on screen.
Read sections 1 and 2 of the stimulus sheet. Underline the numbers in R2, R3 and R4: every edge you underline needs a test. Do not hunt for bugs yet.
Fill in the first four columns for at least 12 tests. Include typical, extreme and erroneous data for both the age and the number of lessons, and test the discount rule on both sides of 6. When you test lessons, use a valid age (9). Write the expected result from the requirements, not from the code. Leave the last two columns for Step 3.
| No. | Input tested | Data | Type | Expected result | Actual result | Pass or fail |
|---|---|---|---|---|---|---|
| 1 | Age | 9 (lessons 3) | Typical | Booked: JON9, total £19.50 | ||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 | ||||||
| 7 | ||||||
| 8 | ||||||
| 9 | ||||||
| 10 | ||||||
| 11 | ||||||
| 12 | ||||||
| 13 | ||||||
| 14 |
For every test, follow the code line by line with your data, exactly as Python would, not as the developer meant it. Write the actual output in the table above. If the program crashes, write “crash”, the error and the line number. Then mark each test pass or fail.
Every failed test points to a fault. Some faults cause more than one failure. Fill in one row per fault, not per test.
| Tests that failed | Line(s) | What is wrong, and which requirement it breaks | Corrected code |
|---|---|---|---|
(a) Write a commentary of about 100 words for Siw, the pool manager. Say how many tests passed, which faults you found, why the developer’s own testing missed them, and what should happen next before the program is used at the desk.
(b) Changed requirement: from September, children aged 4 to 7 pay £5.00 a lesson. Everyone else still pays £6.50, and the 10% discount for 6 or more lessons still applies to everyone. Rewrite block_price so it takes the age as well as the number of lessons, and includes your fix from Step 4.
(c) Add three new tests for the changed requirement, with the expected result for each. At least one must be on the edge between the two prices.
| Age | Lessons | Type | Expected result |
|---|---|---|---|