Верификация: определение, особенности, отличие от валидации

ВВЕДЕНИЕ

Настоящий документ представляет собой 1-е приложение к базовому документу «Валидация Компьютеризированных Систем», и должен использоваться в сочетании с ним, во время планирования, выполнения и документирования процесса валидации компьютеризированных систем. Базовый документ содержит Введение, Область применения и общие требования к валидации различных типов компьютеризированных систем. В настоящем приложении представлен пример валидации электронной таблицы Excel, который необходимо использовать в сочетании с общими рекомендациями, изложенными в основном документе. Этот документ следует рассматривать как руководство для OMCLs, для планирования, выполнения и документирования валидации их компьютеризированных систем. Его не следует воспринимать как перечень обязательных требований. Каждой OMCL предоставляется самостоятельное Это оставлено для профессионального суждения и фона опыт каждого принять решение о наиболее важных процедур, которые будут предприняты для того, чтобы дать показания, что их компьютерные системы работают правильно и соответствуют своему предназначению.

Чем верификация отличается от валидации

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

Верификация Валидация
Что это такое Соответствие изделия, модели или концепции заявленным требованиям. Мы собрали автомобиль. Он полностью соответствует техзаданию и едет. Верификация пройдена. Применимость созданной модели, изделия или концепции на практике в конкретных условиях. Мы собрали автомобиль. Он соответствует техзаданию. Но не едет по льду. Валидация не пройдена.
Для кого имеет значение Для производителя, автора Для потребителя, аудитории
Кто проводит Авторы, производители, разработчики Тестировщики, потребители
Обязательность использования Обязательно (автомобиль должен быть сделан по техзаданию и должен ехать) Необязательно (если мы знаем, что автомобиль едет, можно пробовать пускать его по льду, а можно и без испытаний спрогнозировать, что для успешной поездки нужна доработка в виде установки резины с шипами).
Вид оценки Объективная (соответствует ли изделие/модель стандартам) Субъективная (годится ли изделие/модель для использования в конкретных условиях)

1. ПРЕДСТАВЛЕНИЕ ПРОГРАММЫ И ОБЩИЕ СВЕДЕНИЯ

Задача рассматриваемого программного обеспечения заключается в расчете титрования вакцины (Рис. 1). По результатам, полученным для референтного препарата (измерение высоты в 4 концентрациях), строят калибровочную кривую и рассчитывают формулу. Оба этих элемента необходимы для расчета концентраций, соответствующих измеряемой высоте тестируемой вакцины. На Рисунке 1, серые ячейки заполняются числовыми данными из эксперимента и являются единственными, которые могут быть изменены оператором. Все ячейки, включая формулы заблокированы. Не более одной ячейки из диапазона калибровки может быть пустой, а все ячейки для вакцины должны быть заполнены, для гарантии правильного использования. Чтобы получить доступ к ПО, требуется пароль для входа в компьютер. Регулярно производится резервное копирование для обеспечения сохранности оригинальных файлов.

Рисунок 1. Представление Программного обеспечения

Поэтапная структура валидации

Процедура валидации включает 6 основных ступеней, которые приведены в таблице:

Наименование этапа Что включает процесс
Этап №1. Составление спецификации параметров и требований (URS) Сводное описание ожиданий от продукта, системы, технологии или оборудования.
Этап №2. Составление специализации функций (FS) Детальное описание стандартов соответствия для анализируемого объекта, необходимых для удовлетворения требований конечного потребителя.
Этап №3. Составление спецификации (DS) Детальное исчерпывающее описание всех параметров объекта, включая технические характеристики, проектные требования и другие оценочные критерии.
Этап №4. Квалификационная оценка установки или изготовления (IQ) Проверка документации, подтверждающей соответствие созданного продукта указанным в спецификациях требованиям и характеристикам.
Этап №5. Квалификационная оценка функциональности  (QQ) Проверка результативности продукта, процесса или системы относительно заявленных производителем параметров в стандартных условиях. К примеру, набор скорости транспортным средством анализируют в полигонных условиях, а не в условиях усложненного городского движения.
Этап №6. Квалификационная оценка применения (PQ) Оценка результативности продукции в реальных эксплуатационных условиях, с учетом влияния сопутствующих факторов. Для тех же транспортных средств это светофоры, неровности местности, наличие автомобильных потоков на дорогах и т. д.

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

