Тестування користувачами (UAT) – перевірка придатності до використання

Ця тема є частиною SG Systems Global глосарій нормативних та операційних термінів.

Оновлено у жовтні 2025 р. • Перевірка комп'ютерної системи та готовність до введення в експлуатацію • Якість, ІТ, виробництво, лабораторія, ланцюг постачання

Тестування прийняття користувачами (UAT) – це остаточна бізнес-перевірка регульованим користувачем придатності налаштованої системи для цільового використання . На відміну від демонстрацій постачальників або технічної кваліфікації, UAT доводить, що реальні користувачі, які працюють за затвердженими процедурами, можуть виконувати комплексні робочі процеси, приймати правильні рішення та створювати відповідні записи з достовірними даними. У життєвому циклі CSV , узгодженому з GAMP 5 , воно відбувається після збірки/конфігурації та контролю якості експлуатації, передує випуску та закріплює очікування регуляторних органів щодо відповідності Частині 11 / Додатку 11 , цілісності даних та операційного контролю.

«Якщо кваліфікація показує, що програмне забезпечення працює, UAT доводить, що ви можете працювати з ним — безпечно, відповідно до вимог, щодня».

1) Що охоплює UAT, а що ні

Охоплює: прийняття налаштованих бізнес-процесів (наприклад, електронне виконання партій у MES , вхід та перегляд зразків у LIMS , комплектування зі складу в WMS ), ролі та дозволи, мітки та звіти, інтерфейси (наприклад, EDI / EPCIS ) та створення відповідних записів (наприклад, eBMR ) згідно з реальними стандартними операційними процедурами (SOP).

Не охоплює: UAT не є кваліфікацією обладнання ( IQ/OQ/PQ ), не є модульним тестуванням постачальника та не є неформальною демонстрацією. Він не замінює тести безпеки, продуктивності або резервного копіювання/відновлення, що виконуються в інших частинах плану CSV, хоча нефункціональні перевірки з високим рівнем ризику можуть бути повторені в UAT для підтвердження експлуатаційної готовності.

2) Регуляторні та системні опори

UAT випливає з принципу CSV, згідно з яким регульована компанія повинна довести цільове використання відповідно до своєї системи якості. Тестери використовують задокументовані процедури в рамках контролю документів , записують результати за допомогою відповідних електронних підписів ( Частина 11 , Додаток 11 ) та фіксують журнали аудиту . План та ризик-база відповідають GAMP 5 ; залишкові ризики спрямовуються до QRM , а зміни регулюються MOC . Докази зберігаються в рамках зберігання записів.

3) Пакет доказів UAT

Повний пакет включає план UAT (обсяг, ролі, критерії входу/виходу), обґрунтування ризиків, сценарії сценаріїв з критеріями прийнятності, попередньо затверджені дані тестування, виконані результати зі скріншотами/додатками, витяги з журналу аудиту, зразки звітів та друковані відбитки етикеток, журнали дефектів та обробку відхилень/NC , докази повторного тестування, матриці відстеження, що пов'язують сценарії з вимогами та ризиками, записи про навчання тестувальників ( Матриця навчання ), ідентифікатори середовища та конфігурації, а також офіційне прийняття в рамках робочого процесу затвердження.

4) Від планування до прийняття — стандартний шлях

План: визначення обсягу, ризиків, сценаріїв, даних, ролей та критеріїв. Готовність: підтвердження завершення контролю якості роботи (OQ), базової лінії конфігурації, стабільного середовища, початкових даних та навчених тестувальників. Виконання: запуску сценаріїв у записаному вигляді; одночасного збору доказів. Сортування: реєстрація дефектів, класифікація впливу, визначення виправлення чи обхідного рішення. Повторне тестування та регресія: перевірка виправлень та захист від поломок. Прийняття: підтвердження критеріїв виходу, остаточне визначення залишкових ризиків та підписання. Випуск: перехід до контрольованого запуску; архівування пакета в розділі Контроль документів.

5) Критерії входу та виходу, що запобігають несподіванкам

Вхід: перевірку якості експлуатації (OQ) пройдено, конфігурацію заморожено, дефекти нижче порогового значення, середовище перевірено та стабільне, тестові дані підготовлено, тестувальники навчені та авторизовані, план UAT затверджено. Вихід: усі критичні сценарії пройдено; відсутні відкриті дефекти рівня серйозності 1; дефекти рівня серйозності 2 пом'якшено задокументованим ризиком та планом; відстеження завершено; звіти/етикетки перевірено; продемонстровано журнали аудиту/електронні підписи; отримано схвалення; зареєстровано результати/не результати з обґрунтуванням.

6) Незалежна аттестація на основі ризику

Застосовуйте QRM для визначення пріоритетів: випуску партій, друку етикеток, міграції даних, змін основних даних, безпеки та затверджень, змін стану запасів та інтеграцій, що впливають на ідентичність або утилізацію продукту. Використовуйте мислення в режимі відмови (що може піти не так?) для розробки негативних та граничних тестів, наприклад, відхилення етикетки з неправильним GTIN , блокування вибору товарів, що перебувають у карантині, або оскарження спроб електронного підпису без необхідних привілеїв.

