Верификация и валидация
Updated Jul 2026
Эти два термина часто путают, даже опытные инженеры. Понимание различия между ними является фундаментальным для мышления QA — оно определяет, как вы подходите к тестированию, какие вопросы задаёте и какие типы дефектов ищете.
Ключевое различие
| Аспект | Верификация | Валидация |
|---|---|---|
| На какой вопрос отвечает | «Правильно ли мы строим продукт?» | «Правильный ли продукт мы строим?» |
| Фокус | Соответствие спецификации | Соответствие потребностям пользователей |
| Время проведения | Во время разработки (ревью, инспекции, модульные тесты) | После сборки (UAT, бета-тестирование, юзабилити-тестирование) |
| Подход | Статический и динамический анализ по спецификациям | Пользовательское тестирование, приёмочное тестирование, использование в реальных условиях |
| Кто выполняет | Разработчики, QA-инженеры, рецензенты | Конечные пользователи, владельцы продукта, бета-тестеры |
Классический пример
Команда разработки создаёт систему входа. Они точно следуют спецификации:
- Поле email принимает корректный формат email
- Пароль должен быть не менее 8 символов
- Успешный вход перенаправляет на /dashboard
- Неудачный вход показывает сообщение об ошибке
Верификация подтверждает: да, код реализует спецификацию корректно. Все модульные тесты проходят. Код-ревью не выявило проблем. Страница входа ведёт себя точно по спецификации.
Валидация выявляет: пользователи ожидали входа по номеру телефона, а не по email. Спецификация никогда не упоминала вход по телефону, потому что владелец продукта считал email очевидным. Продукт проходит верификацию, но не проходит валидацию.
Действия по верификации
Верификация проверяет, соответствует ли реализация спецификации. Это преимущественно внутренняя активность.
Статическая верификация (без выполнения кода)
| Активность | Что выявляет |
|---|---|
| Код-ревью | Логические ошибки, пропущенные крайние случаи, нарушения стиля |
| Ревью требований | Неоднозначность, противоречия, отсутствующие критерии приёмки |
| Ревью дизайна | Архитектурные проблемы, вопросы масштабируемости, пробелы в безопасности |
| Обзор спецификации | Непонимание между продуктом и разработкой |
| Инструменты статического анализа | Code smells, потенциальные null-ссылки, неиспользуемые переменные |
Динамическая верификация (с выполнением кода)
| Активность | Что выявляет |
|---|---|
| Модульные тесты | Корректность отдельных функций/методов |
| Интеграционные тесты | Проблемы взаимодействия компонентов |
| Регрессионные тесты | Повторное появление ранее исправленных багов |
| Контрактные тесты | Соответствие структуры ответа API задокументированной схеме |
| Линтинг и проверка типов | Несоответствие типов, неопределённые переменные |
Верификация на практике
Когда вы пишете тест-кейс, который гласит «Given a user with valid credentials, When they submit the login form, Then they are redirected to /dashboard» — вы выполняете верификацию. Вы проверяете, что программа делает то, что спецификация предписывает.
Действия по валидации
Валидация проверяет, удовлетворяет ли продукт реальные потребности пользователей. Она выходит за рамки спецификации и задаёт вопрос: «Решает ли это проблему пользователя?»
Типичные действия по валидации
| Активность | Что выявляет |
|---|---|
| Пользовательское приёмочное тестирование (UAT) | Соответствует ли функция бизнес-требованиям с точки зрения пользователя? |
| Бета-тестирование | Как реальные пользователи взаимодействуют с функцией в реальных условиях? |
| Юзабилити-тестирование | Могут ли пользователи достичь своих целей эффективно и без замешательства? |
| A/B-тестирование | Какая реализация лучше достигает бизнес-цели? |
| Обратная связь от клиентов | Пострелизная валидация того, решает ли функция реальные проблемы |
| Анализ аналитики | Используют ли пользователи функцию на самом деле? Где они уходят? |
Валидация на практике
QA-инженер, участвующий в валидации, задаёт другие вопросы, чем тот, кто сосредоточен на верификации:
Вопрос верификации: «Корректно ли процесс оформления обрабатывает международные адреса?»
Вопрос валидации: «Достаточно ли прост процесс оформления, чтобы пользователи завершали покупки, не бросая корзину?»
Вопрос верификации: «Возвращает ли поиск результаты, соответствующие запросу?»
Вопрос валидации: «Возвращает ли поиск результаты, которые пользователи действительно считают полезными?»
Почему важны оба
Продукт может пройти все проверки верификации и всё равно не пройти валидацию. Это случается часто:
Сценарий 1: Функция, которой никто не пользуется
Команда создаёт сложный дашборд с отчётами из 50 графиков. Каждый график отрисовывается корректно (верификация пройдена). Но пользователям нужны только 3 из этих графиков, а интерфейс настолько перегружен, что они не могут их найти (валидация не пройдена).
Сценарий 2: Корректно, но непонятно
Сообщение об ошибке «Authentication failed: INVALID_CREDENTIALS_401» технически точное (верификация пройдена). Но пользователи не понимают, что это значит и что делать дальше (валидация не пройдена). «Неверный email или пароль. Попробуйте снова или сбросьте пароль.» прошло бы обе проверки.
Сценарий 3: Спецификация была ошибочной
Спецификация говорит «отображать цены в USD». Реализация корректно показывает цены в USD (верификация пройдена). Но продукт запускается в Европе, и пользователи ожидают EUR (валидация не пройдена — сама спецификация была ошибочной).
Роль QA в обоих процессах
Роль в верификации
- Написание и выполнение тест-кейсов по спецификациям
- Сообщение о дефектах, когда поведение отклоняется от спецификаций
- Поддержка регрессионных тест-сьютов
- Участие в ревью кода и дизайна
Роль в валидации
- Участие в сессиях UAT с реальными пользователями
- Предоставление обратной связи по юзабилити на основе опыта тестирования
- Постановка вопросов о требованиях, которые кажутся запутанными или неполными
- Сообщение наблюдений «это работает корректно, но кажется неправильным»
- Защита интересов конечного пользователя, когда спецификация неоднозначна
Подход Shift-Left
Современные QA-инженеры участвуют в валидации на более ранних этапах процесса:
- Во время уточнения требований: «Это требование гласит X, но пользователи могут ожидать Y»
- Во время ревью дизайна: «Этот сценарий содержит 7 шагов — можем ли мы сократить до 3?»
- Во время планирования спринта: «Мы говорили с пользователями о том, нужна ли им эта функция?»
Верификация и валидация в различных методологиях
| Методология | Акцент на верификацию | Акцент на валидацию |
|---|---|---|
| Waterfall | Значительный (фаза тестирования по детальным спецификациям) | Поздний (UAT в конце, изменения дорого обходятся) |
| Agile | Непрерывный (автоматизированные тесты, CI/CD) | Частый (демо спринта, обратная связь от пользователей на каждой итерации) |
| DevOps | Автоматизированный (гейты пайплайна, проверки качества) | Непрерывный (feature flags, канареечные релизы, мониторинг) |
| Lean/Startup | Минимальный (достаточно, чтобы ничего не сломать) | Основной фокус (валидированное обучение, тестирование MVP) |
Связанные концепции
Альфа- и бета-тестирование
- Альфа-тестирование: внутренняя валидация командой QA или внутренними пользователями до внешнего релиза
- Бета-тестирование: внешняя валидация реальными пользователями в окружении, близком к production
V-модель
V-модель явно сопоставляет действия верификации и валидации с фазами разработки:
Requirements ──────────────────── Acceptance Testing (Validation)
System Design ──────────────── System Testing (Verification)
Architecture ─────────────── Integration Testing (Verification)
Coding ─────────────────── Unit Testing (Verification)
Каждый уровень слева (разработка) имеет соответствующий уровень тестирования справа. Верификация доминирует на нижних уровнях; валидация доминирует на верхнем.
Практическое упражнение
Для следующих функций напишите один тест верификации и один тест валидации:
- Уведомления по email: система отправляет email при отправке заказа
- Автодополнение поиска: строка поиска предлагает результаты по мере ввода
- Онбординг пользователей: пошаговый мастер из 5 шагов проводит новых пользователей через настройку аккаунта
Для каждого подумайте: что могло бы пройти верификацию, но не пройти валидацию?
Ключевые выводы
- Верификация: «Правильно строим продукт» — соответствует ли он спецификации?
- Валидация: «Строим правильный продукт» — удовлетворяет ли он потребности пользователей?
- Продукт может пройти верификацию и не пройти валидацию
- QA-инженеры должны участвовать в обоих процессах — проверяя спецификации И защищая интересы пользователей
- Современный QA сдвигает валидацию влево: задавайте вопросы о требованиях рано, не ждите до UAT
Тезис для собеседования: «Я отношусь к ручному тестированию как к мыслительной дисциплине, а не задаче, которую можно автоматизировать. Я использую сессионное исследовательское тестирование с хартиями и тайм-боксами для систематического поиска проблем, которые пропускают скриптовые тесты. Когда я оформляю баг, я включаю минимальное воспроизведение, детали окружения и чёткое разделение серьёзности и приоритета — потому что баг-репорт, который разработчик может воспроизвести менее чем за две минуты, исправляется за часы, а не за недели. Я также разделяю верификацию и валидацию — я тестирую по спецификациям, но также задаю вопрос, служит ли сама спецификация интересам пользователя.»