Community
Community resources
Computer science Worksheets and Python Workspaces shared by Coding Pathway teachers. Worksheets cover exam board theory as well as programming. Read any of them in full here. Teachers can copy one into their own lessons and edit it before setting it to a class.
Planning a whole course or unit? Our mapped pages put the teaching sequence in order with the Worksheets that cover it: OCR GCSE Computer Science (J277), Pearson Edexcel GCSE Computer Science (1CP2), OCR A Level Computer Science (H446), Python Turtle for Key Stage 3.
- 438 resources
- 3 teachers sharing
- Creative Commons licensed
Testing and debugging
9 resources match. Newest first. Opening a resource shows the whole thing, with answers and marking held back.
H446 2.2.2 · Computational methods
Includes OCR H446 2.2.2 Writing backtracking algorithms
Reading a backtracking template is far easier than writing one that terminates and restores its state correctly. This H446 2.2.2 worksheet moves students from the template to their own subset-sum implementation, by way of a debugging task built around the classic missing undo after a failed recursive call. Students will: - define the state, the alternatives, the success test and the failure test for a backtracking problem - explain when a running total exceeding the target is a safe failure test - diagnose how a missing undo step corrupts a later route or the returned path - implement a subset-sum search that uses each value at most once and leaves the input list unchanged - explain why the order of the include and exclude routes changes running time but not the set of solutions reachable Inside: 7 explanation cells, 1 multiple-choice question, 1 fill-in-the-blanks cell, 2 written answers and 1 Python task. 22 marks, about 25 to 40 minutes. Series: H446 2.2.2 · Computational methods, part 5 of 14.
WorksheetSeries · 3 partsH446 2.2.1 · Programming techniques
Includes OCR H446 2.2.1 Tracing and debugging control flow
Faults that appear only at particular input sizes are the ones students find hardest to explain. Sitting in H446 2.2.1, this worksheet turns execution into visible state, so students trace combined control flow, name the observable effect of an off-by-one condition and prove a repair with boundary tests. Students will: - construct a trace of combined selection and iteration in execution order - recognise an off-by-one fault in a Python range and state what it causes - identify a faulty boundary condition, explain its effect and give a corrected version - repair a counting function so it terminates with the required result - write a fresh algorithm to a stated specification and justify the test values chosen Inside: 8 explanation cells, 1 multiple-choice question, 1 fill-in-the-blanks cell, 2 written answers, 3 Python tasks and 1 trace table. 19 marks, about 25 to 35 minutes. Series: H446 2.2.1 · Programming techniques, part 2 of 14.
WorksheetOCR H446 2.1.2 Program caching and reusable components
Part 2 · H446 2.1.2 · Thinking ahead
Caching and reusable components are the two thinking-ahead mechanisms named in OCR H446 2.1.2, and both fail when validity or the interface is left vague. Students trace hits and misses in a live-event app, judge a 24 hour cache policy against changing closures, and write a reusable duration formatter in Python. Students will: - trace a cache hit and a cache miss and say what is computed or stored in each - separate a program cache designed in application code from hardware processor cache - explain how a stale cached result arises and recommend a better policy - implement a small reusable function that honours a stated precondition - justify reusing a component and state one check to make before adopting it Inside: 8 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells, 2 written answers and 2 Python tasks. 23 marks, about 30 to 40 minutes. Series: H446 2.1.2 · Thinking ahead, part 2 of 2.
WorkspaceSeries · 2 parts1CP2-CT-6 · Turtle practical lessons
Includes 1CP2-CT-6.WS4 Compose a scene with subprograms and layers
The fourth practical lesson, composing a whole scene from subprograms drawn in a deliberate order. Students will: - decompose a scene into named subprograms - use parameters to place and size each object - choose a drawing order so layers appear correctly - test each subprogram before composing the scene - correct a scene whose layers were drawn in the wrong order A Workspace lesson: students write and run their own Python in the editor. About 60 minutes. Series: 1CP2-CT-6 · Turtle practical lessons, part 4 of 6.
WorksheetSeries · 2 parts1CP2-CT-9 · Testing, structures and integrated solutions
Includes 1CP2-CT-9.1 Designing test data and validating behaviour
A test case contains input data, an expected result and a reason. Choose expected results before running the program. Normal valid data checks typical behaviour; boundary data checks exact limits and values just around them; erroneous data violates a requirement and should be rejected. Students will: - derive normal, boundary and erroneous tests from requirements - state an expected result before running a program - test compound validation rules systematically - repair validation and rerun relevant tests Inside: 5 explanation cells, 1 fill-in-the-blanks cell, 3 multiple-choice questions, 2 written answers and 1 Python task. 17 marks, about 45 minutes. Series: 1CP2-CT-9 · Testing, structures and integrated solutions, part 1 of 4.
Worksheet1CP2-CT-10.4 Test trace debug and refine an integrated program
Part 4 · 1CP2-CT-10 · Integrated programming and data structures
Refinement is evidence-led. Translate requirements into expected behaviour and design tests. Trace a failure, locate its cause and amend the code. Then rerun both the failing test and earlier regression tests. Correctness, readability and efficiency are separate qualities. Students will: - turn requirements into expected test behaviour - trace an integrated program to locate a defect - amend code while preserving correct behaviour - rerun failing and regression tests after refinement Inside: 5 explanation cells, 1 fill-in-the-blanks cell, 4 written answers, 2 multiple-choice questions, 1 trace table and 1 Python task. 20 marks, about 45 minutes. Series: 1CP2-CT-10 · Integrated programming and data structures, part 4 of 5.
Worksheet1CP2-P-5.5 Robust software audit trails and code reviews
Part 5 · 1CP2-P-5 · Cyber security and robust software
The robust software worksheet, closing the loop from designing carefully to recording evidence and inspecting code. Students will: - recognise behaviour that is strong evidence of robustness - explain how a named weakness could be exploited and how to reduce it - use an audit trail as evidence, and state one of its limitations - compare human and automated code review - recommend improvements from the symptoms a system shows Inside: 8 explanation cells, 4 multiple-choice questions, 1 fill-in-the-blanks cell and 5 written answers. 20 marks, about 45 minutes. Series: 1CP2-P-5 · Cyber security and robust software, part 5 of 6.
Worksheet1CP2-CT-6.2 Planning composing and debugging Turtle programs
Part 2 · 1CP2-CT-6 · Turtle problem solving
The planning and debugging worksheet for the Turtle topic, preparing students for the practical checkpoint that follows it. Students will: - control outline, fill and circle drawing - compose a scene in layers, in a deliberate drawing order - use parameters to build related objects from one subprogram - debug from the visible symptom back to the cause - plan a drawing before constructing it The checkpoint itself stays in the Workspace, where a teacher can inspect both the program and the picture it made. Inside: 7 explanation cells, 3 multiple-choice questions, 1 fill-in-the-blanks cell and 6 written answers. 20 marks, about 45 minutes. Series: 1CP2-CT-6 · Turtle problem solving, part 2 of 2.
WorksheetSeries · 3 partsJ277 2.3 · Producing robust programs
Includes J277 2.3.2 Testing programs and identifying errors
What testing is for, how it differs from validation, and how to identify and refine the two types of error. Students will: - state the purposes of testing a program - distinguish iterative testing from final testing - separate testing from validation - tell a syntax error from a logic error - refine a program once a fault has been found Inside: 6 explanation cells, 1 runnable Python task, 2 multiple-choice questions, 1 fill-in-the-blanks cell and 3 written answers. 17 marks, about 45 minutes. Series: J277 2.3 · Producing robust programs, part 5 of 7.