Продукт корректно обрабатывает одинаковые данные в одной среде, но нарушает тот же сценарий в другой. Какой вид тестирования следует применить первым и что именно сравнивать?
Следует начать с тестирования совместимости: выполнить один и тот же значимый сценарий в различающихся средах и сравнить фактические результаты с ожидаемыми. Менять нужно по одной оси за раз либо использовать заранее определённую матрицу, чтобы связать отклонение с конкретной комбинацией браузера, операционной системы, устройства, версии платформы или конфигурации.
Подход появился как ответ на то, что программный продукт работает не в одной контролируемой среде. Различия платформ, браузеров, устройств, версий библиотек, разрешений и настроек могут менять выполнение одного и того же сценария.
Проверка только функциональности в эталонной среде не выявляет такие расхождения. Тестирование совместимости дополняет функциональные проверки, а не заменяет их.
Если сценарий успешен в одной среде и ошибочен в другой, причиной может быть несовместимость API, различие реализации стандарта, особенности файловой системы, локали, часового пояса, кодировки, аппаратных возможностей или конфигурации.
Неверно сразу объявлять проблему дефектом конкретного браузера или операционной системы. Сначала нужно зафиксировать версии, конфигурацию, входные данные, шаги, ожидаемый и фактический результат, а затем определить минимальную комбинацию условий, при которой появляется расхождение.
Сначала выбирают критичные пользовательские сценарии и поддерживаемые среды. Приоритет среды определяется не только техническим разнообразием, но и долей пользователей, бизнес-критичностью сценария, стоимостью ошибки и официальной поддержкой продукта.
Затем формируют матрицу: например, сценарий сопоставляется с версиями браузеров и операционных систем. В каждой ячейке проверяют одинаковые предусловия, входы и критерии приемки. Если одновременно менять браузер, ОС и версию сервера, причинно связать результат с одним фактором будет трудно.
Нужно различать несколько аспектов:
Если дефект воспроизводится только в одной среде, полезно провести контрольный запуск в другой среде, где сценарий успешен, и затем локализовать различие. Автоматизация помогает повторять проверки на матрице, но не отменяет выбор реально поддерживаемых комбинаций: полный перебор всех устройств, версий и настроек обычно слишком дорог.
Компромисс состоит в покрытии наиболее рискованных комбинаций вместо формального перебора. При этом редкие среды нельзя исключать без анализа: небольшая доля пользователей может иметь высокую бизнес-ценность или особые требования доступности.
Форма оплаты проходит в актуальном браузере на настольной ОС, но на мобильном браузере после подтверждения заказа пользователь возвращается на предыдущий экран. Рассматривались три варианта.
Проверить только серверную часть быстро, но это не объясняет различие пользовательского сценария. Проверить все сочетания устройств и браузеров полностью надёжно, но слишком дорого. Ограничиться ручной проверкой одного мобильного устройства дёшево, однако результат может зависеть от конкретной версии ОС и не представить весь риск.
Выбран вариант с матрицей критичных комбинаций: поддерживаемые мобильные ОС, версии браузеров с существенной аудиторией и два типа сетевого соединения. Один сценарий воспроизвели в каждой ячейке, отдельно проверили журналы клиента и сервера. Дефект связали с конкретной комбинацией мобильного браузера и способом возврата после подтверждения, после чего исправление проверили повторно на этой комбинации и регрессионно на остальных поддерживаемых средах.
Да, критерий совместимости задаётся областью поддержки продукта. Неподдерживаемая среда не обязана иметь тот же уровень качества, но продукт должен явно сообщать ограничения, если это влияет на пользователя. При этом неожиданная работа в неподдерживаемой среде не превращается автоматически в обязательство её поддерживать.
При обычном повторном запуске среда остаётся частью фиксированного контекста и проверяется, сохранилось ли поведение после изменения продукта. В совместимостном тестировании сама среда является изменяемым фактором: один и тот же сценарий сравнивается между поддерживаемыми платформами или конфигурациями. Поэтому важны не только шаги и результат, но и точная фиксация среды.
Нужно повторить сценарий в тех же условиях, выполнить его в контрольной среде и проверить, сохраняется ли зависимость от конкретного фактора. Если результат меняется без изменения продукта и среды, подозрение падает на нестабильность теста, внешнюю зависимость или состояние данных. Если отклонение стабильно возникает в определённой поддерживаемой комбинации, это сильный признак дефекта совместимости, который следует подтвердить минимальным воспроизводимым сценарием.