R097 TA3: Testing and Reviewing Interactive Digital Media
Testing
Test against the plan, not against what you happened to build.
| Test type | What it checks |
|---|---|
| Functionality | Every button, link and interactive element does what it should |
| Navigation | Every screen reachable, every route back working |
| Content | Spelling, accuracy, and everything the brief specified being present |
| Media | Video and audio play, at a sensible level, on every screen |
| Compatibility | Different browsers, devices and screen sizes |
| Accessibility | Keyboard only, screen reader, contrast, text resized to 200% |
| Performance | Load time on a slow connection |
| Usability | A real user completing a task without help |
Recording a test properly
| # | Test | Data or action | Expected | Actual | Action taken |
|---|---|---|---|---|---|
| 1 | Home to Topic 3 | Tap Topic 3 | Topic 3 screen opens | As expected | None |
| 2 | Back from video | Tap Back during playback | Returns to topic, audio stops | Audio kept playing | Added a stop on unload; retested, passes |
The expected result has to be written before the test is run, or there is nothing to compare against. Record failures and the fix, because a test log with no failures is not believable.
Usability testing
Give a real user a task, not a tour: "find out what time the museum opens on a Sunday and book two tickets." Then stay quiet and write down every hesitation, wrong tap and backtrack. The hesitations are the findings. Five users will surface most of the problems.
You know where everything is, so you cannot experience being lost in it. Every evaluation that consists of the maker using their own product scores badly, and deserves to.
Reviewing and improving
What the review must contain
- Against the brief, requirement by requirement, with evidence of where each is met.
- Stakeholder and user feedback, quoted, including the criticism.
- Honest strengths and weaknesses, with reasons.
- Specific improvements, each with how it would be implemented and what effect it would have.
- Further development: how the product could grow beyond the brief, such as new features, content or platforms.
- Reflection on the process: what you would plan differently, and why.
Turning a weak review into a strong one
| Weak | Strong |
|---|---|
| "The navigation worked well." | "Four of five testers reached the booking screen in under three taps. The fifth looked for a 'Book' button in the top right, where the convention puts it, and did not find it in the menu; I would add a persistent booking button to the header." |
| "I would add more content." | "Each topic has text and one image. Two testers asked for sources, so I would add a short references panel under each topic, collapsed by default so it does not compete with the main text." |
| "It all went to plan." | "I styled the topic screens before the navigation was finished, so adding the video screen meant restyling three screens. Next time I would leave all styling until the structure is signed off." |
"It is easy to use" is an opinion. "Five of six testers completed the task without help, and the one who failed was looking for a search function that does not exist" is evidence. The review is marked on evidence.
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: the research behind small, repeated usability tests.
- W3C: easy checks for accessibility: simple accessibility tests anyone can carry out.
- WebAIM contrast checker: test text colours against the standard.
- Nielsen Norman Group: 10 usability heuristics: principles to review an interface against.
Key terms you must be able to define
- Functionality testing
- Checking that every interactive element behaves as intended.
- Usability testing
- Observing a real user attempting a task and recording where they struggle.
- Compatibility testing
- Checking the product on different browsers, devices and screen sizes.
- Test plan
- A document listing each test, the data used and the expected result, written before testing.
- Review
- A judgement of the product against the brief, backed by evidence.
- Further development
- How a product could be extended beyond the brief, such as new features or platforms.
- Iteration
- Improving a product through repeated cycles of building, testing and refining.
Flashcards
Reach the top grade on this topic
- Record the expected result before each test, and log the failures with their fixes
- Watch real users attempt a task rather than demonstrating the product yourself
- Review against the brief requirement by requirement, with evidence
- Quote user feedback, criticism included
- Give specific improvements with the method and the expected effect, and suggest further development
Mistakes that cost marks here
- Testing only what already works.
- Writing the expected result after seeing the actual result.
- Evaluating by using the product yourself instead of watching someone else.
- A test log with no failures in it, which no assessor believes.
- Reviews that praise everything and improve nothing.
- Improvements with no explanation of how they would be made or what they would achieve.
A usability study only needs about five participants to find most of the problems in a product. The sixth person mostly rediscovers what the first five already showed you, which is why professional testing rounds are small and repeated.
Knowledge check
Check you could explain this
- LThe creator already knows how it works
- LSo they cannot experience being confused by it
- LA new user reveals real problems
The creator has an unavoidable advantage: they built the navigation, so they know where everything is and cannot experience the moment of not knowing. That means they are blind to exactly the problems testing is meant to find, and will unconsciously take the route they designed rather than the route a stranger would try. Someone from the audience, given a task and left alone, hesitates in places the creator never considered, taps things that are not buttons and looks for features that are not there, and every one of those moments is a finding that can be fixed.
- LFunctionality testing
- LNavigation testing, or content testing
- LCompatibility testing
- LUsability or accessibility testing
Functionality testing checks that every button, link and interactive element does what it is supposed to do. Navigation testing confirms that every screen can be reached and that there is always a route back, so no user becomes stuck. Compatibility testing runs the product on different browsers, devices and screen sizes, which catches layouts that only work on the machine it was built on. Usability and accessibility testing put it in front of real users, including keyboard only and screen reader use, to find where people struggle rather than where the code fails.
- LCompare against the brief point by point
- LWhy that matters
- LGather feedback from the target audience, not friends, and quote it
- LWhy that matters
- LIdentify specific weaknesses honestly
- LGive improvements with the method and effect
First, it should work through the brief requirement by requirement, quoting each one, saying whether it was met and pointing to the screen where it was met, because the review is assessed on evidence and a general statement that everything worked proves nothing. Second, the feedback should come from people in the target audience rather than from friends, who are both unrepresentative and reluctant to criticise, and it should be quoted: what the tester was asked to do, what they actually did, and what they said. Third, the improvements have to be specific and come with a method and an expected effect. 'More content' is not a plan; 'two of five testers looked for a search function, so I would add a search field to the header, which would let users reach a topic directly instead of scanning the menu' identifies the evidence, the change and the benefit. Underneath all three is the same point: a review that finds nothing wrong reads as a review that was never carried out, and honest criticism of your own work is the thing being credited.