Mobile web testing should follow a task, not a screenshot

Choose a task worth completing on mobile

Start with a real product need. An illustrative service team might need to review an assigned item away from a desk. That does not automatically mean the whole administration console must have identical mobile behavior.

Define the task and its supported scope. Record the browser, viewport and input conditions used. A simulated mobile viewport provides useful layout evidence, but it is not identical to testing a physical device, operating-system keyboard or native application.

Follow the hidden transitions

Begin at the entry point a person would use, such as a notification link or the public navigation. Open menus, select the target item and attempt the task.

Inspect whether important context disappears behind a collapsed panel. Check if sticky elements cover the next action or an error message. Where the journey uses a table, determine whether the person can identify the record and understand what is offscreen.

Do not stop once the first mobile menu opens. The problem may appear several steps later when a dialog or picker uses more space than the remaining viewport.

Include input and recovery

Use safe data to complete a form. Inspect the behavior when the on-screen keyboard is present on a real supported device. Then introduce one invalid field and follow the correction path.

The practical questions are about completion: can the person find the error, reach the field and submit the corrected value without losing unrelated work? If the interface relies on hover behavior, check the intended touch alternative.

Also leave and return to the task. Record whether the application preserves the state it promises and whether a new session makes the next step understandable.

Compare outcomes, not visual sameness

A desktop and mobile layout can differ while supporting the same useful result. The comparison should focus on whether the task can be completed, what additional effort appears and which limitations are deliberate.

Use separate evidence labels for viewport simulation and physical-device checks. If a camera, file picker, browser permission or external app is involved, record which interaction was actually tested.

The result should be a bounded statement about the supported mobile journey. Avoid turning one successful screen size into a claim that every device, browser and input mode is covered.

Next step: Use the onboarding checklist as a task sequence, then add the mobile conditions relevant to your product.