Ответ.

Ручное тестирование совместимости — это проверка того, как ПО функционирует в различных окружениях (например, разных ОС, браузерах, мобильных устройствах), чтобы убедиться, что оно корректно работает для всех целевых пользователей.

История вопроса: С развитием технологий и увеличением числа платформ и устройств стандартом стала проверка, работает ли приложение одинаково на Windows и Mac, Android и iOS, Chrome и Firefox. Недостаточное внимание к совместимости ранее приводило к потере доли пользователей и убыткам бизнеса.

Проблема: Главная сложность — огромное количество возможных комбинаций окружений: версий браузеров, ОС, разрешений, языков интерфейса. Протестировать их все невозможно, но пропуск критичных случаев ведет к ситуациям, когда у части пользователей продукт не работает.

Решение: Внедряют стратегическое тестирование по:

Анализу статистики реальных пользователей (Google Analytics, Яндекс.Метрика, Mixpanel и др.) для выделения топовых платформ/устройств.
Совмещению smoke- и целевых сценариев на ключевых сочетаниях платформ.
Документированию найденных несовместимостей с полным описанием окружения.

Ключевые особенности:

Тестировать нужно именно реальные пользовательские сценарии на целевых устройствах.
Важно фиксировать всё окружение: ОС, язык, разрешение, браузер, версия ПО.
Часто требуется использовать эмуляторы и физические устройства одновременно.

Вопросы с подвохом.

Достаточно ли протестировать только последние версии браузеров и ОС?

Нет! Реальные пользователи часто используют и устаревшее ПО (например, IE11 или старые Android), поэтому соответствие только новым версиям может привести к упущенным критичным багам.

Можно ли заменить тестирование на реальных устройствах проверкой в эмуляторах?

Нет. Многие баги проявляются только на реальном "железе" (проблемы с памятью, ускорением, сенсорикой и т.д.), эмуляторы лишь частично эффективны.

Все ли проблемы совместимости фатальны для релиза?

Не обязательно, некоторые из них можно признать известными ограничениями — важно объективно оценивать бизнес-риски и плотность пользовательской аудитории для такой комбинации.

Типовые ошибки и анти-паттерны

Тестирование только на стандартном окружении, игнорирование других популярных платформ.
Неудержание информации о среде воспроизведения.
Полная ориентация только на эмуляторы без физического контроля.

Пример из жизни

Негативный кейс

Магазин выпустил мобильное приложение, протестировали только на эмуляторах Android 11-12 c Google Pixel. Через неделю начали поступать негативные отзывы от пользователей на Xiaomi и Samsung со старыми версиями ОС — приложение не открывалось.

Плюсы:

Быстрая проверка основных сценариев.

Минусы:

Пропущены значимые комбинации устройств и версий.
Рост негативных отзывов и потери лояльной аудитории.

Позитивный кейс

Перед релизом командой был отобран парк популярных устройств и браузеров, ключевые сценарии прошли итерацию на каждом, баги формализованы и приоритизированы с руководством продукта.