Testing — OCR GCSE Computer Science
Teaching note checked against the official specification.
Test yourself on Testing with OCR GCSE practice questions.
A week of Premium from your first lesson · Then the free plan continues · No card, no charge
Testing explained
Testing covers 5 specification points, including The purpose of testing and Types of testing Iterative Final/terminal.
Read the full explanation
Open a point below for its explanation and revision guidance.
The purpose of testing
Testing is a vital part of software development designed to ensure a program functions as intended and meets its original requirements. Its primary purpose is to uncover logic errors and defects before the software is released to users. Testing also verifies that a program is robust, meaning it can handle unexpected actions without crashing. Two main approaches exist: iterative testing occurs during development to check individual modules, while terminal testing evaluates the finished program. For example, testing a calculator app ensures it adds correctly (functionality) and does not crash when dividing by zero (robustness). Exhaustive testing is usually impossible, so testing aims to build confidence in the software's reliability.
Types of testing Iterative Final/terminal
Testing is not a single event but a process carried out at different points in development. Iterative testing happens repeatedly as each module or feature is written: the programmer runs the code, checks outputs against expected results, fixes defects and runs it again. This tight loop catches errors early, when they are cheap to fix, and supports incremental development. Final or terminal testing happens once the whole program is complete and integrated. It checks the system as a whole against the original requirements, including normal, boundary and erroneous data, and confirms that earlier fixes have not broken other parts. For example, a quiz program might be tested question by question during coding, then tested end-to-end with a full set of answers before release.
Identify syntax and logic errors
A syntax error breaks the rules of the programming language, so the code cannot be translated or run. Examples include a missing closing bracket in print("Hello", a misspelled keyword such as whille, or using a reserved word as a variable name. Translators usually report syntax errors with a line number, which helps you locate them. A logic error is grammatically valid code that produces the wrong result. For example, average = total / count + 1 adds one incorrectly, or a condition uses > when >= is needed at a boundary. Logic errors are harder to find because the program runs. You identify them by comparing actual output with expected output using test data, tracing variables, and checking boundary values.
Selecting and using suitable test data Normal Boundary Invalid/Erroneous
Testing requires carefully chosen data to verify program behaviour. Normal data is typical, valid input that should be accepted, such as entering 25 for an age field accepting 18 to 65. Boundary data sits exactly on the limits of valid input, such as 18 and 65, because logic errors frequently occur at these edges. Invalid or erroneous data is input that should be rejected, such as 17, 66, or 'abc' for the same age field. To select suitable test data, identify the valid range, choose normal values, boundary values at each limit, and invalid values that break the rule. Using this data involves running the program, comparing the actual output with the expected output, and recording whether the test passes or fails in a structured test plan.
Refining algorithms
Testing and refining algorithms are distinct but related processes. Testing evaluates a program to find errors, using iterative testing during development or final testing at the end. A test plan uses normal, boundary, invalid, and erroneous data. Refining an algorithm improves its design, such as fixing errors, handling unexpected inputs robustly, or increasing efficiency. For example, if an algorithm crashes on negative numbers, refinement adds input validation. Trace tables support dry runs to track variable changes and locate logic errors (which produce incorrect results). Syntax errors break language rules and are found by translators. Effective refinement requires identifying the specific weakness and applying a targeted fix.
Your focus
- State the primary purposes of testing in the software development process.
- Explain how testing ensures a program is robust and meets its requirements.
- Distinguish between iterative testing and terminal testing.
Show all 16 objectives
- Describe when iterative testing takes place during program development and why it is repeated.
- Explain the purpose and scope of final or terminal testing on a completed program.
- Distinguish between iterative and final testing using an example of test data and expected output.
- Identify syntax errors in given code and state how they prevent successful translation or execution.
- Identify logic errors by comparing actual output with expected output for supplied test data.
- Explain how a programmer can locate and correct each type of error during testing.
- Identify the valid range or rule in a given scenario and classify test data as normal, boundary or invalid/erroneous.
- Select suitable test data that includes normal values, boundary values at limits, and invalid values.
- Use selected test data by running a program, comparing actual output with expected output, and recording outcomes.
- Identify logic errors in a given algorithm using dry runs and trace tables, and identify syntax errors by inspection or compiler feedback.
- Suggest and apply targeted fixes to refine an algorithm's logic, efficiency, or robustness.
- Explain the difference between syntax and logic errors in the context of algorithm refinement.
- Describe how a test plan uses normal, boundary, invalid and erroneous data, and distinguish iterative from final/terminal testing.
Testing exam tips
Marking Points
- States that testing aims to find logic errors and defects before a program is released to users.
- Explains that testing confirms the software meets its original requirements and functions as intended.
- Describes how testing ensures robustness by verifying the program can handle unexpected actions without crashing.
- Distinguishes between iterative testing (during development) and terminal testing (at the end of development).
- Explains that exhaustive testing is usually impossible, so testing builds confidence and reduces risk rather than proving a program is completely bug-free.
- Iterative testing is repeated throughout development, typically after each small change or module is written.
- Iterative testing supports early detection and correction of defects, reducing the cost and risk of later failures.
- Final or terminal testing is carried out on the completed, integrated program rather than on isolated parts.
- Final testing checks the whole system against the original requirements and user needs.
- Both types use test data such as normal, boundary and erroneous values, and compare actual output with expected output.
- Regression checking after a fix is part of iterative testing because a change can introduce new faults elsewhere.
- A syntax error breaks the grammar or rules of the language, so the program cannot be translated or executed.
- Typical syntax errors include missing brackets or quotation marks, misspelled keywords and incorrect punctuation.
- A logic error is valid code that runs but produces an incorrect or unexpected result.
- Logic errors are found by comparing actual output with expected output, often using normal, boundary and erroneous test data.
- Tracing values, using breakpoints or adding temporary output statements can help locate logic errors.
- Translators often flag syntax errors with a line number, whereas logic errors usually require the programmer to reason about the algorithm.
- Normal data is valid, typical input that lies well inside the accepted range and should produce the expected result.
- Boundary data is input at the exact limits of a valid range, used because logic errors frequently occur at these edges.
- Invalid or erroneous data is input that does not meet the stated rule and should be rejected by the program.
- Using test data involves running the program, comparing actual output with expected output, and recording the outcome.
- Refining an algorithm involves identifying weaknesses, such as logic errors or inefficiencies, and applying targeted fixes.
- Trace tables are used to dry-run algorithms, tracking variable values to pinpoint exactly where logic errors occur.
- Distinguishes logic errors, which produce incorrect results and are found by dry runs, from syntax errors, which break language rules.
- Refinements often include adding input validation, correcting loop conditions, or removing redundant instructions to improve efficiency.
- A suggested fix must directly address the identified error without altering the correct functionality of the original algorithm.
- Testing uses a test plan with normal, boundary, invalid and erroneous data, and distinguishes iterative testing from final/terminal testing.
Examiner Tips
- 💡If a question asks why testing is important, refer to finding defects, meeting requirements and ensuring robustness rather than just writing 'to make sure it works'.
- 💡Be prepared to define and distinguish between iterative testing and terminal testing in exam scenarios.
- 💡Link each type of testing to a stage of the development cycle so your answer shows when and why it happens.
- 💡Use a short scenario, such as testing one function then testing the whole program, to make the distinction concrete.
- 💡When asked to compare, give one point about timing and one about scope for each type rather than listing definitions only.
- 💡Classify the error first: ask whether the program would run at all, then decide syntax or logic.
- 💡Quote the exact faulty line or expression and state the correction rather than describing the error vaguely.
- 💡For logic errors, state the test data used, the expected output and the actual output to justify your identification.
- 💡For each rule, give one normal value, the boundary values at each end, and at least one clearly invalid value.
- 💡State the expected result for each value so the examiner can see why the data is suitable.
- 💡When asked to refine an algorithm, identify the specific line or construct containing the error and write out the corrected code; if the question provides line numbers, refer to them.
- 💡Use a trace table to systematically track variables during a dry run; this is the most reliable way to find hidden logic errors.
- 💡Do not use a trace table to look for syntax errors; check the code against the language rules instead.
- 💡When a question asks about testing, refer to a test plan and give examples of normal, boundary, invalid and erroneous test data.
Common Mistakes
- Confusing testing with debugging; correction: testing finds and reports a defect, while debugging is the process of locating and correcting the cause.
- Assuming testing can prove a program is completely bug-free; correction: exhaustive testing is usually impossible, so testing only builds confidence and reduces risk.
- Believing testing only happens at the end of development; correction: iterative testing occurs throughout the development process to catch errors early.
- Treating iterative and final testing as the same activity: iterative testing is repeated during development, while final testing occurs once the whole program is complete.
- Assuming final testing only means running the program once: it should cover the full range of expected and unexpected inputs and the original requirements.
- Believing that finding no errors in final testing proves the program is perfect: testing can only show the presence of errors, not their absence.
- Calling a wrong calculation a syntax error: if the code runs but gives the wrong answer, it is a logic error.
- Assuming the line number reported for a syntax error is always the exact faulty line: the real cause may be on an earlier line, such as an unclosed bracket.
- Thinking logic errors are found automatically by the translator: they normally require testing and comparison with expected results.
- Choosing only normal data and ignoring boundaries and invalid values; correction: include at least one normal value, boundary values at each limit, and invalid values.
- Treating a boundary value as invalid when it is actually allowed; correction: check the wording of the requirement, for example '18 to 65 inclusive' means 18 and 65 are valid boundary values.
- Recording only the input without the expected output; correction: write both the input and the expected result so the test can be judged objectively.
- Confusing syntax and logic errors; correction: remember syntax errors break language rules (e.g. missing quotes), while logic errors produce incorrect outputs.
- Claiming a trace table finds syntax errors; correction: trace tables track variable values to expose logic errors, while syntax errors are found by inspection or the compiler.
- Rewriting the entire algorithm instead of refining it; correction: identify the specific weakness and change only the relevant lines of code.
- Failing to update variable values correctly in a trace table; correction: carefully follow the algorithm step-by-step, updating the table only when a variable's value explicitly changes.
- Confusing iterative testing with final/terminal testing; correction: iterative testing is repeated during development, while final/terminal testing is carried out at the end against the full requirements.