Operational Acceptance Testing (OAT) Приклад
Томас Гамільтон
⚡ Розумний підсумок
Operaційне приймальне тестування оцінює, чи готовий реліз до запуску у своєму стандарті. Operaсередовище обробки даних, перевірка резервних копій, відновлення, оповіщення, безпека та документація, перш ніж система буде передана командам підтримки виробництва.
Що таке Operaнаціональні приймальні випробування?
Operaнаціональні приймальні випробування (OAT) – це метод тестування програмного забезпечення, який оцінює операційну готовність програмного застосунку перед його випуском у виробництво. Метою операційного приймального тестування є забезпечення відповідності системи та компонентів вимогам, а також безперебійної роботи системи у її стандарті. Operaекологічне забезпечення (ДП).
Operaційне приймальне випробування також називається OperaТестування готовності до роботи (ORT) або, коротше, операційне тестування. Усі три назви описують одну й ту саму перевірку: програмне забезпечення, можливо, вже виконує те, що вимагає бізнес, проте ніхто ще не довів, що його можуть встановити, створити резервну копію, перезапустити, контролювати та відновити люди, які володітимуть ним після запуску.
Ця відмінність міцно ставить OAT серед нефункціональне тестування типи. Він запитує, як система поводиться в реальних умовах експлуатації, а не чи повертає функція правильну відповідь.
Види Operaнаціональне тестування
Operaційне тестування – це комплексна діяльність. Кожен пункт нижче – це окрема перевірка зі своїми власними умовами входу та власними доказами, і повний цикл OAT зазвичай охоплює більшість із них.
- Тестування установки — підтверджує, що збірку можна встановити, оновити та відкотити в цільовому середовищі, використовуючи надану документацію.
- Тест навантаження та продуктивності Operaції — перевіряє, чи система підтримує очікувану пропускну здатність та час відгуку за обсягів, подібних до виробничих. Див. тестування працездатності та тестування навантаження для основних методик.
- Тестування резервного копіювання та відновлення — доводить, що резервну копію дійсно можна створити за розкладом та відновити до робочого стану, а не просто записати на диск.
- Тестування безпеки — перевіряє засоби контролю доступу, облікові дані, сертифікати та засоби захисту в операційному середовищі. Див. тестування безпеки для детального методу.
- Code Аналіз — статичний огляд наданого коду та конфігурації на предмет зручності обслуговування та відомих моделей слабких місць, перш ніж вони стануть чиїмось виробничим тягарем.
- Перевірка тестування — змушує вузол, службу або сайт вийти з ладу та спостерігає, чи резервна служба переймає роботу в узгоджений час.
- Тестування відновлення — вимірює, наскільки повністю та як швидко система повертається до роботи після збою. Тестування відновлення детально охоплює техніку.
- Кінець в кінець Тестове середовище Operaнаціональне тестування — здійснює керування всім ланцюгом серверів, мереж, завдань та інтерфейсів як єдиним операційним блоком.
- Operaціональна документація Review — перевіряє, чи відповідають протоколи запуску, діаграми обслуговування, накази перезапуску та шляхи ескалації фактично зібраній системі.
На діаграмі нижче ці перевірки групуються навколо релізу, показуючи операційне тестування як останній етап перед тим, як програма потрапляє в робоче середовище.
Чому Operaнаціональне тестування
OperaФункціональне тестування існує тому, що реліз, який задовольняє всі функціональні вимоги, все ще може бути неможливим для запуску.
- Під час OAT вперше об'єднуються конфігурації програмного забезпечення та компоненти операційної підтримки.
- Він тестує впровадження функціональних або структурних змін у програмне забезпечення чи сервіс у функціональному або нефункціональному середовищі.
- Це тестування визначає, чи можна розгорнути застосунок у мережі відповідно до стандартів Бібліотеки ІТ-інфраструктури (ITIL).
- Це показує, чи програмне забезпечення працюватиме так, як воно було розроблено, не порушуючи бізнес-процесів.
- OAT зосереджується переважно на таких аспектах програмного продукту:
- Стійкість
- Здатність до відновлення
- Керованість і можливість підтримки
- Integrity
Хто виконує Operaційне тестування та коли
Володіння OAT відрізняється від усіх попередніх рівнів тестування, і ця різниця пояснює більшість його результатів. Люди, які ним користуються, – це ті, кому телефонуватимуть о третій годині ночі.
- Системні адміністратори та інженери інфраструктури — виконати встановлення, перехід на резервний комп’ютер та перезапустити інциденти в цільовому середовищі.
- Operaта команди підтримки — перевіряти сповіщення, порогові значення, маршрути ескалації та документи щодо вирішення проблем, на які посилається кожне сповіщення.
- Адміністратори баз даних та резервного копіювання — створювати та відновлювати резервні копії, включаючи відновлення на другому сайті.
- Співробітники служби безпеки та дотримання нормативних вимог — підтвердити посилення захисту, контроль доступу та ведення журналу аудиту в середовищі, подібному до реального часу.
- Менеджери тестів — зібрати докази для пакету рішень щодо запуску.
Перейдіть на вкладку життєвий цикл тестування ПЗ, операційне тестування відбувається в самому кінці. Тестування системи доводить, що зібраний продукт працює, тестування користувачами підтверджує, що бізнес його приймає, а OAT потім доводить, що організація може його запускати. Оскільки для цього потрібне середовище, подібне до виробничого, OAT зазвичай планується після заморожування реліз-кандидата — будь-яка зміна коду після цього моменту повертає цикл до початку.
Приклади тестів для Operational Testing або OAT
Нижче наведено зручний контрольний список для виконання OAT. Кожен рядок написаний таким чином, щоб його результат був простим «зараховано» або «не зараховано», що саме потрібно дошці для запуску.
- Резервні копії, створені на одному сайті, можна відновити на той самий сайт.
- Резервні копії, створені на одному сайті, можна відновити на іншому сайті.
- Впровадження будь-яких нових функцій у робоче середовище не впливає негативно на цілісність поточних виробничих сервісів.
- Процес впровадження можна відтворити, використовуючи дійсну документацію.
- Кожен компонент може бути успішно зупинений та запущений у встановлені терміни.
- Щодо сповіщень, усі критичні сповіщення повинні надсилатися до TEC та мати посилання на відповідний документ про вирішення проблеми.
- Сповіщення встановлені та видаються у разі перевищення узгоджених порогових значень.
- Будь-яка документація щодо відновлення, що була складена або змінена, включаючи схеми обслуговування, є дійсною. Її слід передати до відповідних відділів підтримки.
- Для будь-якого компонента, на який вплинув збій, відображається рекомендований порядок перезапуску, час завершення та відповідні залежності.
Практичним доповненням до списку є негативний випадок: навмисно порушити одну залежність, а потім підтвердити, що спрацьовує сповіщення, знайдено робочий модуль, а задокументований порядок перезапуску відновлює службу. Контрольний список, який фіксує лише успіхи, взагалі не перевіряв операцію.
Operaційне тестування проти тестування прийняття користувачами
ОВС та приймальне тестування користувачами обидва є заходами з прийняття, і обидва виконуються із затримкою, тому їх так часто плутають. Вони відповідають на різні запитання та підписуються різними людьми.
| Аспект | Operaнаціональні приймальні випробування (OAT) | Прийнятне тестування користувача (UAT) |
| Відповідь на запитання | Чи може організація запускати та підтримувати цю систему? | Чи відповідає система узгодженим бізнес-вимогам? |
| Виконано | Operaції, інфраструктура та допоміжний персонал | Кінцеві користувачі, зацікавлені сторони бізнесу та клієнти |
| Тип вимоги | В основному нефункціональні — відновлення, резервне копіювання, оповіщення, безпека | Переважно функціональний — бізнес-процеси та правила |
| Навколишнє середовище | Як у виробництві, з реальним моніторингом та інструментами резервного копіювання | Стабільне тестове середовище з репрезентативними даними |
| Типові докази | Відновлення журналів, таймінгів відновлення після відмови, знімків екрана зі сповіщеннями, підписаних книг запуску | Виконані бізнес-сценарії та підписання користувачів |
| Невдача виглядає як | Система працює, але її неможливо відновити, контролювати або перезапустити | Система працює, але не виконує те, що просила компанія |
Ці два варіанти радше доповнюють один одного, ніж є альтернативами. Реліз, який проходить перевірку UAT, але не проходить OAT, – це реліз, який функціонуватиме коректно аж до першого збою.
Переваги та проблеми Operaнаціональне тестування
Команди, які впроваджують OAT, зазвичай посилаються на ті самі переваги та стикаються з тими ж перешкодами.
Переваги
- Ризик збоїв знижується, оскільки шляхи відновлення та перемикання на резервний аварійний режим відпрацьовуються до того, як клієнти почнуть від них залежати.
- Команди підтримки успадковують документацію, яка була перевірена на практиці та не відповідає дійсності системи, а не написана на основі проєкту.
- Несподіванки розгортання виникають у контрольованому вікні, а не вночі запуску.
- Докази відповідності та аудиту створюються як побічний продукт контрольного списку.
Виклики
- Продакшн-подібне середовище є дорогим, а зменшена копія приховує саме ті недоліки, які має знайти OAT.
- Цикл конкурує за той самий календарний простір, що й реліз, тому це перша скорочена діяльність, коли дата зсувається.
- Деструктивні випадки, такі як перемикання на резервний комп'ютер та відновлення, потребують схвалень та тихих вікон, які важко отримати.
- Результати залежать від операційного персоналу, який одночасно працює над поточним сервісом.
Звичайний спосіб пом'якшення наслідків — почати з малого: спочатку автоматизувати випадки резервного копіювання-відновлення та перезапуску, оскільки вони повторюються в кожному випуску та дають найчіткіший сигнал про успішне або неуспішне виконання. Звідти контрольний список може зростати з кожним циклом, і будь-яка зміна в runbook стає кандидатом на регресійне тестування у наступному випуску.
