Примеры верификации и валидации
Завод по производству лекарственных препаратов всегда будет проверять, соответствуют ли они техническим условиям и стандартам (верификация), а вот проверку, подойдут ли эти препараты определенному пациенту с таким-то набором симптомов, не будет (валидация).
Компания выпускает ботинки, предназначенные для загородных прогулок. Эти ботинки полностью соответствуют техническим условиям, и это проверяется для каждой пары (верификация). А вот подойдет ли эта обувь для высокогорных восхождений, предстоит определять отдельно (валидация).
Еще один пример, относящийся практически к любому предприятию. Отдел технического контроля осуществляет верификацию, а аудиторы проводят валидацию.
Путаница понятий
Разрабатываемое программное и аппаратное обеспечение, сложные системы и комплексы устройств необходимо тестировать и проверять на соответствие разнообразным требованиям в разные моменты времени на протяжении всего жизненного цикла продукта.
Вне контекста каждый человек имеет свое субъективное представление о том, что означают слова «проверка», «тестирование». В каждой отрасли есть свои нормативы, которым нужно следовать, если пришло время что-то «проверить», а также расписание – когда, на каком этапе и как должны выполняться определенные проверки. На каждом уровне разработки есть свои «приемы» и рекомендованные мировым сообществом процессы, связанные с «проверкой» объекта на соответствие или наоборот несоответствие предъявляемым требованиям. Международные стандарты регулируют необходимые для проверок действия и поясняют их смысл, убирая неопределенность из описанных выше фраз.
Изучив стандарты и другие нормативные документы, можно овладеть лучшими практиками и перейти от проверок к пониманию подходов тестирования, валидации и верификации. Область проверки соответствия какого-то результата каким-то требованиям достаточно широка, поэтому часто возникает путаница понятий. Разберем значения основных терминов (Рисунок 1).
Рисунок 1. Облако понятий
Что и на соответствие чему мы проверяем? Чтобы оценить, соответствует ли какой-то параметр нужному значению или требованию, этот параметр нужно измерить.
3.1. Характеристики качества
Определим сначала параметры, которые можно и нужно измерять в контексте оценок качества. Некоторые из характеристик качества программного обеспечения по ГОСТ 28806-90 (Качество программных средств) и ГОСТ 9126-93 (Оценка программной продукции) приведены в таблице ниже (Таблица 2).
Таблица 2. Характеристики качества ПО по ГОСТ 288806-90 и ГОСТ 9126-93
При проектировании к этим и другим характеристикам качества продуктов, программного обеспечения и систем выдвигаются требования, которым конечный продукт должен удовлетворять.
3.2. Валидация, верификация и другие термины
В каждой отрасли свои стандарты, ограничения и требования к качеству процессов и результирующего продукта.
Ниже (Таблица 3 и далее) приведены определения таких понятий и терминов, как валидация, верификация, обеспечение качества, контроль качества, тестирование.
Таблица 3. Валидация и верификация
Обеспечение качества — Quality Assurance – комплекс мероприятий и сквозных процессов по проектированию, разработке, внедрению, анализу и доработке существующих процессов и практик, осуществляющих весь жизненный цикл качественного продукта.
Контроль качества — Quality Control – комплекс мероприятий, результатом которых является оценка качества результирующего продукта и анализ несоответствия результата предъявляемым требованиям.
Тестирование — Testing – испытания, тестирование, каким мы хотим его видеть, по сути и должно являться контролем качества.
Разница между валидацией и верификацией
Верификация — обычно внутренний процесс управления качеством, обеспечивающий согласие с правилами, стандартами или спецификацией. Простой способ запомнить разницу между валидацией и верификацией заключается в том, что валидация подтверждает, что «вы создали правильный продукт», а верификация подтверждает, что «вы создали продукт таким, каким и намеревались его сделать».
Ещё один пример типичной верификации: проведение испытания оборудования. Имея определенные требования на руках, мы проводим испытание продукта и фиксируем, соблюдены ли требования. Результат верификации — ответ на вопрос «Соответствует ли продукт требованиям?».
Но далеко не всегда продукт, соответствующий установленным требованиям, можно применять в конкретной ситуации. Например, лекарство прошло все положенные испытания и поступило в продажу. Значит ли это, что оно может быть применено каким-то конкретным больным? Нет, так как каждый организм имеет свои особенности и конкретно для него, это лекарство может быть губительным, то есть кто-то (врач) должен подтвердить: да, этому больному можно принимать это лекарство. То есть врач должен выполнить валидацию: придать законную силу конкретному применению.
Другой пример: предприятие выпускает трубы, предназначенные для закладки в землю, в соответствии с некоторыми ТУ (Техническими условиями). Продукция этим ТУ соответствует, но поступил заказ, предполагающий укладку труб по дну моря. Могут ли трубы, соответствующие имеющимся ТУ, быть применены в данном случае? Именно валидация и дает ответ на этот вопрос.
Можно видеть, что еще одно отличие состоит в том, что верификация производится всегда, а вот необходимость в валидации может и отсутствовать. Она появляется только тогда, когда возникают требования, связанные с конкретным применением продукции. Если фармацевтический завод выпускает лекарства, то он будет проверять лишь их соответствие требованиям, а проблемами применения конкретных лекарств конкретными пациентами заниматься не будет.
Таким образом, можно констатировать следующее:
- верификация — проводится практически всегда, выполняется методом проверки (сличения) характеристик продукции с заданными требованиями, результатом является вывод о соответствии (или несоответствии) продукции,
- валидация — проводится при необходимости, выполняется методом анализа заданных условий применения и оценки соответствия характеристик продукции этим требованиям, результатом является вывод о возможности применения продукции для конкретных условий.
Исходя из вышеописанного, валидация должна быть определена как подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, точно и в полном объёме предопределены, а цель достигнута.
Применение в современных технологиях
Если различия между понятиями валидации и верификации в рассматриваемом примере с производством и потребителем достаточно ощутимы и прозрачны, то отличить их в сфере применения высоких технологий (куда они прочно вошли и активно используются) уже намного сложнее. По сути оба этих термина в интернете представляют из себя один и тот же процесс проверки легитимности введенных или указанных данных.
Например, в современной жизни практически не осталось человека, не имеющего в глобальной сети интернет хоть какого-нибудь аккаунта. Социальные сети, электронная почта, платежные сервисы и системы мгновенных переводов – все они требуют прохождения регистрации пользователей с вводом персональных данных и последующим их подтверждением.
Именно подтверждение верности введенной информации с целью проверки ее достоверности и является верификацией данных или аккаунта.
Термин «валидация» в интернете используется, в основном, крупными социальными сетями, такими как, «Одноклассники» и «Вконтакте». Если пароль к системе не сохранен на компьютере или пользователь социальной сети желает посетить аккаунт с другого (ранее не использовавшегося) устройства, например, мобильного телефона, планшета и т.д., ему непременно предлагается пройти валидацию персональных данных в системе. Даже разблокировка мобильного устройства с помощью сканера отпечатка пальцев или сетчатки глаза в каком-то роде является валидацией (верификацией) личности.
Из приведенных примеров видно, что различие между этими двумя понятиями в техническом применении достаточно размыто и в сущности означает одно и то же. Разница лишь в сфере применения одного или другого термина различными интернет (онлайн) сервисами. К слову, интернет мошенники широко используют псевдо процесс валидации (верификации) персональных данных пользователей для перехвата логинов и паролей с последующим их незаконным использованием в мошеннических целях.
Валидация широко применяется и в общественных местах. Валидаторы – это устройства, считывающие электронные метки с магнитных носителей информации, установлены во многих местах ограниченного по особым условиям посещения. Яркий пример совмещенного с турникетом валидатора – это метро, где учет посещаемости, а также правомерности посещения метро ведется с помощью предъявления электронной карты на входе в тоннель.
Электронные валидаторы устанавливаются также в офисах крупных финансовых организации и на входе в здания государственных и силовых структур. Таким образом производится процесс валидации (в данном случае проверки принадлежности к определенному кругу лиц и контроля доступа) посещения учреждения.
Валидатор — это…
Так же, как и с проверкой грамотности языка, HTML-код можно проверять вручную — своими глазами и мозгами, а можно пользоваться и автоматическими помощниками. Это может быть отдельный целостный сервис, а может быть дополнение к браузеру. Первое лучше. Инструменты валидации HTML-кода онлайн облегчают жизнь разработчика, которому не нужно самому вычислять, например, парность скобок.
Как пользоваться валидатором
Рассказываем на примере «родного» валидатора W3C. Этот валидатор используется потому, что его сделали авторы правил, которым должен соответствовать код. Вы можете пройти по ссылке и провести валидацию кода на своём любимом сайте. Будет интересно.
За вами выбор способа проверки. Можно проверять код по ссылке, можно загрузить в сервис HTML-файл, а можно фрагмент кода. В третьем варианте как раз и идёт речь о написанном в окне сервиса коде или скопированной части из разметки всей страницы.
Цепочка действий в два шага. Первый — предоставить исходный код, а второй — нажать на кнопку проверки.
Вы можете пойти дальше и задать дополнительные параметры валидации. Они нужны, чтобы структурировать и детализировать результаты.
Интерпретация результатов валидации
Инструмент валидации оценивает синтаксис, находит синтаксические ошибки типа пропущенных символов и ошибочных тегов и т.д. И отлавливает одну из частых ошибок вложенности тегов.
Часто в результате сервисы валидации разметки, как и компиляторы в разработке, выдают список, разделённый на предупреждения и ошибки. Разница в критичности. Ошибки с максимальной вероятностью могут создать проблемы в работе кода. Это опечатки (да, техника любит точность), лишние или недостающие знаки. А вот к предупреждениям относятся неточности, которые с минимальной вероятностью навредят работе страницы, но не соответствуют стандартам. Это избыточный код, бессмысленные элементы и другие «помарки».
Так выглядит результат валидации HTML-кода на очень простой странице, созданной за пару часов в конструкторе сайтов.
Ошибки и предупреждения собраны в список. В каждом элементе списка указаны значение, атрибут и элемент, которые не устроили валидатор, а также приведена цитата кода с ошибкой.
Сами валидаторы могут ошибаться. То, что не пропускает валидатор, может быть корректно обработано браузером. Так что не обязательно исправлять абсолютно все ошибки в своей разметке
Обращать внимание и уделять время проверке надо при серьёзных ошибках, которые мешают корректной работе сайта и отображению страниц
Подробнее о валидаторе, правилах построения HTML-разметки, а также другие интересные и важные вещи мы разбираем на интенсивных курсах.
О тестировании
Тестирование может быть разных типов в зависимости от этапа жизненного цикла, объекта тестирования, цели, имеющейся информации и других факторов. В качестве примеров можно привести ручное и автоматизированное тестирование, регрессионное тестирование и тестирование производительности, есть и другие виды. Некоторые виды тестирования отображены в облаке на рисунке ниже (Рисунок 2).
Рисунок 2. Облако видов тестирования
4.1. Валидация требований
Важно понимать, что валидация требований и валидация продукта, построенного на основе этих требований – разные процессы. Валидация требований – процесс проверки требований на то, что они действительно описывают именно ту систему, которую пользователь хочет видеть
Процесс валидации требований смежен с анализом требований, так как он напрямую касается поиску проблем в требованиях. Валидация требований – очень важные процесс по причине того, что ошибки в требованиях приводят к огромным финансовым потерям на исправление этих ошибок. Эти затраты тем больше, чем на более позднем этапе жизненного цикла произошло выявление ошибок в требованиях (Рисунок 3).
Валидация требований – процесс проверки требований на то, что они действительно описывают именно ту систему, которую пользователь хочет видеть. Процесс валидации требований смежен с анализом требований, так как он напрямую касается поиску проблем в требованиях. Валидация требований – очень важные процесс по причине того, что ошибки в требованиях приводят к огромным финансовым потерям на исправление этих ошибок. Эти затраты тем больше, чем на более позднем этапе жизненного цикла произошло выявление ошибок в требованиях (Рисунок 3).
Рисунок 3. Рост стоимости исправления ошибок в требованиях
Причина такого роста очень проста – изменение в требования обычно влечет за собой необходимость проведения проектирования и разработки заново. А следовательно, продукт должен подвергнуться повторному тестированию, валидации и верификации на соответствующих стадиях жизненного цикла. Процесс валидации требований состоит из проверок, совершаемых в соответствии с определенными техниками (Ian Sommerwille “Software Engineering”).
Чтобы оценить качество проведенных испытаний, можно использовать метрики оценки качества тестирования. Одной из таких метрик является тестовое покрытие – насколько требования покрыты тестами.
Валидация и верификация — что это простыми словами?
Оба понятия связаны с тестированием какого-либо продукта и обеспечением его качества. Если мы будем говорить простым языком, то выведем следующее:
- Валидация – гарантированная уверенность производителя в том, что он создал продукт по всем необходимым стандартам.
- Верификация – помогает увериться в том, что изделие соответствует всем изначально заданным требованиям к нему.
Рассказывая простыми словами, что это – верификация и валидация, нужно сделать упор и на такие факты:
- Для потребителя важнее всего валидация – уверенность в том, что он получает правильный продукт, соответствующий его требованиям.
- Для производителя более ценной будет верификация – подтверждение того, что изделие, которое он отправляет на реализацию, отвечает всем необходимым стандартам и нормам.
Ключевые различия понятий
Итак, расставим все точки над i. Верификация – это любое тестирование, через которое проходит продукт. Проверка правильности технологии его производства, а также качества изделия. Валидация же — понятие, более близкое к аттестации. Это соответствие каким-то конкретным, а не общим требованиям. Насколько хорош продукт не вообще, а именно для определенного потребителя, заказчика или заданных условий.
Еще можно отметить, что верификация – это бумажное, теоретические тестирование технологии или продукта. Валидация же – реальная, физическая проверка, осуществляемая на практике, в конкретных условиях.
Если изделие прошло верификацию, значит, оно соответствует каким-то заданным технологическим требованиям. Если же успешно пройдена валидация, выходит, что на практике оно также без нареканий применимо. Отсюда можно вынести, что последнее понятие несколько важнее, показательнее, нежели первое.
Валидация с использованием database constraints
Пожалуй, самый распространенный и очевидный способ валидации данных — это использование ограничений на уровне БД, например, флаг required (для полей, значение которых не может быть пустым), длина строки, уникальные индексы и т.д. Такой способ больше всего подходит для корпоративных приложений, так как этот тип ПО обычно строго ориентирован на обработку данных. Тем не менее, даже здесь разработчики часто совершают ошибки, задавая ограничения отдельно для каждого уровня приложения. Чаще всего причина кроется в распределении обязанностей между разработчиками.
Рассмотрим пример, который большинству из нас знаком, некоторым даже по собственному опыту… Если спецификация гласит, что в поле номера паспорта должно быть 10 знаков, весьма вероятно, что проверяться это будет всеми: архитектором БД в DDL, backend-разработчиком в соответствующих Entity и REST сервисах, и наконец, разработчиком UI непосредственно на стороне клиента. Затем это требование меняется, и поле возрастает до 15 знаков. Девопсы меняют значения constraints в БД, но для пользователя ничего не меняется, ведь на стороне клиента ограничение все то же…
Любой разработчик знает, как избежать этой проблемы, — валидация должна быть централизована! В CUBA такая валидация находится в JPA-аннотациях к сущностям. Основываясь на этой метаинформации, CUBA Studio сгенерирует верный DDL-скрипт и применит соответствующие валидаторы на стороне клиента.
Если аннотации изменятся, CUBA обновит DDL-скрипты и сгенерирует миграционные скрипты, поэтому в следующий раз при развертывании проекта новые ограничения на основе JPA вступят в силу и в интерфейсе и в базе данных приложения.
Несмотря на простоту и реализацию на уровне БД, дающую абсолютную надежность этому методу, область применения JPA аннотаций ограничена самыми простыми случаями, которые могут быть выражены в стандарте DDL, и не включают триггеры БД или хранимые процедуры. Так что, ограничения, основанные на JPA могут делать поле сущности уникальным или обязательным или задавать максимальную длину столбца. Можно даже задать уникальное ограничение для комбинации колонок с помощью аннотации . Но на этом, пожалуй, все.
Как бы то ни было, в случаях, требующих более сложной логики валидации, вроде проверки поля на минимальное/максимальное значение, валидации при с помощи регулярного выражения, или выполнения кастомной проверки, свойственной только вашему приложению, применяется подход, известный как «Bean Validation».
Пример
Есть форма из 5 полей:
- Название организации — простое текстовое, обязательное
- ИНН — 10 или 12 цифр, проверка контрольной суммы по потере фокуса, обязательное
- КПП — 9 цифр с проверкой контрольной суммы по потере фокуса, обязательное, если ИНН состоит из 10 цифр
- Электронная почта — адрес почты, проверка по потере фокуса по маске a@a.aa, необязательное
- Телефон — международный формат, проверка по потере фокуса по маске +00000000000, обязательное
Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:
Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:
Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:
Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.
Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:
Заполнил название организации, перешел в поле ИНН:
Понял, что ИНН правильный, и нужно заполнить КПП:
Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из :
Заполнил КПП, перешел в следующее поле:
Исправил почту, перешел в следующее поле:
Исправил телефон, кликнул за пределами поля:
Теперь по нажатию кнопки «Отправить» все будет хорошо.
Реализованный пример этой формы можно посмотреть в .
