Эволюция качества

Дата: 05 мая 2023 г.

Валидация и верификация методик испытаний (измерений)

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

Андрей Владимирович Горбунов — независимый эксперт по системам менеджмента. Занимается диагностикой и аудитом систем управления, разрабатывает и внедряет системы менеджмента (стаж — более 20 лет). Является автором неофициального перевода ГОСТ ISO/IEC 17025-2019. Ведет авторские курсы и много лет занимается преподавательской деятельностью.

Что такое валидация данных в целом?

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

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

Уровни валидации

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

Проверка ошибок

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

Значение валидации в тестировании

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

Валидация программного обеспечения

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

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

Процесс валидации

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

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

Важность валидации

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

Валидация процессов

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

Основные аспекты валидации процессов

Основные аспекты валидации процессов включают в себя:

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

Применение в различных отраслях

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

Валидация фармацевтического производства

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

Валидация фармацевтического производства

Цель валидации фармацевтического производства (английский перевод: validation of the pharmaceutical manufacturing, немецкий перевод Validierung der pharmazeutischen Herstellung) состоит в том, чтобы убедиться, что процессы производства являются стабильными, контролируемыми и способными обеспечивать высокое качество продукции на постоянной основе. Это критически важный процесс в фармацевтической промышленности, так как качество и безопасность лекарственных препаратов прямо влияют на здоровье пациентов.

Этапы валидации фармацевтического производства

В процессе валидации фармацевтического производства проводятся следующие основные этапы:

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

Валидация и верификация: определения

Логично начать с определений. Стандарт ГОСТ ISO/IEC 17025-2019 так объясняет эти термины:

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

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

Объяснение терминов в простых словах

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

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

Контроль качества на предприятии

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

Допустим, в паспорте указано, что в часах можно погружаться в воду на глубину до 10 метров. А я планирую заняться дайвингом с глубиной погружения до 15 метров.

Штамп ОТК говорит, что до 10 метров точно все будет хорошо. Но мне необходимо понять, сохранят ли часы свою работоспособность на глубине свыше 10 метров. Значит, мне необходимо подтверждение пригодности часов за пределами установленных условий эксплуатации. Выражаясь языком стандарта, мне надо провести валидацию часов для новых условий. А именно получить подтверждение, что и на глубине 15 метров они сохранят свою функциональность. Я могу запросить у разработчиков материалы испытаний или поискать в интернете информацию о том, что кто-то нырял с такими часами на глубину более 10 метров и все было нормально.

Когда требуется верификация методики, а когда валидация

Ситуация № 1

Мы планируем применять стандартную (гостовскую) методику. Сначала определим: мы будем использовать методику в заявленной области применения или за пределами этой области?

Ситуация № 2

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

Чтобы узнать подробности, оставьте заявку на сайте или свяжитесь с нами по телефону: +7 (499) 113-49-59

Валидация форм без зависимостей

Пишем систему валидации форм для React приложений (и не только).

Мотивация

Cтатья основана на практике 2х проектов, которые имели следующие условия, повлиявшие на итоговое решение по реализации фичи валидации:

• И конечно же все некоторые аспекты проектов могли в любой момент измениться (привет agile).
• Всё это привело к формированию следующих требований:

Какой вектор решения выбрать

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

Опыт коллег показал, что в основном, для построения стабильной системы люди выбирали самописные решения, которые строились по формату: одна штука валидирует, вторая штука привязывает это к ui. Благо в тех компаниях, на проектах которых я работал, были тысячи IT специалистов с большим опытом и было куда подглядеть и кого поспрашивать).

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

Оставался только один вопрос – надо пилить вообще всё кастомное или же использовать HTML5 Constraint Validation API. Если ещё не читали этот туториал, то очень рекомендую это сделать.

Размышления были долгими, споры были жаркими и не все ребята на проекте со мной согласились, но проведя сравнительный анализ, всё же было принято решение в пользу разработки полностью кастомной и не завязанной ни на какое API системы. И вот почему:

Единый подход при работе с разными типами проверяемых значенийвсе валидаторы имеют одинаковую структуруДля файлов и подобных штук всё равно выносить нужно в отдельные валидаторы. Часть валидаторов "вшита" в разметку

Разделение логики валидации и логики представления данныхлогика валидации мапится на вью в компоненте могут существовать отдельно друг от другалогика валидации "прибита гвоздями" к html – одно без другого не существует

перенос на веб

перенос на бэк

перенос на мобилки

возможность использовать применять валидацию к нестандартным элементам (канвас например или кастомные элементы)нет, только поддерживаемые спекой форматы https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation#the_constraint_validation_api

Зависимость от браузеразапускаемся где хотимзапускаемся только в браузере и при этом имеем ограничения: 1) ie частично 2) opera mini не поддерживается 3) minlength вообще в ie имеет проблемы и т.п

