Returns Portals
Part of Returns portals and self-service tools
Testing a customer return request on mobile
A mobile test procedure for return requests, covering order lookup, reason capture, submission, staff records and selected accessibility checks.
Test a return request from its starting point through confirmation, then check what staff received. Use controlled orders and a phone as well as a narrow browser view. A form can look clear at first but lose entered information when someone switches to email, selects one item from a longer order or corrects an error.
Prepare the cases
Create safe test orders or use a controlled environment. Include a single-item order, a multi-item order, a reported product problem after the voluntary change-of-mind period and an order lookup that should fail. For each, record the expected customer path and staff record. Avoid triggering a real refund, chargeable label or live stock change.
Use the phone browsers and sign-in methods the store expects customers to use. Record the device, browser and viewport so a failure can be reproduced. If sign-in sends a code by email, switch to email and back; check whether the request retains its place.
Return Test Case Coverage
- Single-item order
- Tested
- Multi-item order
- Tested
- Post-change-of-mind problem report
- Tested
- Failed order lookup
- Tested
Follow the customer's steps
- Find the start.From the order email or returns page, find the request action and any terms needed before submission.
- Identify the order.Try valid details, a typo and an unknown order. Check that errors explain what to correct or how to get help without showing another customer's order.
- Select the item.On a multi-item order, distinguish the product, variant and quantity. Check that a mistaken selection can be corrected.
- Describe the issue.Try a preset reason and an account that does not fit the menu. Check that the customer can explain the problem without selecting a false reason or making a legal diagnosis.
- Review and submit.Check the summary, any cost or next-step wording and whether a repeated tap creates duplicate requests. Confirmation should identify the request and say whether it awaits review.
- Check the staff record.Confirm that the correct order line, selected reason, customer words and requested outcome arrived together. Compare the staff record with the customer's confirmation.
Check the narrow view and input controls
At a width equivalent to 320 CSS pixels, check that ordinary form content reflows without losing information or requiring horizontal scrolling. WCAG 2.2's reflow criterion allows exceptions for content that needs a two-dimensional layout. Inspect long product names, validation messages and the on-screen keyboard, not only the first screen.
Check that inputs have labels or instructions and that a detected error identifies the affected input in text. Check whether buttons and choices can be distinguished and activated. WCAG 2.2's minimum target-size criterion generally specifies 24 by 24 CSS pixels, with exceptions that include sufficient spacing. Follow the form with a keyboard and check that focus order preserves the task.
Record each failure with its step, device or viewport, input, expected result and actual result.
Mobile Accessibility & Usability Checks
- Reflow at 320px widthContent reflows without horizontal scrolling; no information lost.
- Labels or instructions for inputsAll form fields have clear labels or guidance.
- Error identificationErrors clearly identify which input needs correction.
- Target size (minimum 24x24px)Buttons and interactive elements meet minimum size requirement with sufficient spacing.
- Keyboard navigation focus orderFocus follows logical sequence through form steps using keyboard only.
Decide what needs fixing
Treat a blocked product-problem report, an incorrect order line, a lost customer explanation or a confirmation without a matching staff record as a release issue. Fix the path and repeat that case from the start. Give smaller wording or layout issues an owner and retest date.
