automationstrategy

Матрица в CI: какие версии браузеров и ОС реально тестировать

«Тестируем во всех браузерах и версиях iOS» — звучит хорошо, но в реальности матрица из 50 комбинаций × 200 тестов × 30 сек = десятки часов CI. Это никто не ждёт. Как разумно ограничить покрытие, не теряя реальные баги.

Принцип 80/20

Сколько твоих юзеров используют каждый браузер/версию? Открой analytics (Google Analytics, Amplitude, App Store Connect). Чаще всего:

— 90% юзеров на 2-3 самых популярных конфигурациях. — 9% — на ещё 5-10. — 1% — длинный хвост старых браузеров и редких OS.

Тестируй первые две группы в CI. Третья — спот-проверки руками раз в месяц, или smoke перед релизом.

Web: что брать в CI

Обязательно:

  • Latest Chrome (Windows/Mac/Linux — большая часть юзеров).
  • Latest Safari (Mac + iOS — другой движок, ловит уникальные баги).
  • Latest Firefox (третий движок — на нём WebKit-баги не видны).

Желательно:

  • Mobile Chrome (Android viewport).
  • Mobile Safari (iOS viewport).

По обстоятельствам:

  • Edge — на Chromium, обычно совпадает с Chrome.
  • Старые версии Chrome/Safari (3-6 месяцев назад) — только если в analytics видишь значимый % юзеров.

Не надо: IE (умер в 2022), старые Firefox, мобильные браузеры на «других» движках.

Mobile: версии iOS и Android

iOS — Apple обычно держит 70-80% юзеров на latest major через 6 месяцев после релиза. То есть:

  • Latest iOS на 2-3 моделях iPhone (iPhone 15 Pro, iPhone 13, iPhone SE).
  • Latest-1 (предыдущая major) — пока проникновение latest не достигнет 60%.
  • Старее — спот-проверки.

Android — фрагментация сильнее. Возьми:

  • Latest Android на топ-2 OEM (Samsung, Xiaomi/Google Pixel).
  • Latest-2 (две версии назад) — реальный low-end.
  • Один OEM-specific девайс с проблемами (Xiaomi MIUI с агрессивной battery).

Структура матрицы в CI

# playwright.config.ts
projects: [
  { name: 'chromium-desktop', use: { ...devices['Desktop Chrome'] }, fullyParallel: true },
  { name: 'webkit-desktop', use: { ...devices['Desktop Safari'] }, fullyParallel: true },
  { name: 'mobile-chrome', use: { ...devices['Pixel 7'] } },
  { name: 'mobile-safari', use: { ...devices['iPhone 14'] } },
]

— Smoke (10-20 critical тестов) — на всех проектах, на каждом PR. — Full regression — на 2 проектах (Chrome + Safari), nightly. — Cross-browser regression — на всех 4 проектах, раз в неделю.

Что меняет правила

  • Игра: фокус на target-девайсы. Не нужно тестировать на сотнях моделей, нужно знать «какие самые популярные у наших юзеров».
  • B2B-приложение: возможно есть жёсткие требования контракта типа «работает в IE11». Тестируй IE11. Жалко времени, но контракт есть контракт.
  • Дизайн-критичный продукт: добавь visual regression (см. мой пост) на всех target-конфигурациях.

Чек-лист

✅ Достать аналитику использования — какие браузеры/OS у юзеров реально. ✅ Покрыть 80% юзеров в каждом PR-pipeline. ✅ Полный регресс на 2 движках (Chrome + Safari) — обязательно. WebKit ловит iOS-специфичные баги. ✅ Длинный хвост — спот-проверки или device-farm (BrowserStack, Sauce Labs) перед релизом.

Подробнее: BrowserStack — Browser usage statistics, Playwright Devices.