Очень конкретная разница между верификацией и валидацией

А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — нет, ты не идиот, просто давным-давно, в другом мире…

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

Когда я только выполнял чужие кейсы, это всё было ненужным и абстрактным лайном.

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

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

А валидационные запросто отклоняли, бо «тестируется сценарий, которые не предусмотрен требованиями».

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

Если в этот момент юзер решит вернуться на шаг назад — он должен передвигаться между экранами только через JS-кнопки «back» и «forward» в приложении (почти каждый современный сайт — приложение). Так написано в требованиях, так реализовано программистами.

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

Поскольку мы занимаемся только тестированием и игнорируем всю остальную Computer science (нам о ней на курсах не докладывают!), то может показаться, что вся эта верифилидация — сугубо тестерское дело, которое относится только к тест-кейсам.

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

Люди, которые создают требования, должны уметь проверять их на внятность, однозначность, непротиворечивость до того, как их выдадут программистам и тестировщикам — всё то, о чём ты лихо говоришь на собеседованиях, но слабо представляешь себе, как именно это надо делать.

И нет, тут подразумевается не покрытие требований тест-кейсами (это всё делается позже, как правило, нами), а проверка требований разными аналитическими инструментами.

Все эти наши техники тест-дизайна — это примеры аналитических инструментов. И они нужны не для того, чтобы уменьшать количество тест-кейсов… впрочем… да…

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

Где взять эту книгу — а проверь свои гигабайты скачанных, но не прочитанных книг, наверняка она там есть. Или глянь Amazon.

Кстати, эту книгу перевели на русский язык, но сделали это очень по-уебански*, поэтому надо смотреть только в первоисточник.

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким?

Когда дело доходит до тестирования, все эти термины наследуются, поэтому всё так и устроено. И подразумевается, что наследуется и их понимание. Или ещё круче: странно осознавать, что это всё кому-то может быть непонятным. Но принимаем мир таким, какой он есть.

Или вот те раз, вот те два, вот те три — примеры очевидных техник проработки требований. Посмотри, как много из этого понятно тестировщику.

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

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

Совершенно ненужный эпилог

Завершим наш пир духа мелким тематическим лозунгом от весёлых психихиатров:

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

Лозунг этот самододумывательный, но ёмкий: если вы не понимаете, в чём разница между валидацией и валидолом — никто вас за идиотов не держит. Вы просто не понимаете, в чём разница. Есть смысл спросить.

Как правило, никто никого ни о чём не спрашивает, бо… смотри лозунг от весёлых психихиатров.

You know it’s sad but true.