Device matrix — это обоснованный набор устройств и конфигураций, на которых команда проверяет мобильное приложение. Его задача — покрывать существенные риски при доступном времени. Коллекция самых дорогих телефонов и длинный список моделей без объяснений одинаково плохо помогают принять решение о релизе.
Для QA матрица полезна, когда по ней видно три вещи: какие пользовательские группы представлены, какие свойства платформы проверяются и какое покрытие выполнено на каждом устройстве. Само количество телефонов не отвечает ни на один из этих вопросов.
Откуда брать исходные данные
Начни с продуктовой аналитики: модели, версии ОС, доля активных пользователей и особенности ключевых рынков. Сопоставь их со статистикой ошибок и обращениями в поддержку. Популярное устройство с устойчивыми сбоями заслуживает внимания даже при обычных характеристиках.
Для нового продукта используй гипотезы о целевой аудитории, минимальные системные требования и доступные рыночные данные. Пометь допущения и назначь дату пересмотра: предположительная матрица не должна оставаться неизменной после появления реального трафика.
Какие измерения действительно важны
Не превращай каждую характеристику в отдельную обязательную комбинацию. Выбирай свойства, которые способны менять поведение именно твоего приложения.
- →Версия ОС, включая минимально поддерживаемую и актуальные используемые версии.
- →Производительность, объём памяти и доступное место.
- →Размер окна, плотность экрана, вырезы и особенности навигации.
- →Производитель и системные ограничения фоновой работы.
- →Доступность камеры, биометрии, NFC и других нужных модулей.
- →Локаль, размер текста, способы ввода и средства доступности.
Для карт критична геолокация, для банковского продукта — безопасный вход, для каталога с видео — память и декодирование. Матрица должна отражать эту разницу.
Разделяй охват аудитории и риск
Высокая доля пользователей помогает выбрать основную конфигурацию, но редкое устройство может представлять важный класс риска: минимальную ОС, мало памяти или складной экран. Эти причины лучше записывать явно.
Не складывай проценты независимых измерений. «Покрыли 80% моделей» и «покрыли 90% версий ОС» не означают 170% покрытия или гарантированные 80% пользователей. Для точной оценки нужна совместная статистика конфигураций и понятный знаменатель.
Уровни проверки
На основном наборе выполняют критические пользовательские сценарии при каждом значимом релизе. На расширенном — выборочную совместимость, изменения платформы и зоны риска. Редкие аппаратные сценарии можно проверять по изменению соответствующей функции.
Это не разрешение забыть расширенный набор. Укажи частоту, ответственного и повод запуска. Например, обновление камеры требует физической проверки съёмки, даже если обычный smoke уже прошёл на эмуляторе.
Практический пример: приложение доставки
Представь команду с шестью физическими устройствами и ограниченным доступом к облачной лаборатории. Основные операции — вход, адрес, корзина, оплата и отслеживание заказа.
- 1.Выбери распространённый Android среднего класса и распространённый iPhone как основные конфигурации.
- 2.Добавь Android с минимальной поддерживаемой ОС и ограниченной памятью: это проверка границы поддержки, а не копия основного устройства.
- 3.Добавь устройство производителя, у которого в поддержке часто встречаются проблемы фоновых обновлений.
- 4.Выдели небольшой экран для адресной формы и крупный экран для адаптивного интерфейса, если продукт их поддерживает.
- 5.На основном наборе пройди заказ целиком. На остальных проверь адрес, клавиатуру, оплату и восстановление отслеживания после фона.
- 6.Запиши ожидаемые результаты и реальные пробелы: например, бесконтактная оплата пока не проверена, потому что нет нужного оборудования.
Такой отчёт позволяет оценить остаточный риск. Формулировка «проверено на шести телефонах» скрыла бы те же ограничения.
Где помогают эмуляторы и симуляторы
Виртуальные устройства удобны для вариантов ОС, размеров окна, автоматизации и быстрого воспроизведения состояния. Android прямо рекомендует использовать эмуляторы для разных версий платформы и разрешений экрана.
Однако результаты производительности, работы радиомодулей, батареи и аппаратных интеграций нужно подтверждать на подходящих физических устройствах. Особенно осторожно сравнивай iOS Simulator на мощном компьютере с реальным телефоном: характеристики хоста не описывают пользовательское устройство.
Как использовать облачную лабораторию
Облако расширяет доступный набор моделей, но перед запуском проверь ограничения: доступ к SIM, геолокации, внешним аксессуарам, уведомлениям, системным настройкам и файлам. Удалённое устройство не гарантирует наличие любого физического сценария.
Для сложного дефекта сохраняй модель, точную версию ОС, номер сборки, логи и видео. Без этих данных успешный запуск на похожем облачном устройстве может ошибочно выглядеть как опровержение бага.
Матрица как рабочий документ
Для каждой строки полезны причина включения, характеристики, сценарии, частота запуска, доступность устройства и последний результат. Версия ОС должна быть конкретной: после автоматического обновления прежняя конфигурация уже не существует.
Периодически сверяй матрицу с аналитикой и изменениями продукта. Отказ от старой ОС, рост доли планшетов или внедрение сканера документов должны менять состав и глубину проверок.
Типичные ошибки
Выбор только по бренду пропускает свойства, которые действительно влияют на поведение. Полный декартов набор всех параметров, наоборот, делает матрицу невыполнимой. Ещё одна ошибка — считать запуск приложения достаточным подтверждением совместимости.
Похожая проблема возникает, когда команда пишет «Android проверен», хотя использовала одну модель с одной версией ОС. Платформу представлял конкретный экземпляр, и границы вывода должны быть видны.
Что должен вынести QA
Хорошая матрица объясняет выбор конфигураций и связывает каждую с пользовательским риском. Используй аналитику, историю дефектов и архитектуру функций; сочетай виртуальные и физические устройства. В отчёте показывай выполненные сценарии и пробелы покрытия, чтобы релизное решение опиралось на факты.