Продукт строго соответствует спецификации, но не решает задачу пользователя. Какой вид QA-деятельности должен был выявить это раньше и чем он отличается от проверки соответствия спецификации?
Это должна была выявить валидация: проверка того, что продукт действительно пригоден для intended use и решает задачу пользователя. Проверка соответствия спецификации — это верификация: оценка того, правильно ли реализованы зафиксированные требования. Продукт может быть корректно реализован с технической точки зрения, но неправильно выбран или сформулирован сам набор требований.
Разделение верификации и валидации появилось как ответ на две разные причины неудач проектов: ошибки реализации и ошибки в понимании нужного результата. Одних проверок соответствия проектной документации оказалось недостаточно, потому что спецификация может быть неполной, ошибочной или не отражать реальную работу пользователей.
Поэтому в инженерных процессах стали отдельно рассматривать соответствие продукта заданным требованиям и его пригодность для предполагаемого применения. Это разделение не означает, что валидация выполняется только в конце проекта: обратная связь о пригодности продукта нужна уже при анализе требований и создании прототипов.
Предположим, бизнесу нужен быстрый способ массово обрабатывать обращения клиентов. Команда реализует все пункты спецификации, но форма требует вводить слишком много данных, а ключевая операция занимает несколько минут. Формально требования выполнены, однако пользовательская задача не решена.
Если ограничиться только верификацией, такой дефект может обнаружиться после релиза. Последствиями станут переделка требований и архитектуры, потеря времени, неудовлетворённость пользователей и ложное ощущение качества из-за высокого процента пройденных тестов.
Верификация отвечает на вопрос: «Правильно ли мы создаём продукт по заданным требованиям?» Она включает анализ требований, ревью дизайна и кода, проверки трассировки, модульные, интеграционные и другие тесты, сопоставляющие фактическое поведение с ожидаемым.
Валидация отвечает на вопрос: «Тот ли продукт мы создаём и пригоден ли он для реального использования?» Для неё нужны сценарии реальных пользователей, проверка бизнес-процессов, прототипирование, приемочные проверки, usability-тестирование и анализ результатов в целевом контексте.
Главный механизм ошибки таков: спецификация является входом для верификации, но сама спецификация может быть неверной. Поэтому успешная верификация доказывает только соответствие зафиксированным условиям, а не ценность продукта и не полноту пользовательской задачи.
На практике граница между видами деятельности не абсолютна. Один и тот же приемочный тест может одновременно проверять соответствие требованию и пригодность сценария, но критерии оценки будут разными: в первом случае — совпадение с ожидаемым результатом, во втором — достижение полезного результата пользователем.
Нельзя считать валидацию заменой верификации. Проверка пользовательской ценности не обнаружит, например, ошибку в расчёте, нарушение контракта интерфейса или неучтённый граничный случай. Надёжный процесс сочетает оба направления и начинает их как можно раньше.
Команда разрабатывает внутреннюю систему согласования заявок. Спецификация требует десять обязательных полей и последовательное прохождение пяти ролей. Тестировщики подтверждают все переходы и правила, но пилотные пользователи сообщают, что для типовой заявки процесс слишком сложен и сотрудники обходят систему через электронную почту.
Рассматривались три варианта. Первый — продолжить только функциональную верификацию: он дешёв на коротком горизонте, но не обнаруживает непригодность процесса. Второй — сразу переписать систему: потенциально эффективно, но рискованно без подтверждения реальной причины. Третий — провести наблюдение за пользователями и валидацию прототипа упрощённого сценария: это требует времени, зато позволяет проверить гипотезу до дорогостоящих изменений.
Выбран третий вариант. Наблюдение показало, что часть полей не используется для принятия решения, а несколько ролей фактически выполняют одинаковую проверку. После уточнения бизнес-процесса команда сократила путь заявки, а последующей верификацией подтвердила корректность новых правил. В результате проверялась не только реализация спецификации, но и то, что изменённый процесс действительно полезен.
Да. Например, приемочный сценарий оформления заказа проверяет, что итоговая сумма соответствует требованию, и одновременно показывает, может ли пользователь завершить покупку в реальном процессе. Однако нужно явно разделять критерии: техническое соответствие не доказывает удобство или бизнес-ценность.
Нет. Валидация начинается с проверки того, правильно ли понята проблема пользователя. Интервью, анализ рабочих процессов, прототипирование и ранние usability-проверки помогают обнаружить ошибочное направление до реализации. Приемочное тестирование — лишь один из способов получить подтверждение пригодности готового решения.
Нельзя молча считать спецификацию единственным источником истины и подменять её ожиданиями отдельного пользователя. Следует зафиксировать расхождение, оценить репрезентативность потребности, уточнить бизнес-цель с владельцем продукта и при необходимости изменить требования управляемым способом. После этого выполняются и валидация нового решения, и верификация его обновлённой спецификации.