R097 TA3: Creating, Testing and Reviewing
Building in the right order, evidencing a real range of skills, testing against the plan and writing an honest review.
Building in the right order
- Structure first. Create every screen and wire up the navigation with placeholder content. The product should be clickable end to end before anything looks finished.
- Content next. Drop in the real text, images, audio and video.
- Styling last. Apply the look once the structure has stopped moving.
- Test throughout. Not as a final stage.
Styling before the structure is settled means restyling everything when it changes, which is where most of the wasted time in this unit goes.
File and asset discipline
- A consistent naming convention, lower case, no spaces
- Folders by asset type:
images/,audio/,video/,css/ - Relative paths, never absolute ones, or nothing works on another machine
- Keep every source file as well as the exports
- Back up in a second location
Skills the assessment wants evidenced
| Area | What to show |
|---|---|
| Combining media | Text, image, audio, video and animation working together |
| Navigation | Working links across the whole product, no dead ends |
| Interactivity | Buttons, menus, rollovers, forms, quizzes, show and hide |
| Video editing | Trimming, cuts, transitions, titles, colour correction |
| Audio editing | Trimming, level balancing, fades, music mixed under narration |
| Optimisation | Assets compressed so the product loads quickly without visible loss |
| Accessibility | Alt text, captions, contrast, keyboard access, actually implemented |
Six different techniques used competently evidence more than one technique used brilliantly, because the criteria ask for a range.
- The background sits at the bottom of the stack.
- The photograph goes on a layer of its own, above it.
- The logo goes above that, so it is never painted into the photo.
- The text sits on top, and can be restyled without touching anything else.
- Flatten it and they merge into one image, and that is no longer editable.
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.
- 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.
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.
- Optimisation
- Reducing asset file sizes so a product loads quickly without visible quality loss.
- Relative path
- A file path given relative to the current file, so the product works on any machine.
- Iteration
- Improving a product through repeated cycles of building, testing and refining.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
- Build the structure first, style last, and test throughout
- Evidence a genuine range of techniques across text, image, audio, video and interaction
- 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
- Quote user feedback, criticism included, in the review
- Give specific improvements with the method and the expected effect
Mistakes that cost marks here
- Styling before the structure is complete, which means restyling it all later.
- Using absolute file paths, so nothing works on another machine.
- 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.
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
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- 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.