Примеры валидации

Теперь примеры, чем отличается валидация от верификации.

Какое-либо предприятие в соответствии с определенными требованиями производит универсальные трубы. Поступает вопрос от заказчика: возможно ли данный продукт проложить по дну моря? Производитель должен провести валидацию своих труб в соответствии с предложенными условиями, чтобы объективно ответить на этот вопрос.

На примере того же велосипеда рассмотреть валидацию тоже очень легко. На устройстве можно кататься? Можно затормозить? Можно повернуть вправо, влево? Переключить скорость? Если все возможно, валидация пройдена. Не смогли затормозить, упало сидение, расшатан руль – увы, велосипед данную процедуру не прошел.

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

Пример из области медицины

Скажем,  разработали новое лекарство. Провели многочисленные тесты для ПРОВЕРКИ, что лекарство лечит такую-то болезнь. Здесь речь идет о ВЕРИФИКАЦИИ (о проверке соответствия лекарства его предназначению). Но Вы знаете, что на самом деле лекарство подходит не всем. Чтобы начать лечение Вам нужна ВАЛИДАЦИЯ врача. Только врач может ПОДТВЕРДИТЬ, что это лекарство подойдет КОНКРЕТНО Вам.

ВЕРИФИКАЦИЯ — это тестирование лекарства с целью ПРОВЕРКИ на соответствие его предназначению. А ВАЛИДАЦИЯ — это ПОДТВЕРЖДЕНИЕ врача, что лекарство подойдет КОНКРЕТНОМУ больному.

Пример из области производства

Предположим завод по производству велосипедов  принял заказ на партию велосипедов. Так вот, ВЕРИФИКАЦИЮ (ПРОВЕРКУ) на соответствие требованиям заказчика выполняет сам завод-производитель. А вот ВАЛИДАЦИЮ (ТЕСТИРОВАНИЕ, ПРОВЕРКУ) на соответствие своим требованиям будут выполнять представители самого заказчика.

Пример из области IT

Аналогичный пример можно привести из области IT. Компания — разработчик программного обеспечения получила заказ на разработку какого-то софта. Программа, которая была создана, прошла тестирование. Результатом тестирования является ВЕРИФИКАЦИЯ на стороне компании, выполняющей заказ, что программа полностью соответствует тех заданию заказчика. А вот ВАЛИДАЦИЮ будет выполнять сам заказчик, когда установит программное обеспечение и протестирует его.

Пример из сферы интернета

Социальная сеть Твиттер проводит ВЕРИФИКАЦИЮ аккаунтов знаменитостей, чтобы участники сети точно знали, что посты публикуются действительно этой знаменитостью. В результате верификации в аккаунте знаменитости появляется синий значок с галочкой.

Еще пример. Для того, чтобы стать продавцом на Амазоне, Вам необходимо пройти ВЕРИФИКАЦИЮ личности. Также необходимо пройти верификацию при регистрации аккаунтов во всех платежных системах (Вебмани, Яндекс.Деньги, Киви и т.д.)

Пример из законодательной области

Инициативный депутат решил улучшить жизнь и придумал прогрессивный Закон. Законотворческие органы выполнят ПРОВЕРКУ нового Закона на соответствие другим Законам и международному праву и ВЕРИФИЦИРУЮТ его. Но Закон вступит в силу не сразу, а только через месяц — после его ВАЛИДАЦИИ (придания законной силы) высшим органом законодательной власти. За этот месяц можно отозвать Закон, выявив вред для каких-то КОНКРЕТНЫХ слоев населения.

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

