БЛОК 7. Типы тестирования — 22. Основные типы тестирования
🧭 Введение: зачем QA знать типы тестирования
Когда junior QA открывает новую задачу, первый вопрос обычно не "какой баг искать", а "что именно здесь нужно проверить".
Если не разделять типы тестирования, легко попасть в хаос: много кликов, мало пользы, важные риски остаются без проверки.
В этой теме мы разбираем три базовых типа, с которых начинается реальная работа manual QA:
Functional testing, UI testing и Usability testing.💡 Совет:
Сначала выбери тип проверки, потом пиши сценарии.
Так ты быстрее поймешь, зачем делаешь каждую проверку.
✅ Вывод:
Тип тестирования — это фильтр мышления QA: он помогает проверять системно, а не случайно.
⚠️ Проблема -> решение
Проблема:
начинающие QA часто смешивают все проверки в один список.
В результате тесты становятся "длинными, но слепыми": что-то проверено слишком глубоко, а критичные вещи пропущены.
Решение:
делить проверку на три уровня:
Functional — логика и бизнес-правила,
UI — поведение интерфейса на экране,
Usability — удобство и понятность для пользователя.🟢 Если совсем просто:
Functional = работает правильно,
UI = отображается и ведет себя правильно,
Usability = пользоваться удобно и понятно.
🎯 Как понять, что этап прошел успешно:
По каждой задаче видно, какие проверки относятся к логике, какие к интерфейсу, а какие к удобству.
🛠️ Чем помогает и как работает
Эта модель нужна, чтобы не тратить время на "проверил всё подряд".
Она дает структуру: сначала критичная логика, потом визуальное поведение, потом качество пользовательского опыта.
Как это работает:
- Шаг 1: определяем, что является бизнес-функцией (functional scope).
- Шаг 2: определяем, что пользователь видит и с чем взаимодействует (UI scope).
- Шаг 3: определяем, где пользователь может запутаться или ошибиться (usability scope).
- Шаг 4: собираем тесты с приоритетом: сначала критичные функциональные, затем UI, затем usability.
✅ Вывод:
Разделение на типы тестирования делает покрытие точнее и помогает быстрее находить реальные риски.
📚 Ключевые термины (простыми словами)
- Functional testing — проверка логики и бизнес-правил фичи.
- UI testing — проверка элементов интерфейса, их состояний и переходов.
- Usability testing — проверка, насколько интерфейс понятен и удобен человеку.
- Validation — проверка корректности данных/формата.
- User flow — последовательность шагов пользователя к цели.
1. Functional testing (функциональное тестирование)
Это первый и обязательный уровень для QA.
Если бизнес-правило не работает, красивый интерфейс уже не спасает фичу.
🟢 Если совсем просто:
Functional testing отвечает на вопрос: "фича делает то, что должна делать?"
🎯 Как понять, что этап прошел успешно:
Ключевые бизнес-правила подтверждены: корректные данные проходят, некорректные отклоняются.
Назначение:
Проверить соответствие поведения системы требованиям и acceptance criteria.
Простыми словами:
Проверяем не "как выглядит", а "правильно ли работает".
Для новичка:
Всегда начинай с functional-проверок, особенно если есть деньги, доступы или критичные действия.
Пример:
- Регистрация с валидными данными создает пользователя.
- Невалидный email отклоняется.
- Дубликат email не проходит.
🔎 Как это происходит на практике:
QA берет AC, делает happy path, затем negative и boundary-проверки.
В конце сравнивает фактическое поведение с ожидаемым по требованиям.
Характеристики:
- зависит от бизнес-логики;
- чаще всего приоритет №1 перед релизом;
- хорошо воспроизводится через тест-кейсы.
Когда использовать:
Всегда, в каждой задаче, где есть логика, правила, статусы, ограничения.
✅ Вывод:
Functional testing — фундамент: без него нельзя говорить о качестве фичи.
2. UI testing (интерфейсное тестирование)
После логики важно проверить, как фича ведет себя на экране.
Даже корректная логика бесполезна, если кнопка недоступна или ошибка отображается непонятно.
🟢 Если совсем просто:
UI testing отвечает на вопрос: "интерфейс отображается и реагирует корректно?"
🎯 Как понять, что этап прошел успешно:
Поля, кнопки, сообщения, состояния и переходы ведут себя ожидаемо.
Назначение:
Проверить визуальное и интерактивное поведение экрана.
Простыми словами:
Проверяем, что пользователь видит правильные элементы в правильный момент.
Для новичка:
Не ограничивайся "красиво/некрасиво": проверяй состояния
disabled/loading/error/success.Пример:
- Кнопка
Submitнеактивна, пока обязательные поля пустые. - После отправки формы показывается
loading. - При ошибке API отображается понятное сообщение.
🔎 Как это происходит на практике:
QA прогоняет основные пользовательские шаги и наблюдает, что интерфейс явно показывает пользователю, что происходит.
Характеристики:
- фокус на экране и состояниях;
- тесно связан с UX и дизайн-макетами;
- часто выявляет проблемы до того, как пользователь упирается в баг.
Когда использовать:
В любой задаче с формами, экранами, кнопками, модальными окнами, таблицами.
✅ Вывод:
UI testing проверяет, может ли пользователь реально дойти до результата.
3. Usability testing (проверка удобства)
Даже при правильной логике и корректном UI пользователь может путаться и ошибаться.
Usability помогает найти такие проблемы раньше, чем они превращаются в отток пользователей и поддержку "почему не получается".
🟢 Если совсем просто:
Usability testing отвечает на вопрос: "пользователю понятно и удобно выполнять задачу?"
🎯 Как понять, что этап прошел успешно:
Пользовательский поток интуитивный: цель достигается без лишних шагов и непонятных решений.
Назначение:
Проверить ясность, удобство и предсказуемость пользовательского опыта.
Простыми словами:
Проверяем, не заставляет ли интерфейс пользователя "догадываться".
Для новичка:
Задавай себе вопрос: "если бы я видел это впервые, понял бы что делать дальше?"
Пример:
- Текст ошибки объясняет, как исправить ввод.
- Важная кнопка заметна и логично названа.
- Критичные действия требуют явного подтверждения.
🔎 Как это происходит на практике:
QA проходит поток глазами нового пользователя и отмечает точки, где можно ошибиться, запутаться или потерять контекст.
Характеристики:
- фокус на реальном поведении пользователя;
- часто не про "баг", а про риск плохого опыта;
- влияет на конверсию и удовлетворенность.
Когда использовать:
На ключевых пользовательских потоках: регистрация, оплата, восстановление доступа, onboarding.
✅ Вывод:
Usability testing уменьшает количество "формально работает, но пользоваться тяжело".
4. Как комбинировать типы в одной задаче
В реальной задаче почти всегда нужны все три типа.
Сильный QA не выбирает "только один", а понимает порядок и глубину проверок.
🟢 Если совсем просто:
Сначала functional, затем UI, затем usability.
🎯 Как понять, что этап прошел успешно:
В тестах нет перекоса: проверены логика, интерфейс и удобство, но без избыточности.
Назначение:
Собрать цельное покрытие по задаче, а не разрозненные проверки.
Простыми словами:
Одна фича = несколько видов проверки с разной целью.
Для новичка:
Если времени мало, урезай глубину, но не выкидывай тип полностью.
Пример:
Фича "логин":
- Functional: валидный/невалидный логин, блокировка после N попыток.
- UI: состояние кнопки и поля, отображение ошибок.
- Usability: понятно ли сообщение, что делать после ошибки.
✅ Вывод:
Комбинация типов тестирования дает баланс между корректностью, стабильностью и удобством.
5. Сравнение: Functional vs UI vs Usability
Эти типы не конкурируют, а дополняют друг друга.
Сравнение помогает junior быстро выбрать правильный фокус проверки.
🟢 Если совсем просто:
Разные типы отвечают на разные вопросы качества.
🎯 Как понять, что этап прошел успешно:
QA может объяснить, какой тип тестирования закрывает какой риск.
| Тип | Главный вопрос | Что чаще всего ломается |
|---|---|---|
| Functional | Работает ли логика по требованиям? | Валидация, статусы, бизнес-правила |
| UI | Корректно ли ведет себя интерфейс? | Состояния полей, кнопок, отображение ошибок |
| Usability | Удобно и понятно ли пользователю? | Неясные тексты, лишние шаги, запутанный flow |
Важное правило:
Один и тот же экран можно проверять разными типами тестирования, потому что они смотрят на него с разных сторон:
- Functional — правильно ли работает логика.
- UI — правильно ли это показано пользователю.
- Usability — понятно ли пользователю, что делать.
✅ Вывод:
Хорошее покрытие строится на сочетании всех трех типов, а не на одном "любимом".
6. Как выбрать глубину проверки (для junior)
На практике времени всегда ограничено.
Нужно уметь решать, где проверять глубже, а где достаточно базового уровня.
🟢 Если совсем просто:
Чем выше риск для бизнеса и пользователя, тем глубже проверка.
🎯 Как понять, что этап прошел успешно:
Приоритет тестов совпадает с приоритетом рисков, а не с "что первое пришло в голову".
Практическое правило:
- Критичные потоки (деньги, доступ, безопасность): deep functional + обязательный UI + usability.
- Средний риск: основной functional + ключевые UI состояния + короткий usability sanity.
- Низкий риск: smoke functional + базовый UI.
✅ Вывод:
Глубина тестирования должна зависеть от риска, а не от привычки.
7. Частая ошибка новичка: все считать "просто UI"
У junior часто встречается перекос: любую проверку считают интерфейсной.
Это приводит к тому, что бизнес-правила проверяются поверхностно.
🟢 Если совсем просто:
Если вопрос про правило системы — это functional.
Если вопрос про отображение — это UI.
Если вопрос про понятность и удобство — это usability.
🎯 Как понять, что этап прошел успешно:
Каждый найденный дефект QA может отнести к правильному типу проверки.
✅ Вывод:
Правильная классификация проверок повышает точность тестирования и качество отчетов.
📌 Must-know факты
Functional,UIиUsabilityпокрывают разные риски и должны использоваться вместе.- Functional обычно идет первым, потому что проверяет бизнес-ядро.
- UI без functional дает ложное чувство качества.
- Usability важен даже когда "формально всё работает".
- Один и тот же экран можно и нужно проверять разными типами тестирования.
❗ Частые мифы
❌ Миф: Если фича визуально работает, значит все ок.
✅ Как правильно: Визуальная корректность не гарантирует корректность бизнес-логики.
📎 Почему это важно: Иначе критичные functional-дефекты уходят в релиз.
❌ Миф: Usability — это только работа дизайнера.
✅ Как правильно: QA тоже проверяет, насколько поток понятен и не провоцирует ошибки.
📎 Почему это важно: Плохая понятность интерфейса — частый источник продуктовых проблем.
❌ Миф: Для junior достаточно только UI-проверок.
✅ Как правильно: Junior обязан уметь делать минимум по всем базовым типам.
📎 Почему это важно: Это основа роста до strong junior.
❌ Миф: Тип тестирования нужно выбрать один раз на задачу.
✅ Как правильно: В одной задаче обычно сочетают несколько типов с разной глубиной.
📎 Почему это важно: Так покрытие становится полным и практичным.
💬 Часто спрашивают на собеседованиях
❓ Вопрос: Чем functional testing отличается от UI testing?
✅ Ответ: Functional проверяет бизнес-логику и правила, UI проверяет экранные элементы и их поведение.
❓ Вопрос: Можно ли пропустить usability, если все работает по требованиям?
✅ Ответ: Нежелательно, потому что формально рабочий поток может быть непонятным и неудобным для пользователя.
❓ Вопрос: Что проверять первым делом в новой задаче?
✅ Ответ: Сначала functional-логику, затем UI-состояния, затем usability-аспекты.
❓ Вопрос: Почему один и тот же баг можно найти разными типами тестирования?
✅ Ответ: Потому что баг может одновременно затрагивать логику, отображение и пользовательский опыт.
❓ Вопрос: Какие типы тестирования must-have для junior QA?
✅ Ответ: Базовый functional, базовый UI и базовый usability на ключевых потоках.
🚨 Типичные ошибки
Ошибка 1: Проверять только happy path
Почему это ошибка:
Фича выглядит рабочей, но реальные сбои проявляются на невалидных данных и исключениях.
Как исправить:
После happy path обязательно добавляй негативные сценарии.
Ошибка 2: Считать все проверки UI-проверками
Почему это ошибка:
Теряется фокус на бизнес-логике и валидации.
Как исправить:
Перед тестом явно подпиши тип проверки рядом со сценарием.
Ошибка 3: Игнорировать usability
Почему это ошибка:
Пользователь может не понимать интерфейс даже при корректной логике.
Как исправить:
Добавляй минимум 2-3 usability-проверки в критичных user flow.
Ошибка 4: Делать одинаковую глубину везде
Почему это ошибка:
Время уходит на низкорисковые зоны, а важные места недопроверены.
Как исправить:
Приоритизируй глубину тестов по риску и влиянию.
✅ Best Practices
- Всегда стартуй с вопроса: "какой риск я сейчас проверяю?"
- Держи в чек-листе три колонки:
Functional / UI / Usability. - В тест-кейсах явно разделяй проверки по типам.
- Для критичных потоков всегда делай три уровня проверки.
- Если времени мало, сокращай глубину, но не выбрасывай целый тип тестирования.
🏁 Заключение
Основные типы тестирования — это рабочий каркас manual QA.
Когда ты уверенно разделяешь
Functional, UI и Usability, качество проверки растет сразу: меньше пропусков, меньше хаоса, понятнее отчеты для команды.Следующий шаг после этой темы — расширенные типы: совместимость, доступность и non-functional-фокус.