How do you find errors in a program and judge whether it is any good?
Testing with normal, extreme and exceptional test data; syntax, execution and logic errors; debugging techniques; and evaluating software for fitness for purpose, efficiency, robustness and readability.
An SQA Higher Computing Science answer on testing and evaluation, covering normal, extreme and exceptional test data, the three error types, debugging techniques, and evaluating software for fitness for purpose, efficiency, robustness and readability.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this key area is asking
The SQA wants you to know how software is tested (with normal, extreme and exceptional data), the three kinds of error (syntax, execution, logic), the debugging techniques used to locate faults, and how to evaluate finished software against four criteria: fitness for purpose, efficiency, robustness and readability.
Why test, and with what data
Testing aims to find errors and to show the program meets its requirements. You cannot test every possible input, so you choose representative data in three categories.
The three error types
- Syntax error. The code breaks the rules of the language (a missing bracket, a misspelled keyword). The translator detects it and the program will not run until it is fixed.
- Execution (runtime) error. The program starts but stops during execution because of an impossible operation, such as dividing by zero or reading past the end of an array. There is no warning until the program is run.
- Logic error. The program runs to completion but gives the wrong result, because the algorithm or a calculation is wrong (using
+instead of*). There is no error message, so it is the hardest to find.
Debugging techniques
A dry run and trace table are especially useful for logic errors, because they reveal where the actual values diverge from what you expected. Breakpoints and watchpoints do the same inside a development environment without editing the code.
Evaluating the finished software
Readability matters because most software is maintained by someone other than its author: clear names, internal comments, sensible indentation and well-chosen sub-programs make later changes safe and quick.
Examples in context
Professional teams test continuously: developers write automated tests that re-run normal, extreme and exceptional cases on every change, and code is reviewed for readability before being merged. Famous failures show the cost of poor testing - the Ariane 5 rocket was lost in 1996 to an unhandled numeric overflow (an execution error never tested for). In the SQA assignment you must supply a test plan with expected and actual results and an evaluation against the specification, so this key area is examined in both the question paper and the coursework.
Try this
Q1. State the category of test data used for values at the boundaries of the valid range. [1 mark]
- Cue. Extreme data.
Q2. State which error type lets a program run but produces the wrong output. [1 mark]
- Cue. A logic error.
Q3. Name two criteria used to evaluate finished software. [2 marks]
- Cue. Any two of: fitness for purpose, efficiency, robustness, readability.
Exam-style practice questions
Practice questions written in the style of SQA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
SQA Higher (style)4 marksA program accepts an exam mark from 0 to 100. State suitable normal, extreme and exceptional test data, and explain the purpose of each category.Show worked answer →
Normal data: a typical valid value within range, for example 57. Purpose: to check the program works correctly for ordinary inputs.
Extreme data: values at the boundaries of the valid range, for example 0 and 100. Purpose: to check the program handles the limits correctly (a common place for off-by-one errors).
Exceptional data: values that should be rejected, for example -5, 150, or the text "abc". Purpose: to check the program copes with invalid input without crashing (its robustness).
Markers reward a correct example in each category (normal within range, extreme at the boundaries, exceptional invalid) and the correct purpose of each.
SQA Higher (style)3 marksExplain the difference between a syntax error and a logic error, and state why a logic error is often harder to find.Show worked answer →
A syntax error breaks the rules of the programming language (for example a misspelled keyword or a missing bracket). The translator detects it and the program will not run until it is fixed.
A logic error means the program runs but produces the wrong result, because the algorithm or a calculation is incorrect (for example using + where * was meant).
A logic error is harder to find because there is no error message: the program runs to completion, so the developer must compare the actual output with the expected output and trace the logic to locate the fault, often using a dry run or trace table.
Markers reward syntax = breaks language rules (caught by the translator) versus logic = runs but wrong output, and the reason a logic error is harder (no error message, must trace the logic).
Related dot points
- Standard algorithms: input validation, running total within a loop, traversing a 1-D array, linear search, counting occurrences, and finding the minimum or maximum.
An SQA Higher Computing Science answer on the standard algorithms, covering input validation, running totals, traversing a 1-D array, linear search, counting occurrences, and finding the minimum or maximum value.
- Computational constructs: assignment and arithmetic, selection with logical operators, fixed and conditional iteration, pre-defined functions, and sub-programs with parameter passing (by value and by reference) and variable scope.
An SQA Higher Computing Science answer on computational constructs, covering assignment and arithmetic, selection with logical operators, fixed and conditional loops, pre-defined functions, sub-programs, parameter passing by value and by reference, and local and global scope.
- The iterative software development process (analysis, design, implementation, testing, documentation and evaluation) and the difference between the traditional waterfall approach and agile methodologies.
An SQA Higher Computing Science answer on the software development process, covering the seven iterative stages from analysis to maintenance, and the difference between the traditional waterfall model and agile methodologies.
- The analysis stage: identifying the purpose, scope, boundaries and functional requirements of a problem to produce a requirements specification.
An SQA Higher Computing Science answer on the analysis stage of software development, covering the purpose, scope, boundaries and functional requirements that make up a clear software specification.
- Design notations used to describe a solution: structure diagrams, flowcharts and pseudocode, and the design of the user interface (wireframes).
An SQA Higher Computing Science answer on design notations, covering structure diagrams, flowcharts and pseudocode for program logic, and wireframes for user-interface design.