Cross-Browser and Mobile Testing Without Endless Combinations

Why this matters

The solution is not random sampling, but a coverage model based on real usage, technical risk and representative rendering engines. The matrix should change as the audience and product change.

Automation can cover repeated core journeys, while targeted manual exploration catches touch, layout, keyboard and device-specific issues.

How to do it well

What to avoid

Hypothetical practical example

A team may automate login and campaign creation in Chromium, WebKit and Firefox, then manually explore the most-used iPhone and Android sizes.

An issue found only with a mobile keyboard can justify a new focused regression check without multiplying every scenario across every device.

Lesson for practice

A good practice does not have to be complicated. It should be intentional, repeatable and explainable: the team should understand why the control exists, what evidence it provides and how feedback will improve the next iteration.

A real example: support changes need an explicit decision

On 16 June 2022, the UK Government Digital Service publicly explained changes to its testing requirements for Internet Explorer 11. This is a digital-service governance example, not a banking incident. It illustrates why a browser matrix needs a rationale and maintenance rather than indefinite copying.

I would not transfer that service’s usage threshold or supported-version list directly into banking. The audience, contractual expectations and consequences of a failed transaction differ. What I would adopt is deliberate decision-making: why a combination is tested, to what depth, and what happens if someone uses it anyway. The explanation should be understandable to support staff and the service owner as well as developers.

A hypothetical matrix for a loan application

Imagine a web-based loan application with 60% desktop visits and 40% mobile visits. That is not necessarily the distribution of completed applications. I would compare starts, intermediate steps and successful submissions by device. A lower completion rate on phones could reflect less interest, but it could also indicate a form that cannot be completed on a particular combination. Traffic data alone cannot distinguish these possibilities.

The initial test set would therefore cover authentication, form completion, attachments and final confirmation. Automation would use representative browser engines; manual checks would include a physical phone with its virtual keyboard and a computer operated only through the keyboard. Viewport emulation is useful, but it does not establish what happens when switching between an authentication application and a browser, or when returning after a network interruption.

One invented test would start with a 4 MB attachment. The user opens the file picker, returns, rotates the phone and continues. I would examine not just button position but preserved input, upload state and the clarity of any error. Retrying submission should also be checked for duplicate applications. Visually identical screens matter less than an equally reliable and understandable result across supported combinations.

How I would consider less common combinations

A small group may still be important to the service. It may use assistive technology, managed corporate devices or an older system that cannot be changed immediately. I would not automatically exclude those users. With the service owner I would examine consequences, alternative routes and support costs. The resulting decision should be proportionate and recorded rather than hidden in an unchecked developer’s note.

I would also distinguish security support from functionality. If a platform is unsupported for security reasons, a polished appearance should not conceal that fact. Users need a clear explanation and a reasonable next step. Conversely, for supported combinations, recommending a different browser is not an adequate substitute for investigating a critical function that fails because of an unchecked implementation detail.

Reproduction and continuing maintenance

A defect record would include the actual operating-system and browser versions, viewport, zoom level, input method and stage of the process. A phone screenshot without those circumstances may be difficult to reproduce. I would also check whether the problem depends on the platform or on another account condition. Calling it a Safari defect solely because the first observation came from an iPhone would be premature.

I would revise the matrix after significant changes to forms, authentication or file handling, and periodically compare new releases with incident history and support feedback. A combination should not disappear from testing merely because it has not generated a recent complaint. Its usage may have changed, or affected users may simply abandon the process. For a newly supported platform I would start with critical journeys, then prioritise lower-impact visual differences.

Checking uncertainty on a slow connection

I would interrupt connectivity after submission but before confirmation appears. On return, the user should be able to establish the actual application state without creating another application accidentally. This connects interface design, integration and result consistency. A reassuring animation alone is not evidence of a completed operation; verification needs the server record as well as the information displayed to the user.

Summary and recommendations

I would treat the test matrix as an evolving decision about service availability. Every support level needs a clear meaning, and critical journeys should be checked on real equipment. I would measure task completion, preservation of information and recovery after interruption. The number of browsers ticked off becomes meaningful only when the team knows what was actually verified on each one.

Sources and links

• Government Digital Service — Internet Explorer 11 testing requirements, 16 June 2022
• GOV.UK Service Manual — Designing for different browsers and devices

Foreign cases provide analytical lessons; their legal frameworks and measures are not automatically applicable to Czech banks. Hypothetical examples and proposed methods do not describe inspections I personally conducted.