---
title: "cross-device testing | Skills We Assign For | Azendo"
description: "Cross-device testing in practice — choosing a matrix from real data, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/cross-device-testing/"
---

[Skills](https://azendo.co/skills/) Testing practice 

# cross-device testing.

Cross-device testing verifies that an application behaves correctly across the range of screen sizes, input methods, operating system versions and hardware capabilities that real users have, rather than only on the machines the team builds on.

## Where cross-device testing fits on a long engagement.

Development machines are systematically unrepresentative. They are faster, their screens are larger, their connections are better, and they run current operating systems. Every one of those differences hides a class of defect that a proportion of real users will hit immediately.

The mid-range Android device is the case most often missed and the most consequential. Animations that are smooth on a flagship stutter, memory pressure causes background eviction, and a layout that fits on a large screen is cramped on a small one. These are not edge cases; on many products they are the median user.

## What an assigned team does with cross-device testing.

Exhaustive coverage is impossible and is the wrong target. The realistic goal is a matrix representing the meaningful segments of the installed base, refreshed as that base changes, with everything else accepted as risk deliberately rather than by omission.

Deciding that explicitly is test-strategy work, and it belongs with the people who also run the tests, under [qa outsourcing](https://azendo.co/services/qa-engineering-and-test-automation/) capacity.

## What we use cross-device testing for.

* Verifying on hardware users actually hold Mid-range devices in the loop, where performance problems are real rather than theoretical.
* Layouts checked across the size range Small screens and large ones verified, including the text-scaling settings people actually use.
* Risk accepted deliberately A written statement of what is not covered, so the gap is a decision rather than an oversight.

## How cross-device testing capacity is assigned.

The device matrix is derived from your analytics at scoping, and what is deliberately not covered is written down. That division between your direction and our delivery is described in [how an assignment runs](https://azendo.co/how-it-works/).

## Roles we assign cross-device testing for

* [Manual QA Tester QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/manual-qa-tester/)

## Service lines it sits in

* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in testing practice

* [exploratory testing — skill we assign for](https://azendo.co/skills/exploratory-testing/)
* [risk-based testing — skill we assign for](https://azendo.co/skills/risk-based-testing/)
* [Test strategy and planning — skill we assign for](https://azendo.co/skills/test-strategy-and-planning/)
* [acceptance criteria validation — skill we assign for](https://azendo.co/skills/acceptance-criteria-validation/)
* [bug reporting with reproduction steps — skill we assign for](https://azendo.co/skills/bug-reporting-with-reproduction-steps/)

## Tell us what your roadmap needs cross-device testing for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)