3. РЕГУЛЯРНАЯ ВЕРИФИКАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Программное обеспечение проверяется регулярно (например, каждые 6 месяцев) или после каждого совершенного изменения программной или аппаратной конфигурации, чтобы быть уверенным в том, что результаты останутся неизменными. Для этого используется набор известных данных, а результаты сравниваются со стандартными (Рис. 1). Для того, чтобы помочь оператору, пишется инструкция по верификации со всей необходимой информацией (Рис. 7). Напечатанные, с указанием даты, и подписанные результаты верификации и хранятся вместе с Журналом жизненного цикла ПО. Каждая верификация регистрируется в Журнале жизненного цикла ПО (Рис. 6), с указанием следующей информации: Дата операции, проводимые работы (т.е. верификация), комментарии и подпись оператора.

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

Инструкции по верификации

(прим. переводчика — этот кусочек текста взят с рисунка 7).

Этот документ содержит инструкции по периодическому пересмотру программного обеспечения описанного ниже.Размещение исходного файла: Диск:\Название ПО\имя_файла.xlsВерификация: Все серые ячейки должны быть заполнены и сравнены с шаблоном ниже.

  • Информация: Имя оператора, номер формы и дата верификации.
  • Данные референтного продукта: Высоты.
  • Данные вакцины: Номер серии и высоты для двух серий.

Результаты: Напечатать, указать дату, подписать и сохранить результаты в файл программного обеспечения.Журнал жизненного цикла ПО: Зарегистрировать вашу верификацию в Журнале жизненного цикла ПО.

Рисунок 7. Инструкции по верификации

Используем JavaScript

JavaScript даёт намного больше возможностей для улучшения работы пользователей с формами. Давайте рассмотрим в качестве примера три числовых поля, у каждого из которых установлен минимум в 10, максимум в 100 и шаг в 10 единиц.

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

Стандартный тултип валидации

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

Добавляем несколько сообщений об ошибках в один тултип

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

Примечание переводчика: Слово «mismatch» переводится как «несоответствие». Поэтому в значениях , и обратная логика: — значение не удовлетворяет атрибуту, — удовлетворяет.

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

Теперь при попытке отправить форму мы увидим вот это:

Отображаем несколько ошибок в одном тултипе

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

Это ограничение валидации, устанавливаемое браузером. Чтобы его побороть, нам нужно пойти другим путём.

Показываем все ошибки для всех полей.

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

Этого можно добиться какой-то парой дополнительных строчек в нашем коде:

Вот что происходит при клике на submit теперь:

Отображаем все ошибки для всех полей в DOM

Используем нестандартные проверки валидности

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

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

Валидация в реальном времени

Хотя текущий способ выглядит намного лучше, он тоже не без изъянов. Наихудший из недочётов заключается в том, что пользователь не сможет увидеть никаких сообщений, пока не нажмёт на кнопку отправки формы. Было бы гораздо лучше, если бы валидация поля происходила сразу же при его заполнении. Можно выделить три правила для того, чтобы с формой было удобно работать:

  1. Требования для каждого поля чётко видны до того, как пользователь начал печатать.
  2. Как только пользователь начинает вводить данные, соблюдая требования, он сразу видит индикатор успешного заполнения поля или подсказки, если есть ошибки.
  3. Нужно отображать сообщения об ошибках таким образом, чтобы пользователь не мог отправить некорректно заполненную форму.

В статье на следующей неделе (оригинал, перевод готовится) я покажу, как реализовать валидацию в реальном времени, переделав вот такую простую форму регистрации:

Пример валидации в реальном времени

Если вы хотите попробовать свои силы (и даже сделать получше), вы можете воспользоваться вот этим шаблоном.