возможность показывать кастомные ошибки

возможность управлять очерёдностью проверок

возможность делать связанные/динамические поля и валидации

нет, надо писать с нулямногие есть, но что-то чуть посложнее надо писать самому

функция запуска проверокнет, надо писать с нулявсё готово к употреблению

низкий, надо написать пару функций уровня Junior+надо вызубрить всё api

Плюс в спеке так же говорится про кастомные контролы https://developer.mozilla.org/en-US/docs/Learn/Forms/How_to_build_custom_form_controls, что снова кладёт на нашу чашу весов ещё одну монетку.

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

PS: Для сравнения доступности апи как всегда использовался убер ресурс caniuse.com

Структура

Глобально статья состоит из 2х частей: база и react

База Эта часть про систему валидации, которая занимается только валидацией и больше ничем. Максимум независимости от всего, чего только можно. Нам нужен только JS движок для исполнения нашего кода.

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

Валидация значений

Валидаторы это простые функции, задача которых провести соответствующие проверки над переданным в неё значением.

Валидация вынесена в отделяемую абстракцию, для того, чтобы быть независимой от платформы, разметки/визуальных элементов и иметь возможность легко переиспользоваться на node.js (и в любом окружении, где работает js).

Валидаторы

Каждая функция валидатор состоит из 3х частей:

Запуск валидации

Функция validate поочерёдно запускает массив валидаторов с переданным значением.

Данная функция не выполняет "лишней" работы, а останавливается на первом невалидном результате. Т.е. Если в наборе из 4х валидаторов у нас валидатор №1 вернул ошибку, то валидаторы 2, 3, 4 уже не будут запущены в этой итерации валидации (так как в этом нет смысла – пользователю нужно исправить сначала ошибку, которую мы словили на валидаторе №1 и уже после этого переходить в последующим проверкам).

Полный код функции validate:

Пример использования системы валидации

Первое требование реализуется через синхронный валидатор. Второе – через асинхронный (например если реализовывать через img.decode() метод – https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode).

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

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

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

В этом примере значение validationResult равно null, что означает успешно пройденную валидацию по переданному массиву валидаторов. Проверяемое значение value:

Итого

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

Несколько примеров валидаторов с тестами можно найти по ссылке в тестовом репозитории src/validators. Ну а дальше по аналогии пишутся свои валидаторы под ваши нужды (телефоны, мейлы, маскированные инпуты и т.д и т.п.). Главное не забывать про тесты и логика будет легко переносима и управляема в процессе применения в разных проектах)

Валидация форм в React

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

Требования

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

Так же неплохо бы иметь возможность в любой момент проверить наличие ошибок в поле/форме. Это может пригодится в различных более сложных кейсах со связанными и/или динамическими полями.

Триггеры запуска валидации

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

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

Поэтому обозначим несколько ключевых моментов, когда хотим запускать валидацию:

По каждому из этих триггеров мы будем запускать валидацию.

Хук useTextFormField

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

Начнём с того, что запилим хук, который позволяет использовать нам любые текстовые поля (input type text и textarea).

В принципе каждый хук, который в будущем будет отвечать за свой тип поля ввода (например за checkbox или radio button), может расширять анатомию DefaultField по своим потребностям.

Все поля, модели работы с которыми мы будем описывать будут основываться на дефолтном поле:

Для текстовых полей useTextFormField мы расширяем DefaultField следующим образом:

А сам код хука представлен ниже. Он простой как тапок и позволяет легко инкапсулировать в себе модель данных конкретного поля формы:

Хук формы useForm

Хук для текстового поля у нас уже есть, теперь опишем логику отправки формы.

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

Ну и разумеется будем в место вызова хука возвращать краткое описание его текущего состояния через флаг isSending:

Примерчики хуков можно посмотреть здесь src/form-validation-hooks. По ссылке примеры хуков для работы с кастомным селектом, радио группой, инпутом для файлов и для текстовых полей.

Собираем всё вместе

Нам осталось соеденить эти 2 фичи вместе:

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

PS: CSS оставим за скобками наших обсуждений. Предположим что мы все профи в этом деле)) Хотя надо признать, что, как показывает практика, на самом деле очень немногие фронты на самом деле действительно хорошо шарят в css).

Мы имеем лёгку, гибкую систему состоящую из двух частей:

Надеюсь вам было любопытно прочитать про этот подход)

Спасибо за чтение и удачи в реализации вашей валидации (кажется каждый frontend должен запилить за свою карьеру хотя бы раз свою собственную кастомную валидацию)))

PPS: ссылки из статьи

Какие операции валидации данных бывают ?

Операции валидации данных могут включать в себя следующие шаги:

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

Что будет если валидация в тестировании не будет проводиться ?

Если валидация не будет проводиться в процессе тестирования, то это может привести к следующим проблемам:

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