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

Автор: | 13.02.2020

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

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

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает 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.

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

  1. Уведомление: From Theory to Theory again | Normal testing

  2. Aleksandr

    открыл для себя новое толкование этих понятий и немного опешил…потому что всегда считал, что верификация отвечает на вопрос – “мы делаем правильно?” и подразумевает “белый ящик”, а валидация отвечает на вопрос “мы сделали правильно?” и подразумевает “черный ящик”…опыт базируется на тестирование программно-аппаратных комплексов для систем критических для безопасности…

  3. Алексей Лупан

    Тонкая разница между “а мы сделали правильно” и “а мы правильно сделали” в английском языке воспринимается более адекватно ввиду особенностей английского языка. В русском она воспринимается как ненужная перестановка кроватей при падении доходов и легко поддаётся запутыванию при выяснении деталей.
    Предложенное вами разделение достаточно логично, и в отношении программно-аппаратных комплексов может считаться верным, если надо тестировать железо отдельно и опционально прилагающееся к нему ПО отдельно (программно-аппаратных комплексов для систем критических для безопасности в вашем случае).
    Но связывать верификацию с «белым ящиком», а валидацию с «чёрным ящиком» — а вот это уже мне кажется странным, бо у меня в фокусе только разработка ПО. Я не знаю, какая именно железяка его обслуживает, подходить к нему с тестером наголо нет необходимости. Можно сервер поднять и на моём ноуте, и подразумевается, что всё должно заработать. И если мы начнём разговор с того, что верифицировать и валидировать можно (и нужно) сами требования к ПО (и железкам в вашем случае), а не само ПО, то картина будет иная. Будет ли она для вас уместна?
    Можно же делать верификационные тесты для ПО и не заглядывая ему в код. Если оно делает то, что было заказано, то верификация пройдена методом «чёрного ящика» — без противоречий.
    И можно делать валидационные тесты, глядя в код — обычно после этого начинается рефакторинг и швыряние стульев. Но уже сложно представить себе, какие такие неформализованные ожидания от кода могут быть у пользователя ПО, который пользуется ПО, не заглядывая ему под код… Неважно вообще, как организован код кофемашины, бо удобно-неудобно кодом не описывается. Хотя им и задаётся, если речь идёт о восприятии последовательности вывода каких-то сообщений или… тут уже воображать можно долго.
    ПО вообще — абстракция.
    Тестирование ПО — продумывание предполагаемых и вероятностных ситуаций, в которых это абстрактное ПО должно (и, соответственно, может) оказаться в ходе решения задач.
    Тест-кейсы — ситуации, которые мне надо воссоздать искусственным образом (ради, соппсно, проверки, чтобы знать, как ПО будет отрабатывать свои задачи) для выяснения способности ПО выполнять поставленные перед ним задачи предопределённым способом.
    Но если ПО в железках можно использовать только определённым образом (для примера подойдёт пульт от ТВ или кондиционера), то в браузерах — или вообще в операционной системе — взаимодействие с ПО может отклоняться от предопределённого способа. Поэтому надо смотреть и придумывать дополнительные ситуации или и ситуации, и способы их создания.
    Метафора «белый ящик» заявляет о том, что я буду придумывать/распознавать тестовые ситуации на основе кода ПО и/или его спеки. На основе увиденного можно продумывать все положительные и отрицательные сценарии, которые должны/могут быть выполнены. Но если программист что-то упустил и какой-то IF не учёл, то вероятно, что и я его пропущу. Например, в алгоритме заваривания чая есть множество подразумеваний вроде «вскипятить воду». А если вода придёт зелёного цвета? А если воды нет? Человек это разрулит на ходу. Робот нет. Тесты на основе «белого ящика» тоже могут такие банальности не предусматривать, и это их слабость.
    Поэтому есть метафора «чёрный ящик», которая заявляет о том, что для придумывания тестовых ситуаций я буду воображать условия выполнения задач будущим ПО на более высоком уровне абстракции, не привязываясь к реализации. Мы это ещё называем «тыкать пальцем в живое приложение и наблюдать за реакцией», но такие тесты можно (и нужно) придумывать и записывать задолго до момента, когда ПО будет доступно для тыкания в него пальцем.
    Программистам всегда кажется, что «белого ящика» должно хватать, и поперву это воспринимается очень обоснованно, бо что нам заказали, то мы и реализовали в коде, case closed. Тестировщики обыкновенные, которые в код смотреть не умеют, вообще не понимают все эти метафоры, и используют «ящики» как средство объяснения своей финтифлюшности, вроде, я мануальный ручник, я тестирую только «чёрным ящиком» и оставьте меня в покое, а «белый ящик» это якась неведома шняга, которой занимаются только программисты.
    А дальше другой пласт — соответствие требованиям не всегда ортогонально к ситуациям, которые строго предлагаются в требованиях к ПО или выявляются в ходе его разработки или эксплуатации. Идеальное соответствие требованиям не означает, что ожидаемое качество ПО было достигнуто, бо толку-то, если мне неудобно или некрасиво или что там ещё, так сложно формализуемое на языке логики и математики, но так легко понятное на языке «личностного отношения». Оказывается, ещё надо выявлять и неформализуемые требования, и это уже будем называть «валидацией». И да, это всё можно сформулировать и записать как требования ещё на этапе, соппсно, работы с требованиям, когда нет ни кода, ни тестов, ни точного понимания того, как всё будет в итоге выглядеть. Что-то будет достаточно верифицировать, что-то будет нужно валидировать — вот примерно такая простая картина Босха. Всюду, где в итоге качество будет определять человек — нужно продумывать и верификацию (основа) и валидацию (опционально, но это источник итоговой оценки).
    В отношении API или настройки железа валидация бывает и не нужна, бо (условно) видеокамера настроена так, как должна быть настроена, и выдаёт то разрешение, которое в ней заложено конструктивно, а если мне что-то не нравится, то иди покупай другую видеокамеру, с этой ничего не изменится.
    Ещё более условно: технологически совершенному современному автомобилю я предпочту старую ГАЗ-21, и никакая верификация технологических параметров не будет аргументом. Да, медленная машина. Да, большой расход. Да, неудобно руль крутить на парковках. А мне в целом — нравится. Валидация тут важнее.
    Или, скажем, Windows XP…
    Ввиду того, что вы опешили — потребуете ли вы отсылки к трудам признанных богословов церковно-тестировщицкой литературы? Обычно на этом разговоры вянут, бо даже если таковая найдётся, не факт, что она выстоит против новых аргументов. И у каждого собеседника всегда есть спасительное «А я не верю, и таково моё мнение» — а это неоспоримо.

  4. Для тех, кто в танке

    Очень сомнительные рассуждения.
    Получается, прописанное требование валидировать не нужно?
    Когда читал, было ощущение, что перепутаны понятия “позитивного” и “негативного” тестирования с “верификацией” и “валидацией”. Проверил. Получилось субъективно логичней.

  5. Ilya

    И то и другое означает проверка. А разницу придумали тестировщики. Чтобы показать, что они тоже “профессионалы”.

  6. Алексей Лупан

    Ок.
    Уточните понятия «позитивного» и «негативного» тестирования.

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.