Виды валидации

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

  1. Перспективная. Проводится путём изготовления пробных серий и проведения тестов перед запуском производства продукта или выполнения процесса. Её главная задача — проверка соответствия оборудования установленным требованиям. Применяется в основном там, где итоговая верификация затруднена или сопряжена с убытками;
  2. Сопутствующая. В этом случае тесты проводятся непосредственно при изготовлении продукта или выполнении процесса, с учётом минимизации помех для производства. Если результат не соответствует требованиям, утилизируют всю партию товара либо объявляют выданные системой данные ошибочными;
  3. Ретроспективная. Применяется для продуктов, у которых очень много потребителей с разными требованиями. Компания производит партию товара, а затем на основании отзывов пользователей собирает данные о наблюдаемых ошибках и отклонениях от стандарта. При наличии значительных дефектов отзывают всю линейку;
  4. Повторная. Проводится при внесении в процесс производства или структуру системы существенных изменений, не предусмотренных первоначальными требованиями. При осуществлении модификаций необходимо прогнозирование влияния нововведений на стабильность работы и повторяемость результата;
  5. Перекрёстная. Подразумевает проведение проверки работы компонентов системы по частям. Процесс запускают без одной из них, а затем оценивают собранные данные. Процедуру повторяют по количеству частей, получая в итоге наиболее достоверную оценку вероятности возникновения отклонений от начальных требований;
  6. Информационная. Разновидность сопутствующей валидации, которая проводится для моментальной проверки предоставленных пользователем данных. Преимущественно встречается в информационных системах, где по итогам валидации клиент получает доступ к закрытой информации или подтверждает свою личность.

Валидатор Markup Validation Service.

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

После захода на страницу этого сервиса, отобразиться вся его функциональная картинка

Но большая часть изображённого и написанного к основной проверке не относится и всё своё внимание надо обратить только на окно ввода адреса проверяемой страницы:. Вот именно с него и надо начинать

Вот именно с него и надо начинать.

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

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

Но также может быть и такой нежелательный вариант:

Это уже похуже и означает, что во внутреннем коде проверяемой страницы есть какие-то ошибки. Однако, это совсем не смертельно: просто надо прокрутить страницу ниже и там подробно будут написаны все найденные ошибки в процессе проверки.

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

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

В качестве краткого и обобщенного вывода, можно сказать следующее:

  1. данный сервис валидатора работает прекрасно и может очень быстро провести проверку сайта.
  2. Ну и небольшое, но очень приятное дополнение: валидация сайта производиться бесплатно.
  3. Сейчас можно перейти к следующему этапу: это проверка кода CSS.

Виды

Выделяют четыре разновидности валидаций:

  1. Перспективная. Ее выполняют до выпуска и производства продукции. При такой разновидности проводится проверка оборудования, чтобы выяснить: способно ли оно сделать продукцию должного качества, отвечающего требования. Также оценивается возможность производить большое количество товара без сбоев и помех.
  2. Сопутствующая. Она проводится во время производства. Чаще всего, к ней обращаются, когда нет возможности провести до начала серийного производства.
  3. Ретроперспективная или ревалидация. Проверка данного типа проводится, когда товар уже выпущен и может себя показать в работе или применении. Если во время использования возникают неполадки, то серия продукции отзывается с рынка и проводит анализ выявленных несоответствий для улучшения продукции. В ходе такого вида можно проверить продукцию в действии, чего нельзя сделать в других разновидностях. Так выясняются недоработки и дефекты, это нормально и имеет место в любом производстве.
  4. Вторичная. Ее применяют, когда в процесс по изготовлению товаров внесли ряд изменений. Валидация здесь нужна, чтобы протестировать и доказать, что продукт соответствует требованиям, и изменения не ухудшили его качество. При использовании этого вида проверяются документы, технические процессы и сами изготовленные товары.

История

Концепция валидации была впервые предложена двумя должностными лицами Управления по санитарному надзору за качеством пищевых продуктов и медикаментов (FDA), Тедом Байерсом и Бадом Лофтусом, в 1979 году в США для улучшения качества фармацевтических препаратов. Это было предложено в качестве прямого ответа на несколько проблем стерильности парентерального рынка больших объемов . Первые действия по валидации были сосредоточены на процессах, задействованных в производстве этих продуктов, но быстро распространились на связанные процессы, включая экологический контроль, наполнение сред, санитарную обработку оборудования и производство очищенной воды.