7) Тестові дані, що виглядають як реальні

Репрезентативні товари, партії, терміни придатності, міцність/розміри, клієнти/постачальники та реалістичні обсяги замовлень. Включайте граничні випадки: дати високосних років, зміни літнього часу, майже лімітовані кількості, багатомовні етикетки та незвичайні робочі процеси (повернення, переробка). Анонімізуйте будь-які конфіденційні дані. Зберігайте повний каталог наборів даних у пакеті UAT, щоб повторні тести були відтворюваними та узгодженими протягом циклів.

8) Ролі, дозволи та журнали аудиту

Доведіть, що кожна роль може робити те, що повинна, і не може робити те, чого не повинна. Спробуйте виконати обмежені транзакції, перевірте режим лише для читання та підтвердьте розподіл обов'язків для критичних кроків (наприклад, розробник/перевірювач для випуску). Продемонструйте поведінку журналів аудиту (хто/що/коли/чому), запитів пароля/електронного підпису, тайм-аутів сеансу та блокування облікових записів. Зафіксуйте витяги як доказ у записі UAT.

9) Інтерфейси, пристрої та мітки

Інтеграція вправ від початку до кінця: сканери та ваги до MES/WMS, LIMS до інструментів, ERP до EDI, упаковка до принтерів етикеток, а також відстеження вихідних даних через EPCIS . Перевірте, чи відповідають етикетки правилам формату та штрих-кодів ( перевірка етикеток ), а також чи правильно поширюються транзакції між системами без втрати даних, дублювання або неправильного зіставлення.

10) Звіти, записи та зберігання

Перевірте всі регламентовані виходи: eBMR, квитанції комплектації/пакування, роздруківки COA, журнали аудиту, управлінські звіти та експорт даних. Перевірте, чи формати, фільтри, часові пояси та десяткова точність відповідають процедурам; чи є PDF-файли незмінними; а чи політики зберігання спрямовують виходи до регульованих репозиторіїв ( Зберігання записів ). Підтвердіть, що пошук та отримання працюють, як описано в SOP.

11) Нефункціональна готовність, яку ви повинні довести

Хоча питання продуктивності та стійкості можуть бути розглянуті в інших місцях, UAT має підтвердити, що рішення придатне для використання за реального робочого навантаження: екрани на пристроях у виробничому цеху відображаються достатньо швидко, пропускна здатність друку етикеток відповідає швидкості лінії, поведінка Wi-Fi в автономному режимі/спокійно з нестабільними показниками є прийнятною, а резервне копіювання/відновлення та перехід на резервний рахунок були продемонстровані принаймні один раз для середовища прийняття зі збереженням доказів.

12) Метрики, що демонструють контроль

• Покриття ризиків: частка високих/середніх ризиків з виконаними сценаріями та успішними результатами.
• Профіль дефекту: поєднання ступеня серйозності, час циклу закриття та коефіцієнт повторного відкриття.
• Стабільність прийняття: відсоток сценаріїв, що проходять після першого виконання; коефіцієнт успішного проходження регресії після виправлень.
• Повнота доказів: сценарії з повними скріншотами, журналами, мітками та витягами з журналу аудиту.
• Готовність тестувальника: частка тестувальників, які пройшли поточну підготовку, згідно з Матриця навчання.

Ці показники роблять рішення щодо прийняття/не прийняття обґрунтованими та показують, чи є прийняття ретельним, чи лише церемоніальним.

13) Поширені помилки та як їх уникнути

• Тільки тестування «щасливого шляху». Розробляти негативні та граничні сценарії на основі аналізу ризиків.
• Нереалістичні або спеціальні дані. Попередньо затверджуйте набори даних; контролюйте їх версії.
• Тільки ІТ-тестувальники. Вимагати від власників бізнес-процесів керівництва виконанням та підписанням.
• Переміщення конфігурації під час UAT. Заморозити збірки; будь-які зміни проходять через MOC з оцінкою впливу.
• Тонкі докази. Одночасно робити знімки екрана, звіти та витяги з аудиторських журналів.
• Відстеження відсутнє. Ведіть матрицю від вимоги/ризику до сценарію, результату та дефекту.
• Сліпі зони інтерфейсу. Доведіть обидві сторони кожної інтеграції, включаючи обробку помилок та повторні спроби.

14) Що належить до запису UAT

Визначити систему та версію; ідентифікатори середовища; затверджений план UAT; список тестувальників та докази навчання; основу ризиків; сценарії сценаріїв; каталоги даних; виконані результати з додатками; зв'язок дефектів/недопущень та CAPA ; записи повторного тестування; матрицю відстеження; акт приймання та протоколи готовності/неготовності; а також посилання на керівні стандартні операційні процедури (SOP) та затвердження . Архівувати з контрольованим доступом та правилами зберігання.

