WDD14 - Testing: usability and compatibility
- I can design personas, scenarios and test cases, and use them to usability test a website.
- I can test input validation, navigation, links and media on a website.
- I can test a website's compatibility across different devices and browsers.
- I can write a persona, a matching scenario, and a specific test case for a given website feature.
- I can design validation test data covering normal, extreme and exceptional cases.
- I can identify an orphan page and explain why device and browser testing both matter.
WDD14 tests the HTML forms (WDD5), media (WDD4/5) and responsive layout built across the course so far.
Key vocabulary
Usability testing: personas, scenarios and test cases
Three tools, used together
WDD3 previewed three testing terms while planning wireframes for Meadows Wildlife Centre's website. This lesson teaches them properly. A persona is a fictional profile of a target user - not a real named individual, but a realistic composite built from the kind of person the site actually needs to serve. A scenario is a specific, realistic task that persona would try to complete using the site. A test case then makes that scenario testable: a precise sequence of actions, together with a clearly stated expected outcome, that a tester can actually carry out and mark as pass or fail.
Why all three, not just one
A persona on its own says nothing about what to test. A scenario without a test case is not checkable - "find a workshop and enquire" is a good scenario, but it needs a test case's precision ("enter school name, class size 28, and a date within the next term, then press submit; expect a confirmation message") before anyone can actually run it and get a pass or fail result. Used together, the three build outward from a realistic person, to a realistic goal, to something a tester can genuinely check off.
Testing input validation, navigation and links
Validation testing needs three kinds of data
WDD5 taught how to build validation rules - presence, length and range checks on form inputs. Testing those rules properly means trying all three categories of test data on each one: normal data that should be accepted (a class size of 20, within an allowed range of 1-35), extreme data at the very edge of what is allowed (exactly 1, or exactly 35), and exceptional data that should be rejected (0, 36, or text typed into a number field). Testing only with normal data can make a form look correctly validated when its boundary or rejection behaviour is actually broken.
These three category names come from the SDD unit (SQA uses normal, extreme and exceptional). Other sources sometimes say "erroneous" for the third category - it means the same thing, but use "exceptional" in your answers.
Testing navigation, links, and orphan pages
Link testing checks that every navigation link and in-page link actually leads to its correct, intended destination - not just that it is clickable, since a broken or mistargeted link is still clickable. A separate, easily missed check is for orphan pages: pages that genuinely exist on the site, but that no other page links to. An orphan page cannot be reached by a user browsing normally, and is effectively invisible, even though the file itself works perfectly if visited directly. Finding orphan pages means checking in the opposite direction from ordinary link testing - not "does this page's links work", but "does anything on the site actually link to this page at all".
Testing media and cross-device/browser compatibility
Media testing
Media testing checks that every image and other media element actually loads, displays at a sensible size without breaking the surrounding layout, and has appropriate alt text for accessibility (recapping WDD4's semantic HTML). A missing or incorrect alt attribute is a genuine testing failure, not a cosmetic detail, since it directly affects whether a screen reader user can access the same content.
Device compatibility
Device compatibility testing checks that a page displays and behaves correctly across different screen sizes - phone, tablet and desktop - since a layout built and only ever viewed on one screen size can look completely broken on another. This site's own stylesheets already use @media (max-width: 640px) rules throughout for exactly this reason.
Browser compatibility
Browser compatibility testing checks the same page in multiple different browsers - Chrome, Firefox, Safari, Edge - because different browsers can render CSS and run JavaScript with small but real differences. A page that looks correct in the browser it was built in can still have a genuine, undiscovered fault in another.
does this page work?
Worked examples
| Test data | Category | Expected result |
|---|---|---|
| 20 | Normal | Accepted |
| 1 | Extreme | Accepted |
| 35 | Extreme | Accepted |
| 0 | Exceptional | Rejected |
| 36 | Exceptional | Rejected |
| "twenty" | Exceptional | Rejected |
A form field accepts a date within the next 90 days. Suggest one normal, one extreme, and one exceptional piece of test data for it.
Normal: a date 30 days from today.
Extreme: exactly 90 days from today (the boundary).
Exceptional: a date 91 days from today, or a date in the past.
Practical: testing your own earlier work
Open one of your own WDD1-13 practical files (or the Meadows Wildlife Centre example from WDD3) and apply today's checklist directly to it.
- Write one persona and one matching scenario for a genuine feature of the page.
- Write a specific test case for that scenario, with a clear expected result.
- If the page has a form, design normal/extreme/exceptional test data for one field.
- Check every link on the page leads to its correct destination, and check whether any page in the site is never linked to from anywhere else.
- Open the page in at least two different browsers, and view it at both a narrow (phone-width) and wide (desktop-width) browser size, noting anything that looks or behaves differently.
- Writing a scenario that is too vague. "Use the website" is not testable - a scenario needs a specific, realistic goal a persona is trying to achieve.
- Testing only normal data for validation. Extreme and exceptional data are just as important - a field can look correctly validated while its boundary or rejection behaviour is actually broken.
- Assuming a link works because it is clickable. A link can be clickable and still lead to the wrong destination - and checking every page's own links still will not reveal an orphan page, which needs the reverse check.
- Testing on only one device or browser. A page that looks correct in the browser and screen size it was built on can still have a genuine fault elsewhere.
Use the precise terms persona, scenario and test case as three distinct things, not interchangeably. For validation testing, always name all three categories - normal, extreme and exceptional - rather than describing testing in general terms. Remember an orphan page is found by checking what links to a page, not by checking that page's own links outward.
Task Set B — Core questions
Task Set C — Extension
File this in OneNote under:
Higher Computing Science > Web Design & Development > WDD14
Timing: content is scoped for a double period and lands on one (Thu 10 Dec 2026, per WDD.md §2a/§4 table) - an "OK" match. This lesson deliberately covers six sub-topics that Chris compresses into half of one lesson (L14): usability testing (persona/scenario/test case), input validation testing, navigation/link testing including orphan pages, media testing, device compatibility, and browser compatibility. Suggested pace: 8 min warm up, 15 min usability testing notes + Example 1, 20 min validation/link/orphan-page notes + context box + Examples 2-3, 15 min media/device/browser notes, remaining time on Task Set B, then Task Set C and the practical.
Scope control: no TYPE 4 code block in Task Set B, since this is a testing/evaluation lesson, not a coding lesson, per CLAUDE.md's instruction to remove it when not applicable. The practical deliberately reuses pupils' own earlier WDD files rather than introducing a new build, keeping the double period's generous time focused on testing skills rather than new construction.
Persona/scenario/test case terminology was already previewed in WDD3 (Meadows Wildlife Centre wireframing) - this lesson is pupils' second, formal exposure to the same terms and reuses the same fictional project for continuity, matching the two-stage pacing WDD.md documents for this pair of lessons.
The orphan page concept is the highest-value gotcha in this lesson - pupils very naturally check a page's own outgoing links and assume that is sufficient, missing that orphan detection requires the reverse, incoming-link check. A5/A6/context box/Example 3/B3 all test this from different angles.