Концепция валидации была впервые разработана для оборудования и процессов и основана на инженерных практиках, используемых при поставке крупных единиц оборудования, которые будут изготовлены, испытаны, доставлены и приняты в соответствии с контрактом. Использование валидации распространилось на другие области промышленности после Несколько крупномасштабных проблем выявили потенциальные риски в дизайне продуктов. Наиболее заметным из них является инцидент с Therac-25 . Здесь программное обеспечение для большого радиотерапевтического устройства было плохо спроектировано и протестировано. При использовании несколько взаимосвязанных проблем привели к тому, что несколько устройств дали дозы радиации, в несколько тысяч раз превышающие предполагаемые, что привело к смерти трех пациентов и еще нескольким необратимым травмам.

В 2005 году человек написал стандарт, по которому процесс транспортировки может быть подтвержден для продуктов холодовой цепи . Этот стандарт был написан для компании-производителя биологических продуктов, а затем был включен в Технический отчет № 39 КПК, тем самым установив отраслевой стандарт для валидации холодовой цепи

Это было критически важно для промышленности из-за чувствительности лекарственных веществ, биопрепаратов и вакцин к различным температурным условиям

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

Официальные этапы валидации

Валидация — сложный процесс, который требует четкой методологии. Официально выделяют 6 этапов валидации, которые соответствуют мировым стандартам:

  1. Спецификация требований пользователей. На этом этапе нужно собрать все данные о том, чего ждут пользователи или покупатели от системы, процесса или продукта. Данные собираются различными способами, от прямых вопросов и анкетирования, до масштабного анализа рынка с привлечением специалистов по статистическим данным.
  2. Специализация функций. На этом этапе, на основе предыдущих данных, нужно собрать свое понимание того, каким требованиям и стандартам будет соответствовать продукт, чтобы удовлетворить потребителя.
  3. Спецификация. На этом этапе на основе предыдущих выводов составляется полное описание того, как будет добиваться это соответствие ожиданиям. Все задокументировано, все технические процессы описаны.
  4. Оценка монтажа. Это проверка документов. Насколько все требования и соответствия были выполнены. Показатели сверяются со стандартами, которые были заданы на этапе сертификации.
  5. Проверка функционирования. Здесь уже этап тестов в конкретных условиях. Нужно посмотреть, как будет себя вести конкретный продукт в абстрактных условиях. Не приближенных к реальным, а в целом. И на основе этого сделать выводы о соответствии ожиданий клиентов с реальными показателями.
  6. Проверка эксплуатации. Если предыдущий этап пройден, нужно смотреть, как будет вести себя продукт в условиях эксплуатации. В каком случае он будет соответствовать ожиданиям пользователей, а в каких случаях нет.

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

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

Источник

Где применяется валидация

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

  • Валидация методики. Осуществляется для получения доказательства эффективности используемых способов контроля качества продукта. Например, технология оценки чистоты воды должна выявлять наличие примесей с требуемой точностью;
  • Валидация оборудования. Заявленные характеристики не всегда позволяют понять, как именно будет работать система в реальных условиях. Проверка проводится при введении оборудования в эксплуатацию, а также при перенастройке или ремонте;
  • Валидация процессов. Требование ISO 9001 при изготовлении продукции, дефекты которой нельзя выявить заранее. Валидация в производстве — это простыми словами проверка того, что технологии обеспечивают повторяемость результата;
  • Валидация продукта. Представляет собой продолжение проверки процессов. В данном случае системы и технологические процессы анализируют для поиска отклонений или дефектов, вызывающих изготовление не соответствующего требованиям продукта;
  • Валидация работающих систем. Некоторые производственные процессы и продукты невозможно проверить пробными запусками, так как останавливать их работу нельзя ни в коем случае. Соответственно, проверка корректности проводится на ходу;
  • Валидация данных. Имеет своей целью определение пригодности информации для проведения исследований и анализа. Если сведения соответствуют некоему шаблону или укладываются в рассматриваемый диапазон, то они признаются достоверными;
  • Валидация программного обеспечения. Необходима для определения соответствия программной модели стандартам или картине реального мира. Пример валидации — проверка корректности кода веб-страниц согласно требованиям консорциума W3C;
  • Валидация пользователя. Используется преимущественно для управления доступом к интернет-ресурсам и платёжным системам. Путём ввода персональных данных клиент должен подтвердить свои полномочия на работу с конкретной информацией;
  • Валидация доступа. Смысл здесь тот же: клиент предъявляет электронный документ или ключ для доказательства наличия у него прав на доступ в салон транспорта, на территорию предприятия или в другое закрытое место;
  • Валидация в банке. В отличие от верификации, имеющей своей целью установление личности владельца банковской карты, валидация предназначена для подтверждения возможности применения этого инструмента для совершения конкретного платежа;
  • Валидация навыков. По сути, представляет собой аттестацию. Работники предприятия или учреждения должны подтвердить знания, необходимые для выполнения какой-либо конкретной работы или доступа к определённому виду оборудования;
  • Валидация документов. Встречается в гражданской практике. Представляет собой принятие в качестве нормы, легализацию какого-либо закона, акта, постановления или договора. Также валидации подлежат иностранные патенты.

