R097 Task 3 Guide: Testing and Reviewing the Product
What Task 3 asks you to do
Task 3 assesses Topic Area 3: testing the product you built and reviewing it against the brief. Work from your current assignment and its marking grid.
| Part | What you produce |
|---|---|
| Test the product | A test plan carried out, with expected and actual results, failures, fixes and retests |
| Test with users | Real users from the audience attempting tasks, with what they did and said recorded |
| Review against the brief | Each requirement judged, with evidence from the tests and the feedback |
| Strengths and weaknesses | An honest account, with reasons |
| Improvements and further development | Specific changes, how they would be made and their effect, and how the product could grow |
Testing, step by step
- Use your test plan, with the expected result written before each test is run.
- Test every function and route: each button, link, hotspot, form and media control, and every screen reachable with a route back.
- Test the content: spelling, accuracy, and everything the brief asked for being present.
- Test compatibility and accessibility: the target device, other screen sizes, keyboard only, contrast, captions.
- Run usability tests: give users from the audience a task, watch without helping, and record what they do and say.
- Record failures honestly, fix them, and retest.
Reviewing, step by step
- Quote each requirement from the brief.
- Give the evidence: the test result, the user's time, the quote.
- Judge it: met, partly met or not met, and why.
- Propose an improvement: what you would change, how, and what effect it would have.
- Suggest further development: where the product could go beyond the brief.
- Reflect on your process: what you would plan differently next time.
"It worked well" is an opinion. Evidence is a test result, a time, a number of users, a quotation. Every judgement in the review needs one.
Before you hand in
- Every planned test is carried out, with expected results written first
- Failures are recorded with their fixes and retests
- Real users from the audience tested real tasks, and you recorded what they did and said
- Every requirement in the brief is judged, with evidence
- Strengths and weaknesses are honest and explained
- Improvements say what, how and with what effect, and further development is suggested
- The review is your own analysis, in your own words
Sources and further reading
- OCR Cambridge Nationals in Creative iMedia (J834): the qualification page, with the specification and the assessment materials your teacher works from.
- The J834 specification (PDF): the content of every topic area. Check that your version matches.
- Moderators' report, summer 2024 (PDF) and summer 2023 (PDF): what moderators saw in real R094 and R097 work, including where marks were most often lost.
- Nielsen Norman Group: why you only need to test with 5 users: how many testers you need, and why.
- W3C: easy checks for accessibility: quick accessibility tests to include in your plan.
Key terms you must be able to define
- Usability test
- Watching a user from the audience attempt a task, and recording what they do and say.
- Retest
- Running a failed test again after a fix, to confirm the fix worked.
- Review
- A judgement of the product against the brief, backed by evidence.
- Further development
- How a product could be extended beyond the brief.
Flashcards
Reach the top grade on this topic
- Test against your plan, with expected results first and failures recorded
- Test with real users from the audience, and record actions as well as opinions
- Judge every requirement with evidence
- Make improvements specific, and suggest further development
Mistakes that cost marks here
- Testing your own product and calling it user testing.
- Recording only the tests that passed.
- Feedback from friends, with no tasks set.
- A review that praises everything.
- Improvements with no method or effect.
Testers often say a product is easy to use and then fail the task in front of you. That is why good usability testing records what people do, not just what they say.
Knowledge check
Check you could explain this
- LReal users from the audience attempt set tasks
- LTheir actions, times and difficulties are recorded
- LThis gives measurable evidence for judging requirements
- LProblems found lead to specific improvements
Usability testing puts the product in front of real users from the target audience and gives them tasks, such as finding this month's events, so their behaviour rather than their opinion is observed. Recording what each one does, how long it takes, where they hesitate and what they say produces measurable evidence, such as four of five users completing the task in under twelve seconds. That evidence is what the review uses to judge whether each requirement was met, and every difficulty observed points to a specific improvement, such as renaming a section to the word users were actually looking for.
- LEach requirement of the brief, judged with evidence
- LUser and stakeholder feedback, quoted
- LHonest strengths and weaknesses
- LSpecific improvements and further development
A review should take each requirement of the brief in turn, say whether it was met, and give the evidence from testing that shows it. It should include feedback from users and the client, quoted, including the criticism. It should state the product's strengths and weaknesses honestly, with reasons. And it should propose specific improvements, saying what would change, how and with what effect, as well as suggesting further development beyond the original brief.