Функция поиска которая возвращает результаты за 3 секунды проходит верификацию: требование выполнено. Но проваливает валидацию: пользователи сравнивают с 0,3 секунды Google и считают это неприемлемо медленным, хотя в спецификации об этом ни слова. Статья разбирает разницу между двумя понятиями, к какому виду относится каждый вид тестовой деятельности и почему поиск только ошибок верификации оставляет целую категорию дефектов нетронутой.
Короткие определения
Верификация проверяет соответствие продукта его спецификациям. Совпадает ли то что построено с тем что было задокументировано, спроектировано и согласовано?
Валидация проверяет соответствие продукта реальным потребностям пользователей. Решает ли продукт ту настоящую проблему для которой был создан?
Продукт может пройти верификацию и провалить валидацию: работает точно по спецификации, но сама спецификация была неверной: продукт не делает того что пользователям реально нужно.
Возможна и обратная ситуация: продукт проходит валидацию, но проваливает верификацию: пользователям нравится и всё работает, но есть недокументированные фичи, дыры в безопасности или поведение расходящееся со спецификацией.
Верификация: соответствует ли спецификации
Деятельность по верификации обычно проводится без запуска программного обеспечения. Вопрос: совпадает ли то что построено с тем что было согласовано?
Как выглядит верификация
Ревью документов
Охватывает ли документ требований все согласованные фичи? Согласован ли дизайн-спек с требованиями? Покрывают ли тест-кейсы все требования?
Code review
Реализует ли код то что описано в дизайн-документе? Соблюдены ли паттерны безопасности из стандартов кодирования?
Инспекция
Совместный просмотр требований, дизайна и реализации: всё согласуется?
Ревью прототипа/вайрфрейма
Соответствует ли UI-вайрфрейм согласованным пользовательским историям?
Цель
Найти дефекты в документах и дизайне до того как программное обеспечение построено или протестировано. Исправить неверное требование на бумаге дешевле чем после трёх спринтов разработки.
Валидация: решает ли реальную проблему
Валидация проводится через запуск программного обеспечения, обычно через реальное тестирование. Вопрос: работает ли этот продукт для людей для которых он создан?
Как выглядит валидация
Пользовательское приёмочное тестирование (UAT)
Реальные пользователи или стейкхолдеры тестируют продукт в рамках своих реальных рабочих процессов. Вопрос: «Это делает то что мне нужно?»
Системное тестирование
Тестирование полной интегрированной системы против требований и против пользовательских целей. Вся система реально работает end-to-end для реалистичных сценариев использования?
Бета-тестирование
Подмножество реальных пользователей использует продукт в своей реальной среде. Выявляет пробелы которые тестирование по спецификации пропустило, потому что спек не отразил реальное использование.
Юзабилити-тестирование
Могут ли пользователи реально достичь своих целей через этот интерфейс? Даже если технически корректен: удобен ли он в использовании?
Цель
Подтвердить что программное обеспечение создаёт реальную ценность. Фича может быть технически правильной и при этом абсолютно бесполезной.
Конкретный пример
Допустим требование:
«Поле поиска должно возвращать результаты в течение 3 секунд.»
Вопрос верификации: соответствует ли реализация этому требованию? Тестируем: запускаем поиск, измеряем время, подтверждаем что меньше 3 секунд. Прошло.
Вопрос валидации: решает ли это реальную проблему пользователя? Обнаруживаем: пользователи ищут по огромным каталогам товаров, и 3 секунды воспринимаются как неприемлемо долго когда Google возвращает результаты за 0,3 секунды. Даже несмотря на то что спек говорил 3 секунды и код выполняет это условие, валидация проваливается.
Спецификация была неверной. Верификация ничего не поймала. Валидация поймала всё.
Именно поэтому нельзя полагаться только на верификацию: спецификация настолько хороша, насколько хороши люди которые её писали.
Ещё один пример: валидация формы
Требование: «Поле пароля не должно принимать менее 8 символов.»
Верификация: тестируем что пароль из 7 символов отклоняется. Отклоняется.
Валидация: реальный пользователь пытается использовать свой обычный 6-символьный пароль, получает отказ, пробует создать новый 8-символьный, но сообщение об ошибке говорит просто «Invalid input» без объяснений. Он сдаётся и не регистрируется. Валидация провалена: продукт не помогает пользователю достичь цели: зарегистрироваться.
Код был правильным. Требование было слишком узким. Оно не учло пользовательский опыт при получении сообщения об ошибке.
Как это выглядит в жизненном цикле разработки
| Фаза | Активность | Верификация или валидация? |
|---|---|---|
| Требования | Ревью требований: проверка полноты и согласованности | Верификация |
| Дизайн | Walkthrough дизайна: проверка соответствия дизайна требованиям | Верификация |
| Разработка | Code review: проверка соответствия кода дизайну | Верификация |
| Тестирование | Юнит-тесты: проверка работы компонентов по спецификации | Верификация |
| Тестирование | Интеграционные тесты: проверка совместной работы модулей | Верификация |
| Тестирование | Системные тесты: проверка полной системы на соответствие требованиям | Оба |
| Тестирование | UAT: проверка что реальные пользователи достигают реальных целей | Валидация |
| Релиз | Бета-тестирование: использование в реальном мире | Валидация |
В ежедневной работе QA-инженер сочетает оба вида: запускаешь тесты против требований (верификация) и одновременно думаешь работает ли фича для реальных пользователей (валидация).
Почему это различие важно
Баги из ошибок верификации: реализация не совпадает со спецификацией. Кнопка делает не то что говорит требование. Расчёт неверен. Поле принимает значения которые не должно принимать.
Баги из ошибок валидации: спецификация была неполной или неверной. Фича работает согласно дизайну, но проваливается в реальных пользовательских сценариях. Отсутствующие сообщения об ошибках, запутанные флоу, производительность которая технически приемлема но практически ужасна.
Хороший QA ловит и то и другое. Чистое выполнение тестов по спецификации ловит ошибки верификации. Исследовательское тестирование, ревью юзабилити и UAT ловят ошибки валидации.
Версия для интервью
Если это спрашивают на интервью:
Верификация = «Правильно ли мы строим продукт?» Соответствие спецификациям, обычно статическое (ревью, walkthrough-ы) или раннее тестирование против задокументированных требований.
Валидация = «Правильный ли продукт мы строим?» Подтверждение что продукт удовлетворяет потребностям пользователей, обычно через запуск программного обеспечения в реалистичных условиях (UAT, бета-тестирование, юзабилити-тестирование).
Классическая аналогия: карта может быть точной (верификация: она правильно изображает местность) но бесполезной (валидация: она показывает не то направление). Нужна и правильная карта, и правильный пункт назначения.
Оба понятия относятся к работе каждого QA-инженера, даже если эти термины никогда не используются явно. Когда проверяешь «совпадает ли это с требованием», делаешь верификацию. Когда спрашиваешь «реально ли это работает для пользователя», делаешь валидацию. Лучшие тестировщики держат оба вопроса в голове одновременно.
→ См. также: Тестирование чёрного и белого ящика: чёткое руководство для QA-инженеров | Приёмочное тестирование: что это, кто делает и как | Что такое ручное тестирование: полное руководство для 2026 года