Два вопроса, определяющих качество
В тестировании ПО две фундаментальных вопроса формируют всё, что мы делаем:
- Мы создаём продукт правильно? (Верификация)
- Мы создаём правильный продукт? (Валидация)
Эти два вопроса — известные как Верификация и Валидация, или V&V — представляют две принципиально разные перспективы на качество. Понимание их различий необходимо каждому тестировщику, потому что их смешение приводит к созданию отполированного ПО, которое никому не нужно, или полезного ПО, полного дефектов.
Верификация: мы создаём продукт правильно?
Верификация — это процесс оценки того, соответствует ли продукт, компонент или система своим спецификациям, требованиям и проектной документации. Она проверяет соответствие определённым правилам и стандартам.
Думайте о верификации как о внутренней проверке качества. У вас есть чертёж, и вы проверяете, соответствует ли постройка этому чертежу. Сам чертёж может быть неправильным — но это не забота верификации.
Активности верификации
- Ревью требований: Каждое требование соответствует стандартному шаблону? Тестируемо ли оно? Есть ли противоречия?
- Ревью дизайна: Архитектура соответствует требованиям? Паттерны проектирования применены правильно?
- Code review: Код следует стандартам кодирования? Соблюдаются ли соглашения об именовании? Реализована ли обработка ошибок?
- Unit-тестирование: Каждая функция возвращает ожидаемый результат для заданных входных данных?
- Статический анализ: Есть ли в коде потенциальные NullPointerException, утечки памяти или уязвимости безопасности?
- Walkthroughs и инспекции: Коллеги подтверждают, что артефакт соответствует его спецификации?
Пример верификации
Требование: «Форма логина должна принимать email-адреса длиной до 254 символов.»
Проверки верификации:
- Поле email принимает 254 символа? (Граничное тестирование)
- Отклоняет ли 255 символов? (Граничное тестирование)
- Столбец в базе данных допускает 254 символа? (Ревью схемы)
- API валидирует длину email на стороне сервера? (Code review)
- Появляется ли сообщение об ошибке при превышении лимита? (Функциональное тестирование)
Все эти проверки верифицируют, соответствует ли реализация спецификации. Ни одна из них не ставит под вопрос, правильный ли лимит 254 символа или нужны ли пользователям такие длинные email-адреса.
Валидация: мы создаём правильный продукт?
Валидация — это процесс оценки того, удовлетворяет ли продукт потребностям и ожиданиям пользователей и заинтересованных сторон. Она проверяет, решает ли ПО реальную проблему, для которой оно предназначалось.
Думайте о валидации как о внешней проверке качества. Вы сравниваете не с документом, а с реальностью. Действительно ли это ПО помогает реальным людям выполнять реальные задачи?
Активности валидации
- Приёмочное тестирование (UAT): Реальные пользователи тестируют продукт в своих рабочих процессах
- Бета-тестирование: Более широкая группа пользователей оценивает продукт перед общим выпуском
- Юзабилити-тестирование: Наблюдение за взаимодействием пользователей с ПО для выявления точек трения
- A/B-тестирование: Сравнение разных реализаций для определения, какая лучше достигает целей пользователя
- Ревью прототипов: Пользователи оценивают макеты до начала разработки
- Демо стейкхолдерам: Владельцы продукта подтверждают, что реализованная функция соответствует их видению
Пример валидации
Та же форма логина, перспектива валидации:
- Пользователи предпочитают входить по email или по номеру телефона?
- Чекбокс «Запомнить меня» действительно полезен, или пользователи ожидают, что останутся залогиненными по умолчанию?
- Понимают ли пользователи сообщения об ошибках при неудачном входе?
- Двухфакторная аутентификация добавляет безопасность или просто раздражает пользователей, которые бросают процесс?
На эти вопросы нельзя ответить, читая спецификацию. Они требуют наблюдения за реальным поведением пользователей.
Сравнительная таблица
| Аспект | Верификация | Валидация |
|---|---|---|
| Вопрос | Мы строим продукт правильно? | Мы строим правильный продукт? |
| Фокус | Процесс и спецификации | Потребности и ожидания пользователя |
| Сравнивает с | Требования, проектная документация, стандарты | Реальное использование и цели пользователя |
| Методы | Ревью, инспекции, статический анализ, unit-тесты | UAT, бета-тестирование, юзабилити-исследования |
| Кто выполняет | Разработчики, тестировщики, QA-команда | Пользователи, клиенты, стейкхолдеры |
| Когда | На протяжении всей разработки (shift-left) | Поздние этапы, после сборки (shift-right) |
| Автоматизируется | Преимущественно да | Частично (A/B-тесты), в основном экспертная оценка |
| Находит | Дефекты (ошибки реализации) | Несоответствия ожиданиям пользователя |
Классическая аналогия
Представьте, что вы строите мост:
Верификация проверяет:
- Стальные балки правильной марки?
- Бетон замешан по спецификации?
- Болты затянуты с нужным моментом?
- Мост соответствует инженерным чертежам?
Валидация проверяет:
- Мост действительно решает проблему трафика?
- Ожидаемый объём трафика может безопасно проезжать?
- Мост находится в правильном месте?
- Водителям интуитивно понятно, как по нему ехать?
Мост может пройти все верификационные проверки (построен идеально по спецификации) и всё равно не пройти валидацию (построен в неправильном месте, решает несуществующую проблему).
Как V&V работают вместе
и непротиворечивые?] R --> V2[Валидация: Требования отражают
реальные потребности пользователей?] D[Дизайн] --> V3[Верификация: Дизайн
соответствует требованиям?] D --> V4[Валидация: Подход к дизайну
правильный для пользователей?] I[Реализация] --> V5[Верификация: Код
соответствует дизайну?] I --> V6[Валидация: Функция работает
как ожидают пользователи?] T[Готовый продукт] --> V7[Верификация: Все спеки выполнены?] T --> V8[Валидация: Пользователи довольны?] style V1 fill:#3b82f6,color:#fff style V3 fill:#3b82f6,color:#fff style V5 fill:#3b82f6,color:#fff style V7 fill:#3b82f6,color:#fff style V2 fill:#22c55e,color:#fff style V4 fill:#22c55e,color:#fff style V6 fill:#22c55e,color:#fff style V8 fill:#22c55e,color:#fff
Обе активности происходят на каждой фазе разработки, и обе необходимы. Продукт, прошедший верификацию, но провалившийся при валидации — технически корректен, но бесполезен. Продукт, прошедший валидацию, но не верификацию — удовлетворяет потребности пользователей, но ненадёжен.
Цель — пройти обе проверки: создать правильный продукт и создать его правильно.
Пример из реальной жизни
Рассмотрим систему записи на приём к врачу:
Верификация пройдена, валидация провалена: Система идеально реализует требование «пациенты могут записаться на приём в 15-минутные слоты». Все тесты проходят. Но реальные пациенты хотят записываться по типу симптома, а система заставляет их знать, какой специалист нужен. Пациенты звонят на ресепшн. ПО технически безупречно, но практически бесполезно.
Валидация пройдена, верификация провалена: Пользовательское тестирование показывает, что пациентам нравится интуитивный интерфейс записи и маршрутизация по симптомам. Но в системе есть состояние гонки: когда два пациента одновременно бронируют последний слот, оба получают подтверждение. ПО решает правильную проблему, но имеет дефекты.
Обе пройдены: Система позволяет записываться по симптому, направляет к нужному специалисту, корректно обрабатывает одновременные бронирования, и пациенты реально пользуются ей вместо звонков. Это и есть цель.
Упражнение: классифицируйте активности V&V
Для каждого сценария определите — это преимущественно верификация, валидация или и то, и другое:
- Тестировщик запускает автоматизированный набор тестов и подтверждает, что все 500 тестов проходят
- Продуктовая команда наблюдает за фокус-группой, использующей новый процесс оформления заказа
- Аудитор безопасности сканирует кодовую базу на уязвимости OWASP Top 10
- CEO демонстрирует продукт ключевому корпоративному клиенту для получения обратной связи
- Разработчик запускает линтер, отмечающий несоответствия в форматировании кода
- Data-аналитик изучает записи пользовательских сессий, чтобы найти, где пользователи уходят
- QA-команда сравнивает формат ответа API со спецификацией OpenAPI
- Пилотная группа из 100 пользователей тестирует новую функцию перед полным запуском
Подсказка
Спросите себя: эта активность сравнивает со спецификацией/документом (верификация) или с потребностями/ожиданиями пользователей (валидация)?Решение
- Верификация — Автоматизированные тесты проверяют реализацию против заранее определённых ожидаемых результатов
- Валидация — Фокус-группы оценивают, удовлетворяет ли продукт реальные потребности
- Верификация — Сканирование по определённому стандарту (OWASP Top 10)
- Валидация — Сбор обратной связи от реального стейкхолдера о соответствии продукта его потребностям
- Верификация — Проверка кода по определённому стандарту кодирования
- Валидация — Анализ реального поведения пользователей для понимания, работает ли продукт для них
- Верификация — Сравнение реализации с документом спецификации
- Валидация — Реальные пользователи оценивают функцию на практике (бета-тестирование)
Профессиональные советы
Совет 1: Требования могут быть «верифицированы», но ошибочны. Требование может гласить: «Страница результатов поиска загружается менее чем за 5 секунд». Вы это успешно верифицируете. Но пользователи ожидают результаты менее чем за 1 секунду, потому что Google приучил их к этому. Верификация пройдена — валидация провалилась бы. Всегда ставьте под сомнение спецификации, а не только тестируйте по ним.
Совет 2: Валидацию сложнее автоматизировать — но не невозможно. Фреймворки A/B-тестирования, инструменты аналитики и системы feature flags позволяют валидировать непрерывно в продакшене. Современный QA не ждёт формальных сессий UAT.
Совет 3: Лучшие тестировщики делают и то, и другое одновременно. Тестируя функцию по требованиям (верификация), опытный тестировщик также думает: «А реальный пользователь действительно так сделал бы?» (валидация). Такое двойное мышление ловит проблемы, которые однофокусное тестирование пропускает.
Ключевые выводы
- Верификация проверяет соответствие спецификациям («создаём продукт правильно»)
- Валидация проверяет соответствие потребностям пользователей («создаём правильный продукт»)
- Необходимы обе проверки — прохождение одной при провале другой ведёт к плохим результатам
- Верификация обычно внутренняя и документо-ориентированная; валидация — внешняя и пользователе-ориентированная
- Лучший подход к QA сочетает обе перспективы на каждой фазе разработки
- Идеально верифицированный продукт, которым никто не хочет пользоваться — всё равно провал