Протокол квалификации функционирования (OQ)

СТАНДАРТНАЯ ОПЕРАЦИОННАЯ ПРОЦЕДУРА

Протокол квалификации функционирования (OQ) системы\ «n-tst.ru»

Номер СОП: СОП-КС-03

Версия: 1.0

Дата эффективности: 01.11.2026

Планируемая дата пересмотра СОП: 01.11.2028

           ФИО   Должность                                 Подпись   Дата

Утвердил Генеральный директор
Разработал Специалист по клиническим исследованиям

История изменений документа

Версия Дата эффективности Изменения Необходимость тренинга

СОП-КС-03, версия 1.0 01.11.2026 Первоначальный документ. Да

  1. НАЗНАЧЕНИЕ ПРОЦЕДУРЫ

Настоящий Протокол определяет перечень тестовых сценариев (OQ) для проверки функционирования системы «n-tst.ru» на соответствие требованиям Технического Задания (ТЗ) и минимизации рисков, выявленных в СОП по Оценке рисков. Протокол является приложением к Плану валидации.

  1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Процедура применима к тестированию Production-среды (или Staging-среды с конфигурацией, идентичной Production) перед началом набора пациентов в клиническом исследовании.

  1. НОРМАТИВНО-ПРАВОВАЯ БАЗА

  2. Решение Совета Евразийской экономической комиссии № 63 от 01.08.2025 г. «О Правилах надлежащей клинической практики Евразийского экономического союза»

  3. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition).

  4. ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

Термин Определение

OQ Operational Qualification (Квалификация функционирования). Тест-кейс Конкретный шаг тестирования с ожидаемым результатом. Баг Выявленное несоответствие работы системы ожидаемому результату.

  1. ОБЯЗАННОСТИ

  2. Тестировщик (QA или Администратор): Выполняет тест-кейсы, фиксирует результаты (Пройдено / Не пройдено) и описывает выявленные баги.

  3. Разработчик: Устраняет выявленные баги и предоставляет обновленную версию для повторного тестирования.

  4. Владелец системы: Утверждает Протокол после успешного закрытия всех тест-кейсов.

  5. ОПИСАНИЕ ПРОЦЕДУРЫ

6.1. Инструкция по проведению тестирования

Для каждого тест-кейса тестировщик выполняет шаги, описанные в колонке «Действие», и сравнивает результат с колонкой «Ожидаемый результат».

  • Если результат совпадает, в колонке «Результат» ставится отметка «Пройдено».

  • Если результат не совпадает, ставится «Не пройдено», и заполняется форма отклонения (баг-репорт).

  • После исправления бага тест-кейс выполняется повторно.

6.2. Матрица тест-кейсов OQ (Приложение 2).

Цель: подтвердить работоспособность общих функций системы «ИРК» и её готовность к использованию в клиническом исследовании.

Инструкция: для каждого кейса выполните шаги и отметьте результат. В случае ошибки создайте Bug Report (Приложение 1).

6.3. Действия при выявлении несоответствий

В случае если тест-кейс не пройден, создается запись в Журнале отклонений (Deviation Log). Тестирование приостанавливается до устранения дефекта разработчиком. После устранения дефекта проводится повторное тестирование (Retest).

  1. ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ

Приложение 1. Форма Журнала выявленных отклонений (Bug Report).\ Приложение 2. Матрица тест-кейсов (oq / pq protocol).

Приложение 1. Журнал выявленных отклонений (bug report).

Номер дефекта: BUG-[Год]-[Номер] (например, BUG-2026-001)\ Дата выявления: [ДД.ММ.ГГГГ]\ Тестировщик: [ФИО]\ Среда тестирования: [ ] Staging / [ ] Production

1. Общая информация

