Протоколы испытаний разработаны для того, чтобы проводить различные испытания. Например, цель состоит в том, чтобы подтвердить, что информация о новых пользователях может быть добавлена, модифицирована или удалена из ЛИМС.
9.6.4Требования при проведении испытаний
Имеются функциональные требования, которые испытываются по протоколу испытания. Протокол испытания может быть разработан для более чем одного функционального требования. Любое функциональное требование, которое не было включено в план валидации, не должно быть включено в разработку протоколов испытаний.
9.6.5Специальные потребности или требования
В этом разделе перечисляются специальные пункты, которые необходимы для выполнения протокола испытания, включая специальные навыки, которые должен иметь испытатель, или связи с другими протоколами испытаний или другими приложениями.
9.6.6Процедуры этапов испытания
Каждый этап испытания должен включать номер этапа, процедуру испытания и критерии приемки для этого этапа. Каждый этап испытания должен быть градуирован в соответствии с одной из трех категорий: испытание в обычных условиях (normal testing); испытание в предельных режимах (stress testing); испытание надежности (robustness testing). На этапах испытания в обычных условиях проверяется функция ЛИМС с использованием всех общих пользовательских команд. Этапы испытаний, которые проверяют функцию в ее границах, являются испытаниями в предельных режимах (нагрузочными испытаниями). Примером может являться введение 20 символов в 20 символьных полей. Испытание надежности (устойчивости) представляет собой испытание характеристик за пределами их границ. Например, пароль пользователя может принимать только текстовые знаки или числа, однако испытатель отдает распоряжение для введения специальных знаков или знаков пунктуации для недавно созданного пароля пользователя. Испытатели должны определить, прошел ли этап испытания критерии приемки. Обычно это выражается простым утверждением: да/нет.
9.6.7Раздел комментариев
Данный раздел используется испытателями для введения их комментариев по поводу любых неожиданных результатов, полученных в процессе выполнения протокола испытания. Пользователи также могут отмечать, как эти неожиданные результаты объясняются.
9.6.8Завершение работы испытателя
Испытатель должен подписать и датировать протокол испытания в конце процесса испытания. Если протокол испытания занимает несколько страниц, испытателю следует подписать и датировать ту страницу, на которой указано, когда они завершили этапы испытаний. В некоторых организациях испытатели ответственны за принятие решения в отношении того, проходят ли или терпят неудачу протоколы испытаний. Если протокол испытания не выполнен, испытатели должны документировать в разделе комментариев, почему протокол испытания не был выполнен. Если испытатели приняли какое-либо решение, они также должны его документировать.
9.6.9Завершение работы рецензента
Рецензент протокола испытания должен подписать и датировать протокол испытания только после рассмотрения данных и подтверждения того, что протокол испытания завершен. Если имеются вопросы, рецензент не должен подписывать протокол испытания, пока на эти вопросы не будут получены ответы. В некоторых случаях рецензент несет ответственность за принятие решения относительно того, выполнен или не выполнен протокол испытания. Если протокол испытания не выполнен, рецензент должен использовать раздел комментариев, чтобы объяснить в нем, почему это произошло. Рецензент не должен осуществлять каких-либо изменений в документе. Если изменения должны быть внесены, необходимо связаться с основным испытателем, чтобы осуществить эти изменения.
9.6.10Приложения
Все приложения, которые являются частью выполнения протокола испытания, должны содержать следующую информацию: идентификационный номер протокола испытания; номер этапа; информацию о тех, кто создал приложение; дату, когда приложение было создано. Кроме того, испытатель может изъявить желание выдвинуть на первый план или объяснить отдельные пункты приложения. Любое рукописное изменение, внесенное в отдельный пункт, должно следовать тем же самым критериям, что и протокол испытаний, и включать единообразные действия по оформлению этого пункта, информацию о лице, производящем изменения, дату и причину внесения изменения.
9.7Как только завершается оформление протоколов испытаний, они должны быть отправлены на рассмотрение. После того как они будут рассмотрены и подписаны, они должны быть переданы руководителю команды по валидации. Это облегчит разработку заключительного валидационного отчета. Кроме того, если принимались меры по поводу аварийных отключений идентифицируемой системы, руководитель команды по валидации может начать рассмотрение этих проблем, не препятствуя дальнейшей деятельности членов команды по испытаниям.
9.8Члены команды по валидации могут использовать несколько подходов для решения задач по проектированию и испытанию внедрения ЛИМС. Команда по испытаниям может выразить желание включить следующие дополнительные варианты подходов в проект протоколов испытаний:
9.8.1Управление поставляемыми продавцом диагностическими тестами (поставляемый комплект компонентов/тестов нуждается в валидации перед их использованием).
9.8.2Управление автоматизированными средствами испытания, если они доступны, конкретной ЛИМС (поставляемый комплект компонентов/тестов нуждается в валидации перед их использованием).
9.8.3Регистрация результатов вручную, наряду с ЛИМС, для данного периода времени, и сравнение результатов.
9.8.4Если у ЛИМС имеется телефонный доступ, основательно проверяются меры безопасности, связанные с телефонной связью.
9.8.5Следует ввести ошибки преднамеренно и определить, идентифицирует ли их система должным образом или отклонит их.
9.8.6Следует нагрузить систему искусственно и полностью заполнить ее данными или работать с многими действиями сразу.
9.8.7Если функционирование происходит в среде Windows, то, например, следует открыть все окна сразу.
9.8.8Следует запланировать загрузки больших массивов информации.
9.8.9Следует испытать безопасность путем попытки прерывания или использования запрещенных функций. Следует рассмотреть скрытые алгоритмы входа.
9.8.10Следует попытаться прервать вход, чтобы посмотреть, будет ли система вести себя особым образом.
9.8.11Следует визуально осмотреть интерфейсы и другие компоненты системы, которые производят существенные действия.
9.8.12Следует изменять последовательность загрузки автоматизированных инструментов.
9.8.13Для полноты исследования следует рассмотреть каждый выводящий экран, исправить данные в каждом поле и четко следовать спецификации.
9.8.14Следует использовать технику захвата экрана или технику одновременного нажатия клавиш, чтобы рассмотреть работу системы.
9.8.15Следует испытать все события запусков, принуждая систему к выполнению этих действий. Следует включать класс запланированных событий и в максимально возможной степени класс событий исключения.
9.8.16Следует отключить источник питания от инструментов, связанных интерфейсами, от серверов и других частей системы.
9.8.17Следует использовать протоколы испытаний для исследования работы сети, включая следование протоколу, временным границам и целостности данных.
9.8.18Следует использовать симуляторы инструментов, если таковые имеются в распоряжении, для проверки особых ситуаций и ошибок в интерфейсах.
10 Функционирование (эксплуатация) ЛИМС
(ГОСТ Р ИСО/МЭК 12207*, ГОСТ Р ИСО/МЭК 14764*, ГОСТ Р ИСО/МЭК ТО 15271*, ГОСТ Р ИСО 10006, ГОСТ Р ИСО 10007, ГОСТ Р ИСО 9001, ГОСТ Р 53798)
10.1После того как ЛИМС будет валидирована, начинается эксплуатационное обслуживание системы. На этом этапе члены команды по валидации могут быть распущены. С этого момента лица, ответственные за ежедневную работу системы, должны быть ответственны за поддержание ее в валидированном состоянии. К критическим проблемам, с которыми сталкиваются организация и, что еще более важно, менеджер ЛИМС, относятся следующие:
10.1.1Управление конфигурацией ЛИМС (ГОСТ Р ИСО 10006, ГОСТ Р ИСО 10007)
Цель управления конфигурацией состоит в том, чтобы гарантировать, что определяются и контролируются любые изменения в компьютерном оборудовании, программном обеспечении, сетевых характеристиках, кодах ЛИМС или в любом другом компоненте, который был частью системы при проведении первоначального процесса валидации ЛИМС. Все приложения ЛИМС и платформы аппаратных средств, на которых они размещаются, со временем будут изменяться. Чрезвычайно важно, чтобы организация контролировала и документировала эти изменения. Процедуры по управлению этими изменениями подпадают под управление конфигурацией. Управление конфигурацией начинается в процессе разработки и выполнения операций по квалификации монтажа и функционирования (IQs, OQs) аппаратных средств и программного обеспечения ЛИМС. В это же время валидационная команда создает список всех аппаратных средств и программного обеспечения при монтаже (установке) и конфигурировании ЛИМС, включая номера партий, номера выпуска, серийные (регистрационные) номера и номера версии программного обеспечения. Все эти элементы составляют первоначальную конфигурацию ЛИМС. Они являются базовой совокупностью для управления конфигурацией. Дополнительными элементами, которые должны быть рассмотрены, являются DLLs (Dynamic-Link Library, динамически подсоединяемая или компонуемая библиотека, динамическая библиотека), используемые приложением ЛИМС и любым связанным с ней программным обеспечением. В этом случае пользователь должен прослеживать названия динамической библиотеки, даты установки/написания и версии. Крайне важно гарантировать, чтобы никакое другое программное обеспечение не могло изменить динамические библиотеки, используемые ЛИМС. Цель состоит в том, чтобы показать, что организация управляет ЛИМС; что, как только устанавливается первоначальная конфигурация, все изменения к ней санкционированы, проверены и зарегистрированы. В случае если ответственность за различные элементы конфигурации ЛИМС разделена с другими организационными группами, например по информационным услугам, которые поддерживают инфраструктуру сети, они должны знать, что не могут произвести изменения в своей области ответственности без первоначальной проверки менеджером ЛИМС и руководством организации.
10.1.2Контроль изменений
То, что ЛИМС изменяются, является естественным процессом. Однако в обязательном порядке все осуществленные изменения должны пройти контроль изменений. Контроль изменений включает несколько этапов: запрос на изменение; анализ воздействия; рассмотрение/утверждение; внедрение; валидирование. Организация должна иметь СОП, описывающие процедуры, которыми сопровождаются запросы на изменения. Кроме того, организация должна иметь орган управления, контролирующий изменения, который рассматривает все предложенные средства для контроля изменений. Членство в этом органе управления изменяется в зависимости от организации. К ключевым фигурам относятся персонал подразделения по обеспечению качества (QAU), знакомый с валидацией компьютерных систем, и персонал, относящийся к различным областям бизнеса. Роль органа управления состоит в том, чтобы рассмотреть все предложенные изменения и определить, придерживается ли применяемый подход организационных или нормативных требований. Кроме того, орган управления рассматривает и оценивает воздействия изменения на функционирование ЛИМС. Готовясь принимать решение относительно требований к изменению ЛИМС, следует рассмотреть следующее: будут ли изменения обеспечивать достаточно большие преимущества, чтобы возместить время и ресурсы, необходимые для повторной валидации ЛИМС; на какие другие системы будет воздействовать изменение; сколько времени потребуется для успешного внедрения изменения; какие ресурсы должны быть доступны, чтобы осуществить изменение; какие воздействия не будут приводить к изменениям как в лаборатории, так и в организации. Кроме того, приложениями ЛИМС, которые размещены на сервере, на базе персонального компьютера (ПК), нужно управлять предусмотрительно, потому что пользователь ПК может использовать различные динамически подсоединяемые библиотеки и обновлять их версии в ЛИМС неконтролируемым способом.
10.1.3СОП
См. 11.4 относительно деталей СОП.
10.1.4Эксплуатационные регистрационные отчеты
Организация должна использовать журналы учета, чтобы документировать продолжающуюся в надлежащем режиме эксплуатацию ЛИМС. Отчеты могут быть столь же простыми, как предопределенная форма, которая заполняется и регистрируется, и столь же сложными, как специализированное приложение по ведению протокола. Обычно целью организации является использование регистрации, чтобы привести доказательство контроля над функционированием ЛИМС. В некоторых случаях эти отчеты могут использоваться, чтобы показать отклонения в работе компонентов программного обеспечения или аппаратных средств. Эксплуатационные регистрации должны охватывать следующие области:
10.1.4.1Резервирование регистрационных данных
Этот документ обеспечивает свидетельство того, что приложение ЛИМС поддерживается в соответствии со стандартными операционными процедурами (СОП) организации. Данная регистрация должна содержать следующие пункты, но не ограничиваться ими: кто выполнил резервное копирование; время резервного копирования; уровень поддержки ЛИМС (например, полное резервирование системы, включая ЛИМС и операционную систему, постоянно хранящую ее, или частичное резервирование, где поддерживаются только справочники данных ЛИМС); где хранятся твердые копии и было ли резервирование успешным.
10.1.4.2Регистрация ошибки и ошибочного решения
Организация должна обслуживать регистрацию ошибки и ошибочного решения. Эта регистрация помогает определять, имеются ли тенденции к ошибкам, а также обеспечивает свидетельство того, что к ошибкам обращаются сразу же после их фиксирования. Организация должна определить, может ли она справиться с ошибкой самостоятельно. Если есть способы зафиксировать ее в собственной организации, в дальнейшем организация должна связаться с продавцом ЛИМС. В любом случае организация должна сообщить о предпринятых мерах по исправлению ошибки. Когда ошибки идентифицированы как сбои (дефекты программы), организация должна получить обязательство от продавца по срокам для исправления ошибки. Эти данные должны быть зарегистрированы. Если продавец ЛИМС устанавливает, что ошибка была зафиксирована при модернизации программного обеспечения, организация должна зарегистрировать эти данные. Повторная валидация зафиксированного сбоя должна быть ключевой областью, на которую обращают внимание при проведении повторной валидации после завершения модернизации.