Design and apply testing strategies, including test data and test cases, to verify a prototype against its requirements, and evaluate the solution using justified criteria

What this dot point is asking

Building a prototype is not enough; QCAA wants you to prove it works and judge how well. Testing verifies that the solution meets its requirements, using planned test cases and test data. Evaluation then makes a justified judgement about the solution's quality against criteria such as reliability, security, usability and fitness for purpose. Testing and evaluation are distinct, both are assessed in IA3, and confusing them is a common way to lose marks.

Test cases and test data

A test case is a planned check: a description, the input, the expected result and the actual result. Test data should be chosen deliberately to cover three categories:

• Normal (valid) data: typical values that should be accepted (a mark of 72).
• Boundary data: values at the edge of the valid range, where off-by-one errors hide (0 and 100 for a 0-to-100 mark, plus 1 and 101 just outside).
• Abnormal (invalid) data: values that must be rejected (a mark of 250, a letter, an empty field).

Testing only with normal data is the classic weakness; boundary and abnormal data are where defects appear.

Types of testing

QCAA expects awareness of several testing levels and kinds:

• Unit testing: checking an individual function or component in isolation.
• Integration testing: checking that components work together, critical for a data exchange where two systems interact.
• System testing: checking the whole solution against requirements.
• Acceptance testing: checking the solution meets the user's needs, often with the user.

For a data exchange prototype, also test the failure paths: a malformed payload, a dropped connection, an unauthorised request. These prove the exchange handles errors reliably, which is a key requirement.

Testing a data exchange specifically

Beyond ordinary input testing, a data exchange prototype needs tests that exercise the exchange itself: send a valid payload and confirm it is received and stored, send an invalid payload and confirm it is rejected with the right status, tamper with data and confirm the integrity check catches it, and simulate a failed transmission and confirm the retry or error handling fires. Each maps to a security or reliability requirement.

Evaluation against criteria

Evaluation is a judgement, not a list of test results. You assess the solution against criteria drawn from the requirements:

• Functionality: does it do what was specified?
• Reliability: does the exchange succeed consistently and handle failure gracefully?
• Security: are confidentiality, authentication and integrity actually achieved?
• Usability: can the intended users operate it?
• Fitness for purpose: does it solve the original problem?

A strong evaluation cites test evidence, acknowledges limitations, and recommends improvements. It explains why the solution does or does not meet each criterion, rather than just asserting it.

Testing versus evaluation

The distinction is examinable. Testing is the process of checking behaviour against expected results, producing evidence (pass or fail). Evaluation is the reasoned judgement built on that evidence about overall quality and fitness for purpose. Testing answers does it work; evaluation answers how well does it solve the problem and what would improve it.

How this appears in assessment

IA3 requires both a test plan with results and an evaluation against criteria, supported by that evidence. The external exam can ask you to design test data for a scenario, identify a missing test category, or evaluate a described solution against a criterion. Practise writing test tables that include boundary and abnormal data and evaluations that quote evidence and recommend specific improvements.