+-------------------------------+------------------------------------------------------------+ | > Параметр | > Значение | +===============================+============================================================+ | > Модуль/Функция: | > (например: Конструктор блоков, Экспорт в CSV, Валидация) | +-------------------------------+------------------------------------------------------------+ | > Критичность (Severity): | > [ ] Критический (Блокирует работу)\ | | | > [ ] Высокий (Ломает логику)\ | | | > [ ] Средний (Ошибка интерфейса)\ | | | > [ ] Низкий (Опечатка) | +-------------------------------+------------------------------------------------------------+ | > Приоритет (Priority): | > [ ] Немедленно / [ ] Высокий / [ ] Обычный | +-------------------------------+------------------------------------------------------------+ | > Связанный тест-кейс: | > (например: OQ-03, PQ-01) | +-------------------------------+------------------------------------------------------------+

2. Описание проблемы

  • Ожидаемое поведение: (Что должно было произойти согласно ТЗ?)

  • Фактическое поведение: (Что произошло на самом деле?)

  • Шаги для воспроизведения:

    1. Зайти в...

    2. Нажать...

    3. Ввести...

  • Прикрепленные файлы: (Скриншоты, логи из консоли браузера, дампы БД)

3. Исправление и верификация (Заполняется разработчиком и QA)

+--------------------------------------------+-----------------------------------------------------------------------------------+ | > Параметр | > Значение | +============================================+===================================================================================+ | > Ответственный разработчик: | > [ФИО] | +--------------------------------------------+-----------------------------------------------------------------------------------+ | > Статус: | > [ ] Открыт / [ ] В работе / [ ] Исправлен (Fixed) / [ ] Закрыт (Closed) | +--------------------------------------------+-----------------------------------------------------------------------------------+ | > Корневая причина (Root Cause): | > (Краткое описание, почему произошла ошибка) | +--------------------------------------------+-----------------------------------------------------------------------------------+ | > Дата исправления: | > [ДД.ММ.ГГГГ] | +--------------------------------------------+-----------------------------------------------------------------------------------+ | > Результат повторного теста (Retest): | > [ ] Пройдено / [ ] Не пройдено | +--------------------------------------------+-----------------------------------------------------------------------------------+ | > Подпись QA (закрытие дефекта): | > _____________ / [ФИО] / [Дата] | +--------------------------------------------+-----------------------------------------------------------------------------------+

Приложение 2. Матрица тест-кейсов (oq / pq protocol).

Раздел 1. Базовые настройки системы (Setup)

ID Действие Ожидаемый результат Статус

SETUP-01 Создание нового Исследования (Study) в админ-панели. Исследование создается, присваивается ID, сохраняются настройки (название, протокол). [ ] OK SETUP-02 Создание Клинического центра (Center). Центр привязывается к исследованию, присваивается номер. [ ] OK SETUP-03 Создание пользователей (Врач, Главный исследователь, Монитор). Пользователи создаются, получают роли, привязываются к центрам. [ ] OK

Раздел 2. Конструктор визитов и библиотека блоков (Builder)

ID Действие Ожидаемый результат Статус

BUILD-01 Создание нового пользовательского блока (например, «УЗИ») в библиотеке. Блок появляется в списке, тип «Пользовательский». [ ] OK BUILD-02 Редактирование встроенного блока (изменение типа поля, добавление min/max). Изменения сохраняются, блок помечается как «Измененный». [ ] OK BUILD-03 Сброс встроенного блока к эталону (кнопка «Сбросить»). Настройки возвращаются к заводским, метка «Измененный» исчезает. [ ] OK BUILD-04 Добавление созданного блока в структуру Визита (например, Визит 1). Блок отображается в списке блоков визита. [ ] OK BUILD-05 Публикация визита (Кнопка «Опубликовать»). Система компилирует JSON, ошибок нет, создается новая версия. [ ] OK

Раздел 3. Управление пациентами (Patients)

ID Действие Ожидаемый результат Статус