15) Позиція проти IQ/OQ/PQ та Go-Live

IQ/OQ підтверджують, що система встановлена ​​та функціонує відповідно до специфікацій; UAT підтверджує, що ваша організація, використовуючи ваші процедури та дані, може експлуатувати її відповідно до вимог. Деякі галузі поєднують UAT з PQ або розглядають частини UAT як операційну кваліфікацію — важливо, щоб прийняття було власним користувачем, ґрунтувалося на ризиках та було завершено до використання у виробництві.

16) Як це поєднується з V5 від SG Systems Global

Робочий простір та управління UAT. Платформа V5 забезпечує керований робочий простір UAT всередині системи управління якістю: плани та сценарії створюються та затверджуються в розділі «Контроль документів» , а потім проходять через робочий процес затвердження на основі електронного підпису . Доступ на основі ролей розділяє розробників та тестувальників для збереження незалежності.

Виконання з автоматичним отриманням доказів. V5 крок за кроком керує тестувальниками та автоматично фіксує докази — знімки екрана, зображення етикеток, витяги з аудиторських журналів та PDF-файли звітів — зберігаючи їх із незмінними метаданими для задоволення вимог ALCOA(+) . Там, де UAT охоплює модулі (наприклад, MES , WMS та LIMS ), міжсистемні докази об'єднуються в одне досьє.

Дефекти до CAPA. V5 перетворює дефекти UAT на записи про якість: критичні висновки можуть бути безпосередньо передані до CAPA , тоді як незначні елементи потрапляють до портфеля з видимістю ризиків. Повторні тести пов'язані між собою, тому закриття можна перевірити.

Покриття та відстежуваність на основі ризиків. Сценарії UAT пов'язані з реєстром ризиків ( QRM ), вимогами та налаштованими об'єктами. V5 генерує матриці відстеження в реальному часі та панелі інструментів покриття, щоб показати, які функції з високим рівнем ризику мають перевірені докази.

Інтеграційні системи етикеток та етикеток. Для штрих-кодів/етикеток V5 інтегрується з перевіркою етикеток , тому зразки друку та оцінки додаються автоматично. Інтерфейсні заглушки перевіряють корисні навантаження EDI/EPCIS та події пристроїв у цеху, не піддаючи жодної зовнішньої залежності з першого дня.

Видача та зберігання. Після завершення прийняття V5 видає пакет «придатний/непридатний» з усіма дозволами, потім блокує та архівує досьє в розділі «Зберігання записів» . Подальші зміни мають пройти через MOC і можуть ініціювати цільову повторну перевірку UAT за ризиками.

Підсумок: V5 робить UAT повторюваним, орієнтованим на ризики та готовим до перевірок, перетворюючи прийняття з набору скріншотів на регульовану, повну історію придатності до використання.

17) FAQ

Q1. Хто має очолювати UAT?
Власники бізнес-процесів перебувають під наглядом служби контролю якості. ІТ-відділ підтримує середовище та інструменти, але прийняття має бути орієнтованим на користувача, щоб задовольнити очікування щодо використання.

Q2. Чим UAT відрізняється від OQ?
OQ (Operation Quality Quality - контроль якості) – це технічна перевірка на відповідність функціональним специфікаціям, часто за ініціативою постачальника або ІТ-фахівців. UAT (User Atta - перевірка бізнес-процесів від початку до кінця) – це бізнес-перевірка наскрізних процесів згідно зі стандартними операційними процедурами (SOP) з використанням реальних даних та рішень.

Q3. Чи потрібен нам негативний результат тесту?
Так, особливо для засобів контролю з високим рівнем ризику (наприклад, блокування статусу, перевірки електронних підписів, невідповідності міток). Негативні тести доводять, що система запобігає небезпечним або невідповідним діям.

Q4. Чи можемо ми змінити конфігурацію під час UAT?
Тільки через контрольований MOC з оцінкою впливу та повторним тестуванням. Неявні зміни підривають достовірність доказів.

Q5. Які докази є важливими для Частини 11/Додатку 11?
Демонстрації унікальних облікових записів користувачів, прив’язки електронного підпису, журналів аудиту з позначками часу, цілісності записів та належного захисту/зберігання — зафіксовані як артефакти в пакеті UAT.

Q6. Скільки UAT достатньо?
Достатньо, щоб покрити всі високі/середні ризики з належними доказами, всі критичні робочі процеси та інтерфейси, а також усі регульовані результати, із задокументованими залишковими ризиками та їх прийняттям відповідними особами, що їх затверджують.

Пов'язане читання
• Валідація та управління: CSV | GAMP 5 | Документ контрольний | Робочий процес затвердження | Розширення QRM
• Основи відповідності: 21 CFR ч. 11 | Додаток 11 | Аудиторський слід | цілісність даних | Зберігання записів
• Контексти виконання: МНС | LIMS | WMS | еБМР | Перевірка етикетки | EPCIS