Loading…
Free A-Level Computer Science guide
Development evidence explains how the solution changed and why. A useful record connects a requirement, an implementation decision, a test result and the response to that result.
Content owner: Michael Print · Written for A-Level learners · Checked against official specifications
Build a small, meaningful part of the solution, test it against its intended behaviour and use the result to choose the next change. Preserve failures and explain remedial work; a finished-product screenshot alone cannot show iterative development.
These are fictional teaching exercises. Your assessed project must be your own work. Follow your centre's supervision and authentication rules and OCR section 4e: permitted AI assistance must be acknowledged and its effect made clear; copied output cannot establish your own knowledge, understanding or ability.
OCR H446 · 3.3.1–3.3.2
Useful foundations
By the end, you should be able to
An iteration should deliver a coherent capability such as checking intervals, saving accepted bookings or searching reloaded records. State which requirement it advances and how completion will be demonstrated. Avoid splitting work into arbitrary 'coding day 1' and 'coding day 2' entries.
Start with the difficult or uncertain logic early enough to change the design. A simple interface can expose the conflict-check contract before the final presentation is polished. Record a design change when new evidence makes the original approach unsuitable.
Use focused annotated code or other appropriate evidence to explain a decision. Describe why a loop, data structure or validation rule meets a requirement and how components interact. Comments that merely repeat 'this line adds one' reveal little understanding.
Maintain clear names and reusable components, and handle errors deliberately. For a local file operation, decide what the user sees when the file is absent or malformed. A catch-all that silently loads an empty dataset might hide data loss rather than solve the problem.
A failed result is useful evidence when followed by an explanation, correction and retest. Derive the expected result from the requirement; do not rewrite it to agree with a bug.
Evidence must be readable and tied to the test. A console log without inputs or a cropped screenshot without context can be ambiguous. Capture what is needed to verify the behaviour, using fictional or permitted data and avoiding unnecessary personal information.
Inputs and setup
Record exactly what was supplied and how the test ran.
Expected result
State the outcome required by the specification.
Actual result
Record what the identified version really did.
Status and evidence
Compare expected with actual, state pass/fail and attach readable evidence tied to that test/version.
A retest repeats the case that exposed the failure after a change. Regression tests check that previously working behaviour still works. If changing the overlap comparison fixes adjacency, also rerun contained and partial overlaps so the correction does not introduce a new gap.
Tests at several levels answer different questions: a unit check isolates the interval rule; an integration check exercises saving and loading; a user task checks whether the interface supports the workflow. Passing one does not prove all the others.
| Test | Expected | Observed | Response |
|---|---|---|---|
| B4: 11:00 start after 10:00–11:00 | Accept adjacent booking | Rejected in iteration 2 | Replace inclusive endpoint comparison with stated strict-overlap rule |
| B4 retest, iteration 3 | Accept | Accepted | Attach input/output evidence |
| B1 contained overlap, iteration 3 | Reject | Rejected | Regression case still passes |
End each iteration with its result and the next decision. The record might show that core checks pass but save/reload is untested, so persistence is next. If user feedback changes a requirement, identify that change and its effect on the design and test plan.
Source control can support the history, but commit counts alone are not a development explanation.
Worked example
Failure: B4
The policy allows adjacency, but iteration 2 rejects 11:00–12:00 after 10:00–11:00.
Cause: inclusive comparison
<= incorrectly counts a shared endpoint as overlap.
Correction and retest
Use the designed < comparisons and rerun B4 on the changed version.
Regression evidence
Also record contained, identical, partial-overlap and different-room outcomes before moving to save/reload integration.
4 original questions total 14 marks. Attempt each before opening the independently written indicative marking guidance.
List four details needed to make a development test reproducible and assessable. [4]
Indicative answer
A change fixes adjacent booking rejection. Explain why retesting only that case is insufficient. [3]
Indicative answer
Explain two reasons why hiding failed tests weakens a development record. [4]
Indicative answer
Distinguish a unit check of conflict logic from a save/reload integration check. [3]
Indicative answer
This guide addresses OCR H446 3.3.1–3.3.2. Check your examination year and the complete specification for the assessment scope.
These are independently written explanations and practice questions. CompSciTutoring.co.uk is not affiliated with or endorsed by an examination board. The marking guidance is indicative; always check the syllabus for your examination year.
Found an error? Email a correction.
Use the free examples first, then explore one-to-one tuition if guided practice would help.