БЛОК 7. Типы тестирования — 23. Compatibility, Accessibility и Non-functional testing
🧭 Введение: зачем QA знать эти три направления
После базовых типов тестирования (
Functional, UI, Usability) у junior появляется следующий вопрос:
как проверять продукт в реальных условиях, где разные устройства, разные пользователи и разные нагрузки.Здесь как раз нужны три направления:
Compatibility testing — работает ли продукт в разных окружениях,
Accessibility testing — доступен ли продукт для людей с ограничениями,
Non-functional testing — насколько продукт стабилен, безопасен и производителен.💡 Совет:
Думай не только "работает ли фича", но и "для кого, где и под какой нагрузкой она работает".
✅ Вывод:
Эти проверки защищают продукт от проблем, которые не видны в обычном happy path.
⚠️ Проблема -> решение
Проблема:
команда может идеально закрыть функциональные тесты, но релиз все равно падает на реальных пользователях:
в старом браузере кнопка не работает,
клавиатурная навигация ломает поток,
или сервис тормозит под пиковым трафиком.
Решение:
расширить тестовый фокус:
- compatibility — проверяем кросс-окружения;
- accessibility — проверяем доступность и равный доступ;
- non-functional — проверяем качество системы под нагрузкой и рисками.
🟢 Если совсем просто:
Compatibility = где это работает,
Accessibility = кому это доступно,
Non-functional = насколько это надежно в бою.
🎯 Как понять, что этап прошел успешно:
У релиза есть минимальное покрытие по окружениям, доступности и системному качеству, а не только по логике.
🛠️ Чем помогает и как работает
Эта модель нужна, чтобы релиз не "ломался неожиданно" после выкладки.
Она переводит тестирование из уровня "локально ок" в уровень "готово к реальным пользователям".
Как это работает:
- Шаг 1: определяем целевые окружения (браузеры, устройства, ОС).
- Шаг 2: определяем accessibility-базу (клавиатура, фокус, контраст, тексты, семантика).
- Шаг 3: определяем non-functional риски (производительность, устойчивость, безопасность, надежность).
- Шаг 4: добавляем минимальный smoke-набор по каждому направлению в release checklist.
✅ Вывод:
Даже базовый набор этих проверок сильно снижает риск пострелизных инцидентов.
📚 Ключевые термины (простыми словами)
- Compatibility testing — проверка работы в разных браузерах, ОС, устройствах, разрешениях.
- Accessibility testing (A11y) — проверка доступности интерфейса для людей с разными ограничениями.
- Non-functional testing — проверка не "что делает фича", а "как качественно система это делает".
- Performance — скорость отклика, время загрузки, поведение под нагрузкой.
- Reliability — стабильность и предсказуемость системы при длительной работе.
- Security (обзорно) — устойчивость к базовым угрозам и защита данных.
- WCAG — базовые международные рекомендации по доступности веб-интерфейсов.
1. Compatibility testing (совместимость)
Фича может работать у разработчика, но ломаться у части пользователей.
Compatibility помогает проверять продукт в реальных технических комбинациях.
🟢 Если совсем просто:
Compatibility testing отвечает на вопрос: "работает ли это в нужных нам окружениях?"
🎯 Как понять, что этап прошел успешно:
Критичный пользовательский поток подтвержден на согласованной матрице браузеров/устройств.
Назначение:
Снизить риск "у нас работает, у пользователя нет".
Простыми словами:
Проверяем ту же фичу в разных технических условиях.
Для новичка:
Не проверяй "везде подряд". Начни с целевой матрицы: top-браузеры, топ-устройства, важные разрешения.
Пример:
- Login flow на Chrome, Firefox, Safari.
- Mobile checkout на iOS/Android.
- Ключевой экран на desktop и mobile breakpoints.
🔎 Как это происходит на практике:
QA и команда фиксируют поддерживаемые окружения.
Дальше QA выполняет один и тот же критичный поток на выбранной матрице и отмечает отклонения.
Характеристики:
- зависит от продукта и аудитории;
- особенно важен для B2C и мобильных сценариев;
- обычно выполняется как приоритетный кросс-платформенный smoke.
Когда использовать:
Перед релизом и после изменений в UI/JS/адаптиве/браузерных API.
✅ Вывод:
Compatibility testing снижает риск массовых пользовательских поломок.
2. Accessibility testing (доступность)
Доступность — это не "опциональная красота", а качество пользовательского доступа.
Если поток нельзя пройти с клавиатуры или нечитабельный текст, часть пользователей фактически исключается.
🟢 Если совсем просто:
Accessibility testing отвечает на вопрос: "может ли любой пользователь реально пройти поток?"
🎯 Как понять, что этап прошел успешно:
Критичный путь проходится без мыши, фокус видим, ошибки читаемы и понятны.
Назначение:
Обеспечить доступный интерфейс для пользователей с различными ограничениями.
Простыми словами:
Проверяем, что интерфейс не блокирует человека из-за способа взаимодействия.
Для новичка:
Начни с базового минимума:
- keyboard navigation,
- focus visibility,
- alt-тексты для значимых изображений,
- контраст и читаемость ошибок.
Пример:
- В форме логина можно перейти между полями через
Tab. - Фокус всегда виден.
- Ошибка поля читается и объясняет, что исправить.
🔎 Как это происходит на практике:
QA проходит поток без мыши, проверяет фокус и порядок навигации, смотрит тексты и базовую семантику интерфейса.
Характеристики:
- повышает доступность и продуктовую зрелость;
- часто обнаруживает проблемы UX и структуры;
- полезен даже для "обычных" пользователей (понятность, читабельность).
Когда использовать:
На всех ключевых пользовательских потоках: login, registration, checkout, recovery.
✅ Вывод:
Accessibility testing — это про качество доступа и уважение к реальным пользователям.
3. Non-functional testing (обзорно)
Этот блок проверяет не бизнес-логику самой фичи, а системное качество:
скорость, стабильность, надежность, безопасность и поведение под нагрузкой.
🟢 Если совсем просто:
Non-functional testing отвечает на вопрос: "насколько система качественно работает в реальных условиях?"
🎯 Как понять, что этап прошел успешно:
Есть понятные метрики и базовые проверки по ключевым рискам.
Назначение:
Снизить риск деградаций и инцидентов после релиза.
Простыми словами:
Проверяем "как работает система", а не только "что она делает".
Для новичка:
Минимум для старта:
- проверить базовое время ответа критичных API;
- убедиться, что при росте данных экран не "умирает";
- проверить устойчивость к простым сетевым проблемам.
Пример:
- Login API отвечает в рамках целевого SLA.
- Список заказов не зависает на большом объеме.
- Повторный запрос после timeout не приводит к дублированию операции.
🔎 Как это происходит на практике:
Часть проверок делает QA вручную (наблюдение, метрики в DevTools, простые стресс-сценарии), часть — команда автотестов/инфраструктуры.
Характеристики:
- больше про риск и метрики, чем про интерфейс;
- сильно влияет на релизные решения;
- тесно связан с мониторингом и production-наблюдаемостью.
Когда использовать:
На критичных потоках, перед крупными релизами и после значимых архитектурных изменений.
✅ Вывод:
Non-functional testing показывает, выдержит ли система реальную эксплуатацию.
4. Как эти направления сочетаются в одной задаче
В реальной задаче эти проверки не изолированы.
Один и тот же пользовательский поток обычно должен пройти через все три фильтра качества.
🟢 Если совсем просто:
Один поток проверяем с трех сторон: совместимость, доступность, системное качество.
🎯 Как понять, что этап прошел успешно:
По релизному чек-листу видно coverage по всем трем направлениям.
Назначение:
Собрать полную картину рисков для релиза.
Простыми словами:
Не выбираем "или/или" — комбинируем проверки под один критичный user flow.
Для новичка:
Если времени мало, делай минимум в каждом направлении, а не максимум в одном.
Пример:
Фича "оплата":
- Compatibility: checkout на Chrome/Safari + mobile.
- Accessibility: форма оплаты проходит keyboard-only.
- Non-functional: API оплаты держит целевое время отклика и не дублирует транзакции при ретраях.
✅ Вывод:
Комбинация направлений дает реалистичную оценку готовности релиза.
5. Сравнение: Compatibility vs Accessibility vs Non-functional
Эти направления закрывают разные группы рисков.
Таблица помогает junior быстро понять фокус каждого.
🟢 Если совсем просто:
Разные вопросы качества = разные типы проверок.
🎯 Как понять, что этап прошел успешно:
QA может быстро объяснить, какой риск закрывает каждая проверка.
| Направление | Главный вопрос | Что чаще всего ловим |
|---|---|---|
| Compatibility | Работает ли в нужных окружениях? | Поломки в браузерах/устройствах/разрешениях |
| Accessibility | Доступно ли всем пользователям? | Проблемы клавиатуры, фокуса, контраста, семантики |
| Non-functional | Устойчива ли система под реальными условиями? | Медленные ответы, деградация под нагрузкой, нестабильность |
Важное правило:
Один и тот же дефект можно увидеть через разные типы тестирования.
- Compatibility покажет, что баг проявляется только в части окружений.
- Accessibility покажет, что из-за дефекта часть пользователей не может пройти поток.
- Non-functional покажет, что при нагрузке дефект проявляется чаще или критичнее.
Важно:
Не все проблемы в этих направлениях выглядят как "классический баг".
Часть из них — это риск релиза, деградация качества или ограничение для части пользователей.
Даже если логика формально корректна и UI "работает", accessibility или performance могут фактически ломать пользовательский поток.
✅ Вывод:
Сильный QA смотрит на проблему с нескольких сторон, а не из одного чек-листа.
6. Базовый junior-checklist перед релизом
Чтобы не утонуть в объеме, нужен простой минимум.
Ниже минимальный набор, который можно выполнить даже в сжатые сроки.
🟢 Если совсем просто:
Короткий structured-smoke лучше, чем длинный хаотичный прогон.
🎯 Как понять, что этап прошел успешно:
Для каждого направления есть хотя бы 2-3 осмысленные проверки.
Практический минимум:
- Compatibility:
- критичный поток на 2-3 целевых браузерах;
- mobile + desktop проверка ключевого экрана.
- Accessibility:
- keyboard-only проход критичного шага;
- видимый фокус и читаемые ошибки.
- Non-functional:
- базовая проверка времени отклика ключевых API;
- проверка поведения при плохой сети/timeout.
✅ Вывод:
Даже минимальный набор этих проверок резко повышает шанс спокойного релиза.
7. Границы ответственности junior QA
Эти темы могут выглядеть "слишком инженерными", но junior тоже должен в них участвовать.
Важно понимать, что именно ты проверяешь сам, а что эскалируешь в команду.
🟢 Если совсем просто:
Junior закрывает базовый smoke и поднимает риски, команда углубляет сложные части.
🎯 Как понять, что этап прошел успешно:
Ты можешь назвать риск, показать факт и передать его правильному владельцу.
Что обычно делает junior:
- запускает кросс-браузерный минимум;
- проверяет базовую accessibility-навигацию;
- фиксирует перфоманс-симптомы (медленно, timeouts, фризы) и собирает артефакты.
Что обычно углубляет команда:
- расширенные performance/load-тесты;
- security-пентесты;
- глубокие accessibility-аудиты по стандартам и автоматизированным инструментам.
✅ Вывод:
Junior не обязан делать всё, но обязан видеть риски и корректно их эскалировать.
📌 Must-know факты
- Compatibility, Accessibility и Non-functional testing закрывают разные классы рисков.
- Один и тот же поток нужно смотреть с разных сторон качества.
- Accessibility — это часть качества продукта, а не "дополнение по желанию".
- Non-functional проблемы часто проявляются только под реальными условиями.
- Базовый release-smoke по этим направлениям обязателен для критичных фич.
❗ Частые мифы
❌ Миф: Если тесты логики прошли, значит релиз безопасен.
✅ Как правильно: Логика — только часть качества; нужны проверки окружений, доступности и системной устойчивости.
📎 Почему это важно: Иначе проблемы всплывут уже на реальных пользователях.
❌ Миф: Accessibility нужна только для "особых" продуктов.
✅ Как правильно: Базовая доступность нужна любому интерфейсу с пользователями.
📎 Почему это важно: Это влияет на реальный доступ к продукту и на UX в целом.
❌ Миф: Non-functional = только нагрузочное тестирование.
✅ Как правильно: Это шире: производительность, надежность, стабильность, базовая безопасность.
📎 Почему это важно: Ошибки в этих зонах часто самые дорогие после релиза.
❌ Миф: Compatibility можно проверить "на одном браузере".
✅ Как правильно: Проверяем минимум на согласованной матрице целевых окружений.
📎 Почему это важно: Пользовательская аудитория почти всегда технически неоднородна.
💬 Часто спрашивают на собеседованиях
❓ Вопрос: Чем compatibility testing отличается от UI testing?
✅ Ответ: UI testing проверяет поведение интерфейса в одном окружении, compatibility — устойчивость того же поведения в разных окружениях.
❓ Вопрос: Что такое accessibility testing для junior на практике?
✅ Ответ: Минимум — keyboard navigation, видимый фокус, читаемые ошибки, базовая проверка контраста и понятности текста.
❓ Вопрос: Что означает non-functional testing в ручном тестировании?
✅ Ответ: Это проверка качества работы системы (скорость, стабильность, надежность) базовыми ручными сценариями и метриками.
❓ Вопрос: Нужно ли делать эти проверки в каждой задаче?
✅ Ответ: Глубина зависит от риска, но для критичных потоков минимум по этим направлениям обязателен.
❓ Вопрос: Как junior выбрать приоритет между этими проверками?
✅ Ответ: Сначала критичный user flow, затем минимальный coverage по compatibility, accessibility и non-functional рискам.
🚨 Типичные ошибки
Ошибка 1: Проверять только "свой" браузер
Почему это ошибка:
Дефекты совместимости остаются невидимыми до релиза.
Как исправить:
Используй согласованную матрицу браузеров/устройств и закрывай хотя бы smoke.
Ошибка 2: Игнорировать клавиатурную навигацию
Почему это ошибка:
Часть пользователей не сможет пройти ключевой поток.
Как исправить:
Добавь keyboard-only прогон в обязательный чек-лист.
Ошибка 3: Считать медленный отклик "не багом"
Почему это ошибка:
Деградация производительности напрямую влияет на конверсию и SLA.
Как исправить:
Фиксируй метрики и симптомы в баге, указывай условия воспроизведения.
Ошибка 4: Не собирать артефакты для non-functional проблем
Почему это ошибка:
Без данных команде сложно повторить и диагностировать проблему.
Как исправить:
Прикладывай время, окружение, сеть, видео/логи/скриншоты и шаги.
✅ Best Practices
- Держи отдельный release-checklist: Compatibility / Accessibility / Non-functional.
- Для каждого критичного user flow закрывай минимум по всем трем направлениям.
- Всегда фиксируй матрицу окружений до начала теста.
- Эскалируй риски фактами: метрики, шаги, артефакты.
- Если нет времени на глубину, делай короткий, но обязательный smoke.
🏁 Заключение
Compatibility, Accessibility и Non-functional testing — это шаг от "проверил фичу" к "проверил готовность продукта к реальному миру".
Для junior это важный переход: ты начинаешь видеть не только логику экрана, но и устойчивость релиза для разных пользователей и условий.
Следующая цель после этой темы — научиться выбирать глубину этих проверок по риску и контексту релиза.