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 erroneous 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 erroneous 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.
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 | Erroneous | Rejected |
| 36 | Erroneous | Rejected |
| "twenty" | Erroneous | Rejected |
A form field accepts a date within the next 90 days. Suggest one normal, one extreme, and one erroneous piece of test data for it.
Normal: a date 30 days from today.
Extreme: exactly 90 days from today (the boundary).
Erroneous: 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/erroneous 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 erroneous 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 erroneous - 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 A - Core questions
Task Set B - 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 A, then Task Set B and the practical.
Scope control: no TYPE 4 code block in Task Set A, 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.