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

Итак, что же это за слова такие?

Верификация — доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены.

Валидация — доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения были выполнены (Глоссарий ISTQB)

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

Поиск разницы

Как мы выяснили из определения, верификация связана с подтверждением неких требований. Если мы возьмём любой технологический процесс от пошива штор и сборки офисного кресла до написания ПО, то заметим, что на предметы нашего процесса всегда есть техническое задание. В нём написано, какой высоты должно быть кресло, какого цвета и из какого материала. И если мы верифицируем кресло, то мы проверим его высоту, цвет и соответствует ли материал заявленному, т.е. наличие всех необходимых компонентов из ТЗ. Аналогично и для ПО.

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

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

Другими словами, верификация — это подтверждение того, что техническое задание было выполнено верно и в полном объеме. А валидация — проверка того, что итоговый продукт функционирует так, как от него и ожидалось. Может случиться так, что ТЗ выполнено верно, но итоговый продукт работает совсем иначе, чем от него ожидалось. Поэтому валидация является более показательным и всеобъемлющим понятием, чем верификация.

На примере из тестирования ПО

Теперь для большей ясности давайте разберём эти 2 процесса уже на примерах из области тестирования. Примером для нас выступит некая игра, которую делает наша компания.

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

В игру вводят новую фичу “Ежедневный бонус”.

В рамках верификации мы проверим наличие изменений, описанных в патч ноуте (списке изменений). Каждое из этих изменений было продумано геймдизайнерами и имеет своё техническое задание. И именно соответствие этому ТЗ мы и проверяем.

Мы проверим, что арт соответствует утвержденным макетам, что ежедневная награда соответствует своему ТЗ ( выдаётся 1 раз в день, каждая следующая награда ценнее предыдущей, если пропустить хоть 1, то снова с первой награды получать и т.д.). Если вдруг награды можно собирать чаще раза в день или награды не начисляются, мы заводим репорты, и верификацию фича не проходит.

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

Например, наличие ежедневной награды призвано вызвать у игрока желание зайти в игру хоть на 5 минуточек, чтобы эту награду забрать. И тут уже мы проверим, действительно ли с точки зрения игрока важно взять эту награду и хочется ли запускать игру ради нее. Например, если эти награды весомые и позволят игроку чувствовать себя в игре “круче”, то валидация будет пройдена. Но если награды не дают весомого преимущества (например, дают слишком мало кристалликов) и носят скорее номинальный характер, то цель заманить игрока в игру будет провалена, и валидацию эта фича не пройдёт.

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

Приступим к верификации. Проверим соответствие ТЗ, макету, посмотрим вёрстку и т.д.

Если в ходе проверок мы увидим, что цена отображается неверно или картинка при разных разрешениях экрана съезжает, то верификацию версия не пройдёт.

А что же с валидацией? Тут всё так же, как и в случае с играми. В первую очередь смотрим на то, зачем была введена фича. Предположим, цель была привлечь больше народа к плохо продаваемым товарам. Значит, нужно обратить внимание на то, насколько заметна эта колонка. Если она находится на главном экране, пестрит анимациями, яркими красками и всячески манит по ней кликнуть, то это значит, что она выполняет свою задачу. Но если она находится где-то внизу, арт блеклый и совершенно не обращает на себя внимания или находится рядом с чем-то поярче, то валидация пройдена не будет.

Итог

Таким образом, несмотря на очень большое сходство в определениях, верификация и валидация являются совершенно разными в плане подхода к тестированию. Важно ли QA использовать оба процесса? Определенно да, потому что без верификации продукт выйдет не таким, каким его планирует разработчик, а без валидации работа над продуктом может быть бессмысленна.