UX Testing

Why it matters

A product can pass every functional test and still lose users: the flow completes and the message is technically correct, yet people abandon the cart because the next step is unclear. Nothing crashed, so these failures are rarely reported.

UX testing turns a vague "it feels awkward" into findings a team can act on, each tied to a step and a violated expectation. ISO/IEC 25010:2023 places these qualities under interaction capability, with sub-characteristics such as operability, user error protection and self-descriptiveness, so a UX finding backed by a stated expectation is a quality defect like any other.

What UX testing checks

Usability testing observes participants; UX testing, as QA teams practise it, is the inspection you do yourself, every sprint, without them. It is not an ISTQB term; the nearest ISTQB technique is checklist-based testing, an experience-based technique: a fixed checklist applied while walking a flow, a narrower and repeatable form of heuristic evaluation.

Your test oracle, the source of the expected result, has four parts: the approved design, the product's own conventions (the same button behaves the same everywhere), recognised heuristics such as Nielsen Norman Group's ten, and WCAG 2.2, whose criteria on forms, navigation and errors are precise enough to cite. A finding backed by one of them is a defect; one backed only by preference is a suggestion.

• User flows: the screens from a goal to its confirmation, with the ways out and back in.
• Navigation: where the user is, where they can go, how they return.
• Forms: labels, hints, defaults, validation timing and the data after an error.
• Messages: errors, confirmations and empty states that say what happened and what to do next.

User flows and navigation

Write the flow as steps, each with a screen and an action: "Cart → Address → Delivery time → Payment → Review → Confirmation". Walk the happy path once, then every exit and return: Back from each step, refresh, reopening the app, a session expiring on Payment, an email link landing mid-flow. A good flow lets the user back out of any step without losing work (heuristic 3, user control and freedom).

At each step, ask three questions. Where am I: page title, highlighted menu item, step indicator ("Step 2 of 5"). Where can I go: buttons and links that name their action ("Continue to payment", not "OK"). How do I get back: a Back control that keeps the step's data. WCAG 2.2 gives citable criteria: 2.4.2 Page Titled (a title describing the page's topic or purpose), 2.4.4 Link Purpose (link text, with its context, says where it leads) and 3.2.3 Consistent Navigation (repeated menus keep the same relative order).

Flow: Order a meal (mobile web)

Step  Screen         Action          Exits to test
1     Cart           Continue        Back, refresh
2     Address        Save address    Back (cart kept?), refresh (form kept?)
3     Delivery time  Pick a slot     slot taken while choosing
4     Payment        Pay             card declined, session expired, Back
5     Review         Confirm order   double tap on Confirm
6     Confirmation   -               refresh (order repeated?), link from the email

Try it: User Story → Test Scenarios Try it: Test Scenario Generator

Forms and error messages

Forms are where many UX defects live, because there the product asks the user to do work. Check each form in three passes. Empty: visible labels, required fields marked in words, format hints such as DD/MM/YYYY before typing, sensible defaults and a fitting mobile keyboard, all preventing errors (heuristic 5, error prevention). Realistic valid data: a full Arabic name, a phone number with spaces, pasted values. Invalid data, as in the lesson on positive and negative testing.

On the invalid pass, watch timing and aftermath. Validation firing while the user still types is a finding; the usual expectation is validation on leaving the field or on submit, with focus moved to the first error. Typed values must survive the error, and the message belongs next to its field. WCAG 3.3.1 requires the field in error to be identified and the error described in text; 3.3.3, a known correction to be suggested; 3.3.7 Redundant Entry, information already given in the same process to be auto-populated or selectable, with exceptions such as re-entry for security. A payment step that makes the user retype the delivery address is a citable defect.

Heuristic 9 asks for messages in plain language, without codes, that state the problem precisely and suggest a solution. For a field that gives four checkable parts, in plain words without blame: name the field, say specifically what is wrong, say how to fix it and, where a format is involved, give a working example. Error 4011: Invalid input has none; "Mobile number: this number has 8 digits. Enter 9 digits starting with 5, for example 512345678" has all four. Confirmations and empty states pass the same test.

Field: mobile number. Rule: 9 digits starting with 5.

Weak:  Error 4011: Invalid input.
Good:  Mobile number: this number has 8 digits.
       Enter 9 digits starting with 5, for example 512345678.

Also check:  message sits next to the field        yes / no
             typed value is still in the field      yes / no
             focus moved to the field               yes / no
             same wording on every form             yes / no

Try it: Validation Test Generator Try it: Mock Error Payload Generator Try it: Fake Name Generator

The UX checklist, applied to a checkout

Turn these questions into a checklist with ids and one yes-or-no condition per item, as in the lesson on checklist-based testing. Run it per flow, not per page. Here it is on the meal-ordering flow, with what it found:

• FLW-04, two orders from a double tap on Confirm: Critical, a functional defect found by a UX check.
• FLW-02 and FRM-04, the cart empties on Back from Payment and the address form clears after an error: Major, the user loses work twice.
• MSG-01, "Something went wrong" on a declined card: Major, the user cannot tell whether to retry, change card or call the bank; proposed text attached.
• NAV-01, NAV-02, FRM-02, no step indicator, "OK" instead of "Continue to delivery time", a text keyboard for the card number: Minor each, grouped in one report.

UX checklist, run per flow                                 Result
FLW-01  Happy path completes without a dead end            pass
FLW-02  Back from every step returns with data intact      fail: Payment -> Cart empties
FLW-03  Refresh on any step keeps the entered data         pass
FLW-04  Double submit cannot create two orders             fail: orders 1042 and 1043
NAV-01  Every screen shows where the user is               fail: no step indicator
NAV-02  Every button names its action or destination       fail: "OK" on Address
NAV-03  Menus and controls in the same place everywhere    pass
FRM-01  Labels visible, required fields marked in words    pass
FRM-02  Hints before typing, mobile keyboard fits field    fail: text keyboard for card
FRM-03  No error shown while the user is still typing      pass
FRM-04  After an error, typed values are kept              fail: address form cleared
MSG-01  Error names the field, the problem and the fix     fail: "Something went wrong"
MSG-02  Confirmation says what happened and what is next   pass
MSG-03  Empty states say what to do                        n/a

Try it: AI QA Checklist Generator

Frequently asked questions

References

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• 10 Usability Heuristics for User Interface Design (Jakob Nielsen)Nielsen Norman Group · 1994Jakob Nielsen's ten broad rules of thumb for interface design — such as visibility of system status and error prevention — originally written for heuristic evaluation.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.