Compatibility testing — проверка способности продукта работать в согласованных окружениях и взаимодействовать с поддерживаемыми версиями других компонентов. Пользователь открывает документ, обновляет приложение или подключает интеграцию и ожидает сохранения результата. Несовместимость часто возникает даже тогда, когда каждая сторона отдельно проходит функциональные тесты.
Задача QA — сделать границы поддержки явными, выбрать значимые сочетания и проверить поведение на переходах. Формулировка «работает на всех устройствах» не помогает ни планировать проверки, ни принимать решение о выпуске. Нужны конкретные версии, сценарии и правила для окружений за пределами поддержки.
Что входит в совместимость
Совместимость шире браузерной отрисовки. Для мобильного приложения важны ОС, аппаратные возможности и системные разрешения. Для настольного клиента — форматы файлов, драйверы и корпоративные политики. Для сервиса — версии API, схемы сообщений, кодировки и внешние зависимости. Один продукт может содержать все эти границы одновременно.
Разделяйте совместимость окружения и взаимодействие компонентов. Первый вопрос: запускается ли клиент на минимальной ОС? Второй: сможет ли этот клиент прочитать ответ нового сервера? У этих рисков разные данные, владельцы и наборы тестов.
Как определить поддержку
Начните с продуктовых обязательств, договоров, аналитики и архитектуры. Зафиксируйте минимальные версии, основные конфигурации, исключения и порядок прекращения поддержки. Уточните, что означает поддержка: полная функциональность, ограниченный режим или только возможность безопасно экспортировать данные.
Для внешних сервисов укажите не только название поставщика, но и версию контракта, режим авторизации, обязательные заголовки. Поддерживаемая интеграция может перестать работать после изменения схемы или настройки шлюза, хотя пользовательский интерфейс приложения не менялся.
Как построить матрицу
Список комбинаций растёт быстрее бюджета. Поэтому матрица должна отражать вероятность использования и ущерб отказа, а не математическое желание перебрать всё. Отдельно отметьте договорные конфигурации: небольшой процент аудитории не отменяет обещанную поддержку.
- →Базовые сочетания проверяют критические цепочки при каждом значимом выпуске.
- →Граничные сочетания включают минимальные версии и компоненты на пороге обновления.
- →Редкие сочетания выбирают по рискам конкретного изменения и истории дефектов.
Комбинационные техники помогают сократить перебор независимых факторов. Они не заменяют обязательную цепочку, в которой взаимодействуют сразу несколько зависимых компонентов.
Версии клиента и сервера
Проверяйте переходное состояние выпуска: старый клиент с новым сервером, новый клиент с поддерживаемым старым сервером, совместную работу разных версий. Такая ситуация нормальна при постепенном развёртывании и задержке обновления мобильных клиентов.
Добавление необязательного поля обычно менее рискованно, чем удаление существующего, но это не универсальная гарантия: клиент может строго проверять схему или значения перечисления. Полезны контрактные проверки реальных потребителей. Они обнаруживают несовпадение ожиданий, однако не доказывают корректность полного пользовательского сценария.
Данные и форматы
Открытие файла ещё не подтверждает совместимость. Проверьте значения, порядок, кодировку, изображения, формулы и возможность повторного сохранения. Иногда приложение читает документ, но при сохранении теряет неизвестные поля и делает его непригодным для другой версии.
Для API проверьте отсутствующие и новые поля, неизвестные значения, большие идентификаторы, пустые коллекции и правила времени. Не предполагайте, что успешный статус означает правильное понимание ответа. Ожидаемый результат должен включать бизнес-значение данных и допустимое поведение при неизвестном формате.
Практический пример: обновление заказов
Команда добавляет в заказ состояние «частично отправлен». Поддерживаются мобильные клиенты двух поколений, веб-клиент и партнёрский экспорт. На тестовом стенде подготовьте заказ с двумя позициями, из которых отправлена одна, и сохраните ожидаемые количества.
- 1.Откройте заказ старым клиентом после обновления сервера. Ожидается предусмотренное контрактом отображение неизвестного состояния без падения и без ложного сообщения «доставлен».
- 2.Откройте тот же заказ новым клиентом. Ожидается правильное состояние каждой позиции и общий оставшийся объём.
- 3.Экспортируйте и повторно импортируйте заказ поддерживаемыми версиями. Ожидается сохранение идентификаторов, количества и уже выполненных действий.
- 4.Повторите цепочку после отката клиента. Проверьте, что совместимость данных соответствует обещанному сценарию отката.
Если требования не определяют fallback для неизвестного состояния, это вопрос к контракту до запуска проверки, а не возможность выбрать удобный результат постфактум.
Что делать за границей поддержки
Неподдерживаемое окружение не обязательно должно работать полностью. Но продукту полезно сообщать ограничение понятным образом, если такой сценарий предусмотрен требованиями. Проверяйте отсутствие повреждения данных и недостоверного подтверждения успеха.
Например, неподдерживаемый импорт должен завершиться объяснимым отказом до изменения существующих записей. Бесконечная загрузка или частичный импорт без отчёта создают самостоятельный риск. Зафиксируйте, какие гарантии команда действительно предоставляет, чтобы не расширять обязательства случайно.
Как расследовать дефект
Сравните успешное и неуспешное окружения на одинаковых данных и сборке. Меняйте один фактор: версию клиента, ОС, контракт или конфигурацию зависимости. Приложите минимальный пример документа либо очищенный запрос и ответ.
В отчёте укажите точные версии, режим обновления, состояние данных до проверки и фактическую потерю функции. Скриншот без версии компонента редко позволяет повторить несовместимость. Для файлов сохраняйте исходный и полученный экземпляры, иначе доказательства исчезнут после очередного сохранения.
Типичные ошибки и результат работы
Частые ошибки — считать эмуляцию полной заменой устройства, проверять только чистую установку, забывать смешанные версии при развёртывании и сравнивать лишь внешний вид. Не менее опасно менять поддержку без согласованного решения и объявлять обнаруженный дефект «устаревшим окружением».
Результат QA — матрица с обоснованием, проверенные переходы версий, доказательства сохранности данных и список ограничений. Такая запись позволяет осознанно обновлять продукт: команда видит, кого затронет изменение и какой риск остаётся после проверок.