PAT-01 Создание карты нового пациента врачом. Карта создается, присваивается ID. Админ не может создавать карты. [ ] OK PAT-02 Ввод ФИО, пола, даты рождения. Расчет возраста. Возраст рассчитывается автоматически и корректно. [ ] OK PAT-03 Присвоение скринингового номера. Номер сохраняется, отображается в списке пациентов. [ ] OK PAT-04 Попытка присвоить существующий скрининговый номер другому пациенту. Система выдает ошибку уникальности (дубликат запрещен). [ ] OK PAT-05 Очистка поля скринингового номера. Номер удаляется из карточки пациента и из списка. [ ] OK

Раздел 4. Ввод данных и Валидация (Data Entry)

ID Действие Ожидаемый результат Статус

DATA-01 Заполнение формы визита (Основные данные, Жалобы и т.д.). Данные сохраняются при нажатии кнопки «Сохранить». [ ] OK DATA-02 Проверка автосохранения (отключить интернет на 10 сек, ввести текст, включить). Данные восстанавливаются, статус «Сохранено». [ ] OK DATA-03 Ввод в обязательное поле (Required) пустого значения. Система выдает ошибку, сохранение блокируется. [ ] OK DATA-04 Ввод числа вне диапазона (min/max), например, рост 300 см. Система выдает предупреждение, подсвечивает поле. [ ] OK DATA-05 Ввод текста в поле с валидатором regex (например, буквы в поле для цифр). Ввод блокируется или выдается ошибка формата. [ ] OK DATA-06 Проверка парных полей (eye-pair) для Левого/Правого глаза. Создаются две отдельные колонки/поля, данные сохраняются независимо. [ ] OK DATA-07 Заполнение карты на 100%. Проверка зеленого статуса «Завершено». Флаг is_complete в БД становится true, бейдж в списке зеленеет. [ ] OK

Раздел 5. Проверка специфичных блоков (Protocol-Specific) --- Заполняется под конкретное исследование

ID Действие Ожидаемый результат Статус

PROT-01 (Пример) Визит 0: Проверка блока «Офтальмологический анамнез» (заполнение всех полей). Все поля сохраняются, расчет ИМТ корректен. [ ] OK PROT-02 (Пример) Визит 1: Проверка блока «Рандомизация» (ввод номера, привязка слота). Пациент рандомизирован, номер отображается в карточке. [ ] OK PROT-03 (Пример) Дневник пациента: Ввод данных за 6 дней. 24 ячейки (6 дней х 4 закапывания) сохраняются корректно. [ ] OK PROT-04 (Пример) Визит 4: Блок «Лабораторные исследования» (проверка расчета лейкоцитарной формулы). Сумма процентов не выдает ошибку, если в пределах нормы. [ ] OK

Раздел 6. Экспорт и Отчетность (Export)

ID Действие Ожидаемый результат Статус

EXP-01 Экспорт одного пациента в Excel. Файл скачивается, заголовки колонок соответствуют формам. [ ] OK EXP-02 Массовый экспорт всех завершенных пациентов в CSV. Выгружаются только пациенты с is_complete = true. Кодировка UTF-8 с BOM. [ ] OK EXP-03 Проверка целостности данных (сверка файла с БД). Запуск скрипта validate_export.py подтверждает 100% совпадение строк и номеров. [ ] OK EXP-04 Формирование Отчета мониторинга (HTML/PDF). Отчет генерируется, содержит актуальные данные по центрам. [ ] OK

Раздел 7. Безопасность и Аудит (Security & Audit)

ID Действие Ожидаемый результат Статус

SEC-01 Вход в систему с неверным паролем (3 раза подряд). Учетная запись блокируется (защита от брутфорса). [ ] OK SEC-02 Проверка Audit Trail: изменение значения в поле. В журнале audit_log фиксируется старое и новое значение, кто и когда изменил. [ ] OK SEC-03 Попытка доступа к админке под ролью «Врач». Доступ запрещен (ошибка 403 / редирект). [ ] OK

Итоговое заключение QA:

Все критические и высокие риски проверены. Выявленные дефекты (Bug ID: _______) исправлены и перетестированы. Система готова к валидации PQ (эксплуатация).

Подпись тестировщика: _____________ / [ФИО] / [Дата]