Loading...
Testing and evaluation should form a traceable argument about the completed outcome. Select representative evidence, relate it to requirements and discuss genuine limitations.
What you'll be able to do
Choose normal, boundary and erroneous cases from the requirements and data rules. Include core algorithms, validation and the integration between components. A collection of successful login screenshots does not demonstrate that an unrelated calculation or concurrency rule is correct.
Record the purpose, input, expected outcome and actual outcome with carefully selected evidence. The specification emphasises representative samples rather than every possible screenshot. When a fault is repaired, explain the cause and retest the affected behaviour and relevant dependencies.
Assess each appropriate objective against the working result. Obtain useful independent feedback and discuss its meaning, including critical comments. A positive user opinion and a passed numerical test are different kinds of evidence; neither should be substituted for the other without explanation.
Acknowledge incomplete or limited behaviour rather than evaluating only the successful features. If feedback was obtained during prototyping, explain where it influenced a decision and reference the evidence. Keep factual observations separate from claims about how well the system would perform under untested conditions.
A useful improvement identifies a demonstrated limitation, proposes a feasible change and explains the expected benefit and trade-off. “Add more features” is too vague without showing why those features matter. Wider testing may also be an improvement when the current evidence has a restricted scope.
Prepare the final submission according to current centre instructions, preserving required source acknowledgements and a clear route through the evidence. Do not invent feedback, measurements or test results to complete a table. The assessment concerns the actual independent outcome, and honest limitations help a reviewer understand its practical boundaries.
| Requirement reference | Test purpose | Evidence to retain |
|---|---|---|
| R1 valid booking | Normal complete request | Input and resulting confirmation |
| R2 no overlap | Boundary and conflicting times | Accepted/rejected outcomes |
| R3 report totals | Known small dataset | Independently calculated expected total |
| R4 invalid input | Malformed value | Controlled error response |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.