How do you prove a program works, and how do you judge whether it is any good?
Plan and carry out testing using normal, extreme and exceptional data and dry runs with trace tables, and evaluate software for fitness for purpose, robustness, efficiency and maintainability.
A focused answer to the SQA Advanced Higher Computing Science content on testing and evaluation, covering normal, extreme and exceptional test data, dry runs and trace tables, and evaluating software for fitness for purpose, robustness, efficiency and maintainability.
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 dot point is asking
The SQA wants you to plan systematic testing, choose the right categories of test data, trace code by hand with a trace table, and evaluate finished software against meaningful quality criteria. Testing proves the program meets its specification; evaluation judges how well it does so.
Categories of test data
Comprehensive testing covers three categories so that both correct handling and correct rejection are checked.
Test planning
A test plan is written from the specification, before or alongside coding, so testing is systematic rather than ad hoc. Each row states the test purpose, the input data, the expected result and (once run) the actual result, with a pass or fail. Comparing expected against actual is what reveals defects; a test with no predetermined expected result proves nothing.
Dry runs and trace tables
A dry run is a hand-execution of code: you read it line by line as the computer would, without running it, and record the value of each important variable in a trace table after each step. Because you see every intermediate value, a trace table pinpoints the exact line where a variable takes a wrong value, making it a powerful way to find logic errors that a black-box test only reveals as a wrong final output.
Evaluating software
Evaluation judges the finished product against quality criteria, going beyond "does it run".
- Fitness for purpose. Does it meet every requirement in the software specification and solve the user's actual problem?
- Robustness. Does it cope with unexpected or invalid input without crashing, for example by validating data and handling errors?
- Efficiency. Does it use processor time and memory sensibly, for example by choosing an appropriate algorithm and data structure?
- Maintainability. Is the code readable, modular, well commented and consistently named, so another developer can understand and change it?
Try this
Q1. State the category of test data for the value 0 on an input that validly accepts 0 to 50. [1 mark]
- Cue. Extreme (boundary) data: it is valid and sits on the lower limit.
Q2. Name the quality criterion concerned with how easily another developer can understand and change the code. [1 mark]
- Cue. Maintainability.
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.
AH style: test data3 marksA program accepts a percentage mark from 0 to 100. Give one example each of normal, extreme and exceptional test data.Show worked answer →
Normal: any value comfortably inside the valid range, for example 57 (1 mark). Extreme: a value at the boundary of the valid range, for example 0 or 100 (1 mark). Exceptional: a value that should be rejected, either out of range such as 150 or -5, or the wrong type such as the text "abc" (1 mark). Markers want one correct example in each of the three categories; boundary values must be the limits themselves, not just "a big number".
AH style: trace table4 marksExplain what a dry run with a trace table is and give two reasons a developer would use one.Show worked answer →
A dry run is stepping through code by hand, line by line, without executing it on a computer (1 mark); a trace table records the value of each key variable after each step so you can follow how they change (1 mark). Reason one: it locates a logic error by showing exactly where a variable takes an unexpected value (1 mark). Reason two: it lets you verify an algorithm before or instead of running it, useful when no working code or test environment is available yet (1 mark).
Related dot points
- Describe and compare iterative (agile) and structured (waterfall) development methodologies, and apply the analysis, design, implementation, testing, documentation, evaluation and maintenance stages of the software development process.
A focused answer to the SQA Advanced Higher Computing Science content on development methodologies, covering iterative agile and structured waterfall approaches and every stage of the software development process from analysis to maintenance.
- Describe and implement the standard searching and sorting algorithms (linear and binary search, bubble, insertion and quicksort), explain recursion, and compare algorithm efficiency.
A focused answer to the SQA Advanced Higher Computing Science content on standard algorithms, covering linear and binary search, bubble, insertion and quicksort, recursion, and comparing the efficiency of algorithms.
- Describe and implement object-oriented programming using classes, objects, instantiation, attributes and methods, encapsulation, inheritance, and polymorphism through method overriding.
A focused answer to the SQA Advanced Higher Computing Science content on object-oriented programming, covering classes and objects, instantiation, encapsulation, inheritance and polymorphism through method overriding, with UML class diagrams.
- Describe and implement the data structures used in Advanced Higher: one- and two-dimensional arrays, records, sequential files, linked lists, stacks and queues, including their operations.
A focused answer to the SQA Advanced Higher Computing Science content on data structures, covering one- and two-dimensional arrays, records, sequential files, linked lists, stacks and queues with their core operations.