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

Який сенс у забезпеченні якості на виробництві, якщо все виглядає чудово і працює належним чином у постановці?

Зазвичай процес розробки програмного забезпечення потребує віртуальних середовищ, де веб-продукт можна одночасно розробляти і тестувати.

Типова система тестування програмного забезпечення передбачає створення окремого середовища, в більшості випадків це називається [highlight dark=”no”]QA середовище[/highlight](стадіювання), де ви можете нормально перевіряти покращену або перероблену функціональність і бути впевненими, що помилки не будуть помітні кінцевому користувачеві.

Коли потрібне тестування у виробничому середовищі?

Труднощі з розмежуванням постановочного та виробничого середовищ

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

Наприклад, у нас є проект, який використовує довгі тестові скрипти для функціонального тестування середовища розробки. Він не має такого ж технічного фону, як виробниче середовище, але це не заважає виконувати функціональне тестування.

Чому ми не можемо просто скопіювати виробниче середовище на продакшн? Відповідь дуже проста: уявляєте, скільки ресурсів потрібно, щоб скопіювати таку річ, як Facebook, наприклад, з усіма його потужними та продуктивними серверами. Фактично, вам доведеться розгорнути копію такого додатку. Це надзвичайно дорого.

Окремо варто відзначити, що в процесі інтеграції з іншими сервісами користувач отримує різні конфігурації для тестування і реальне технічне середовище (гарним прикладом є використання стороннього API).

Очевидно, що ми не повинні розглядати тестування і постановку середовищ як безглузді речі. Ми просто ніколи не можемо бути впевнені, що якщо тести були успішно виконані в тестовому середовищі, то вони будуть успішними в середовищі інших сервісів.

І тут з’являється тестування на виробництві.

Реальні багаторівневі завдання та технічні проблеми

Деякі групи помилок можна виявити лише після тривалого моніторингу функціональності системи на основі багатозадачності та великого навантаження. Такі ситуації пов’язані зі швидкістю роботи системи, стійкістю програмного забезпечення, стабільністю її функціонування та можливими витоками пам’яті.

Проблеми під час розгортання

Як ми знаємо, [highlight dark=”no”]деплоймент[/highlight] - це спеціальний процес розгортання нової робочої версії програмного забезпечення в інфраструктурі виробничого середовища.

Логічно припустити, що найкращий спосіб знайти помилки під час розгортання - це безпосередньо провести тестування під час розгортання.

Короткий висновок

Ми всі розуміємо, що не можемо знайти всі помилки на виробництві, і навіть найретельніше тестування на стадії постановки не врятує нас від помилок у виробничому середовищі.

І якщо такі недоліки знайдуть клієнти, це може негативно вплинути на репутацію компанії.

І тому [highlight dark=”no”]тестування на виробництві - це “must-have”[/highlight] для будь-якої поважної QA-компанії.