В чём разница между валидацией и верификацией?

Основные различия верификации и валидации

Как верификация, так и валидация технологического продукта являются действиями, которые используются для проверки того, является ли произведенный продукт требуемым нами или другим заинтересованным лицом (к примеру заказчиком системы).

Стоит помнить, что оба эти действия происходят в разные моменты времени разработки системы. Следовательно, будет неправильно понимать, например, валидацию как этап, завершающий построение системы. (Это замечание здесь уместно, поскольку во многих случаях приемочные испытания конструкции обычно называются «валидацией» во многих командах)

Различия между верификацией и валидацией связаны, прежде всего, с целью тестирования.

Самый простой способ - помнить, что мы верифицируется то, что можно рассчитать, проверить логически. С хорошо написанными требованиями, верификация может быть выполнена любым, кто понимает текст спецификации и знает, как выполнить тест.

Валидация в свою очередь проверяет удовлетворение потребностей клиента и является окончательным критерием успеха. Исключив возможность консультации с клиентами по вопросам, касающимся удобства использования продукта, производители рискуют провалить валидацию.

Верификация

Верификация продукта заключается в предоставлении доказательств того, что продукт соответствует определенным требованиям. Также существует такое определение термина, которое утверждает, что верификация проверяет, «правильно ли построено приложение», соответствуют ли продукты данной стадии производства условиям, указанным в начале.

Ключевое слово здесь «определено». Верификация требует ссылки на требования, которые были написаны таким образом, что их можно проверить однозначно. Верификация заключается в утверждении, что данный пункт, например технической спецификации, является утверждением, которое действительно описывает продукт, который мы тестируем. Поэтому на практике важно связывать верификацию с процессом, который приведет к принятию решения «ноль один» о том, что продукт выглядит или ведет себя или соответствует тому, что указано в спецификации.

Например функцию можно верифицировать, вычислив числовой результат, который она возвращает; или же верифицировать, отправляется ли соответствующий файл между сервером и клиентом - тогда мы можем ожидать, что процесс верификации этого продукта является корректным.

Валидация

Валидация продукта включает проверку правильности и предоставление доказательств того, что продукт производственного процесса соответствует потребностям и требованиям пользователя. Это также можно понимать как «проверку правильности приложения» (в более старых версиях словарей тестировщиков).

Самым важным для понимания валидации является то, что в случае валидации четко определенные критерии прохождения теста преобразуются в потребности и требования пользователя. Несмотря на то, что можно проверять различные вещи, не понимая роли конечного пользователя (поскольку нам нужно только полагаться на вычисления и проверять, соответствуют ли результаты утверждениям из спецификации), валидация используется для проверки всех функциональных возможностей, которые пользователь оценит в соответствии со  своими личными предпочтениями, часто субъективными.

Успешность валидации часто основывается на проблемах, которые трудно предсказать при написании функциональной спецификации. Получатель системы часто не осознает своих собственных предпочтений и может заявить, что «ему что-то не нравится» только тогда, когда он проходит финальный приемочный тест. Аргумент, часто звучащий из уст недовольного заказчика, состоит в том, что что-то «настолько очевидно, что это не должно быть записано в спецификации».

В то время как ключ к успешной верификации продукта заключается в четком определении критериев для прохождения теста, ключ к успешной валидации - это углубленное и эффективное общение с пользователем, постановка точных вопросов, помогающих понять реальные потребности клиента, проведение с клиентом моделирования системных приложений на всевозможных макетах. Другим очень важным вопросом является умелое использование исследований текущих решений и тенденций в продуктах, уже доступных на рынке (хотя бы для того, чтобы предсказать, что будет проверять клиент, который сравнил несколько решений, предоставленных нашими конкурентами).

Не стоит тесно связывать верификацию с функциональными требованиями, а валидацию с нефункциональными требованиями. Фактически, функциональное тестирование на основе предоставленных функциональных требований чаще всего связано с утверждением «ноль-один» о наличии заданного, запланированного решения в системе, и мы обычно понимаем нефункциональные требования как те, которые менее четко описаны в спецификации, но это не означает, что нефункциональные требования не могут быть описаны в форме, которая позволяет их верификацию. Простейшим примером будет тест производительности (наиболее нефункциональный атрибут), чей критерий прохождения будет ответ системы менее чем за 50 мс. Мы можем ясно видеть, что такое требование может быть проверено, и результат теста может быть описан четким утверждением,

Валидацию следует понимать как действия, которые повышают вероятность удовлетворения пользователя созданным продуктом и которые будут учитывать консультации с этим пользователем, совместную разработку решения и прогнозирование его предпочтений.