Принципы верификации

Проверка функциональности необходима для получения доказательств способности продукта или процесса достигать поставленных целей. В неё входят такие критерии:

  • Пригодность. Имеется в виду способность продукта выполнять задачи, которые предписываются ему стандартами и требованиями технического задания;
  • Точность. Необходимо проверить, может ли продукт выдавать результаты с заданной точностью в оговорённом диапазоне входных данных;
  • Безопасность. Здесь нужна верификация не только безопасности пользователя, но и информации, материалов и самой системы;
  • Соответствие. Продукт или процесс должны выдавать предсказуемый результат при использовании оговорённых стандартом условий;
  • Совместимость. Нужно проверить, допускается ли сочетание объекта с товаром или процессами других производителей, также соответствующих стандартам.

Проверка надёжности заключается в тестировании способности товара или процесса поддерживать заданный уровень работы в оговорённых условиях. В неё входят:

  1. Завершённость. Нужно понять, является ли результат применения продукта или процесса достаточным с учетом начальных требований;
  2. Стойкость к ошибкам. Тестирование предполагает проверку функционирования объекта при отклонении входных данных от идеальных;
  3. Устойчивость. Здесь проводится исследование поведения продукта или работы процесса в условиях нестабильной среды;
  4. Способность восстанавливаться. Имеется в виду продолжение выполнения функций после сбоев разной степени критичности.

Проверка удобства пользования выявляет трудности, которые могут возникнуть у пользователей, включая их субъективную оценку. Сюда включаются:

  • Понятность. Включает способность пользователя разобраться в принципах функционирования продукта или процесса;
  • Возможность обучения. Речь идет о диапазоне регулировок, позволяющих адаптировать объект к потребностям разных клиентов;
  • Управляемость. Это верификация возможности управлять продуктом. При хорошей управляемости клиент без труда сменит настройки на желаемые.

Проверка производительности заключается в анализе соответствия результата и объёма израсходованных для его достижения ресурсов. В неё входят:

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

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

  • Лёгкость анализа. Верификация позволяет понять, нужно ли прикладывать усилия для обнаружения требующих корректировки частей объекта;
  • Изменяемость. Демонстрирует сложность и трудоёмкость непосредственного внесения упомянутых изменений для пользователя;
  • Возможность настройки. Сюда входит изучение способности получения нового результата только за счёт настроек, без переделки всего продукта или процесса;
  • Тестируемость. Позволяет определить, насколько легко проверяется правильная работа изменённой части объекта.

Проверка перемещаемости подразумевает анализ возможности переноса процесса или продукта из одной среды в другую. В неё входят:

  • Приспособляемость. Здесь проверяется способность объекта поддерживать нормальную работу при изменении окружающих условий;
  • Уровень адаптации. Речь идёт о возможности использовать продукт как составную часть более сложных объектов разных видов;
  • Согласованность. Это непосредственная проверка продукта или процесса на предмет соответствия отраслевым стандартам;
  • Возможность замены. Подразумевает вероятность применения объекта вместо аналогичного продукта другого производителя.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector