Валидация и верификация требований
Введение: шьём костюм по меркам 👔
Можно идеально сшить костюм по выкройке, но если мерки неверные — он не подойдёт.
Так же и в разработке: важно не только «сделать правильно», но и «делать нужное».
Валидация проверяет нужность и ценность требований.
Верификация проверяет соответствие реализации этим требованиям.
✅ Вывод: качество требований определяется двумя вопросами: «то ли делаем?» и «так ли делаем?»
Проблема → решение
Проблема: команды часто сосредоточены только на реализации, из-за чего получают формально работающую, но бизнесу ненужную функцию.
Решение: разделять validation и verification как два обязательных цикла проверки:
сначала подтверждение ценности, затем подтверждение соответствия.
✅ Вывод: если пропустить любой цикл, резко растёт стоимость переделок.
Чем помогает и как работает
Процесс validation/verification помогает:
- снизить риск разработки «не того»;
- сделать требования однозначными и тестируемыми;
- заранее выявить противоречия между бизнесом и реализацией.
Как это работает:
- Бизнес и аналитик валидируют ценность требований.
- Команда уточняет критерии приёмки и границы.
- QA и разработка верифицируют соответствие реализации.
- Результат фиксируется через review, traceability и sign-off.
✅ Вывод: два типа проверки работают как единая система контроля качества.
Ключевые термины (простыми словами)
- Validation (валидация) — подтверждение, что требование нужно бизнесу и пользователю.
- Verification (верификация) — подтверждение, что решение соответствует требованию.
- Acceptance Criteria — условия «готово/не готово».
- Review / Walkthrough — совместная проверка требований с командой и стейкхолдерами.
- Prototype — быстрый макет для ранней проверки гипотез.
- Traceability Matrix — матрица связей «требование -> тест -> результат».
- Sign-off — формальное подтверждение согласованности.
✅ Вывод: общий словарь позволяет команде одинаково трактовать процесс проверки.
1. Валидация: делаем ли мы нужное
Назначение: проверить, несёт ли требование реальную ценность.
Пример:
Требование: добавить фильтр по уровню курса.Валидация: интервью показали, что пользователи теряются без этого фильтра.🔎 Как это происходит на практике:
- Формулируется гипотеза ценности.
- Проводится проверка на пользователях/бизнесе.
- Решение принимается на фактах, а не на ощущениях.
Когда использовать: до разработки и на ранних версиях требований.
✅ Вывод: валидация отвечает на вопрос «зачем это вообще нужно».
2. Верификация: сделали ли мы правильно
Назначение: проверить, что реализованное поведение соответствует согласованным требованиям.
Пример:
Требование: фильтр показывает только выбранный уровень.Верификация: тест-кейс подтверждает корректную фильтрацию для каждого уровня.🔎 Как это происходит на практике:
- Требование связывается с критериями приёмки.
- QA подготавливает тесты по сценариям.
- Результат сравнивается с ожидаемым поведением.
Когда использовать: после согласования требований и на этапах тестирования.
✅ Вывод: верификация отвечает на вопрос «соответствует ли реализация договорённости».
3. Acceptance Criteria как основа проверки
Назначение: сделать требования проверяемыми и однозначными.
Пример:
Given: пользователь авторизованWhen: выбирает уровень "beginner"Then: видит только курсы уровня "beginner"🔎 Как это происходит на практике:
- Критерии формулируются для main и error flows.
- Продукт и QA согласуют трактовку.
- Критерии становятся базой тест-кейсов.
Когда использовать: для всех Must/Should требований.
✅ Вывод: без AC спор «готово или не готово» почти неизбежен.
4. Review и walkthrough требований
Назначение: находить ошибки и неоднозначности до начала реализации.
Пример:
Совместный review: продукт + аналитик + QA + разработка.🔎 Как это происходит на практике:
- Черновик требований выносится на совместный разбор.
- Фиксируются риски, пробелы и конфликтные точки.
- Итоговая версия согласуется и фиксируется.
Когда использовать: после подготовки черновика и перед передачей в разработку.
✅ Вывод: review — самый дешёвый этап исправления ошибок требований.
5. Прототипы для ранней валидации
Назначение: проверить, понятна ли логика пользователю, до разработки.
Пример:
Прототип фильтра показал, что названия уровней неочевидны для новичков.🔎 Как это происходит на практике:
- Создаётся минимальный сценарный макет.
- Пользователи проходят задачу и дают фидбек.
- Требования корректируются до реализации.
Когда использовать: при новой функциональности и спорных гипотезах.
✅ Вывод: прототип экономит бюджет, выявляя ошибки раньше кода.
6. Traceability matrix
Назначение: контролировать покрытие требований проверками.
Пример:
R-12 -> AC-12 -> TC-45🔎 Как это происходит на практике:
- Каждому требованию присваивается ID.
- Указываются связанные критерии и тест-кейсы.
- На релизе проверяется, что нет непокрытых требований.
Когда использовать: в критичных релизах и при сложной регрессии.
✅ Вывод: трассируемость показывает, что именно проверено, а что ещё нет.
7. Sign-off и финальная договорённость
Назначение: формально зафиксировать, что требования согласованы и готовы к реализации.
Пример:
Sign-off: Product Owner, Lead QA, Tech Lead.🔎 Как это происходит на практике:
- Проверяются цели, AC, риски и покрытие.
- Ответственные подтверждают финальную версию.
- После sign-off изменения проходят через controlled change process.
Когда использовать: перед началом реализации и перед релизом критичных изменений.
✅ Вывод: sign-off снижает риск хаотичных правок «в последний момент».
Сравнение: validation vs verification
| Параметр | Validation | Verification |
|---|---|---|
| Ключевой вопрос | «Делаем нужное?» | «Делаем правильно?» |
| Фокус | Ценность и релевантность | Соответствие и качество реализации |
| Участники | Бизнес, продукт, пользователи | QA, разработка, аналитик |
| Артефакты | интервью, прототипы, feedback | AC, тесты, чек-листы, traceability |
Часто спрашивают на собеседованиях
- Чем validation отличается от verification в реальном проекте?
- Почему критерии приёмки критичны для верификации?
- Когда review требований обязательны?
- Зачем нужна матрица трассируемости?
- Что делать, если validation пройдена, а verification провалена?
✅ Вывод: хороший ответ всегда связывает теорию с практическими этапами работы.
Типичные ошибки
Ошибка 1: Validation только после релиза
❌ сначала код, потом проверка ценности
✅ валидация до старта разработки
Ошибка 2: Verification без чётких AC
❌ QA интерпретирует требования по-разному
✅ формальные критерии приёмки
Ошибка 3: Нет review
❌ проблемы выявляются слишком поздно
✅ совместный walkthrough перед реализацией
Ошибка 4: Нет traceability
❌ часть требований не покрыта тестами
✅ явная связь requirement -> test case
Best Practices
- Валидируйте ценность до начала реализации.
- Пишите AC так, чтобы они были тестируемыми.
- Делайте review требований межфункциональной командой.
- Используйте прототипы для спорных гипотез.
- Ведите traceability matrix для критичных требований.
- Фиксируйте sign-off перед реализацией.
Заключение
🎯 Validation отвечает за нужность требований.
🎯 Verification отвечает за корректность реализации.
🎯 Вместе они дают предсказуемый результат и снижают стоимость ошибок.
🎯 Verification отвечает за корректность реализации.
🎯 Вместе они дают предсказуемый результат и снижают стоимость ошибок.
Теперь вы можете выстроить проверку требований так, чтобы команда делала именно нужный и качественный продукт.