Регресія — що це, чому виникає та як тестувати

Що таке регресія в розробці

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

Термін прийшов із тестування: регресійне тестування — це повторний прогін існуючих тестів після кожної зміни. Якщо раніше успішний тест падає — значить, сталася регресія. У широкому сенсі регресія — це не лише падіння тесту, але й будь-яке погіршення поведінки, помічене користувачем або QA. За даними Tricentis State of Testing 2023, регресії становлять 35–45% всіх багів, знайдених у production.

Від звичайного багу регресія відрізняється часовим контекстом: баг міг існувати завжди, а регресія — це завжди результат зміни. Це важлива відмінність, тому що пошук причини регресії починається з аналізу змін: що було змінено між «працювало» та «перестало працювати». Git bisect — стандартний інструмент для пошуку коміту, що спричинив регресію.

Види регресій та приклади

Локальна регресія — зміна в модулі A ламає функціонал у тому ж модулі A. Приклад: розробник переписує функцію сортування, і вона перестає правильно обробляти порожній масив. Локальна регресія — найпростіша для виявлення та виправлення, оскільки причина та наслідок знаходяться поруч.

Віддалена регресія — зміна в модулі A ламає функціонал у модулі B, який не пов'язаний напряму по коду, але пов'язаний по даних або по часу. Приклад: зміна схеми бази даних у модулі «Користувачі» ламає звіт у модулі «Аналітика», який використовує ту саму таблицю. Віддалені регресії — найпідступніші: розробник не підозрює, що його зміна вплине на інший модуль.

Side-effect регресія — зміна побічного ефекту (логіювання, кешування, надсилання сповіщень) ламає очікувану поведінку. Приклад: розробник додав кешування для прискорення роботи, але через застарілий кеш користувачі бачать застарілі дані. Side-effect регресії складно ловити автоматичними тестами, оскільки побічні ефекти часто не покриті тестами.

Performance регресія — код продовжує працювати коректно функціонально, але повільніше, ніж раніше. Приклад: новий алгоритм шифрування дає ті самі результати, але час виконання зріс із 2 мс до 200 мс. Performance регресії не ловляться звичайними unit-тестами — потрібні бенчмарки та профілювання.

Чому виникають регресії

Перша причина — зв'язаність коду (coupling). Чим сильніше модулі залежать один від одного, тим вища ймовірність, що зміна в одному викличе регресію в іншому. Класичні антипатерни: God Object (об'єкт, який робить все), Shotgun Surgery (зміна одного вимагає правки в десятку місць), Circular Dependency. Зниження coupling — завдання архітектури: SOLID-принципи, Dependency Injection, гексагональна архітектура.

Друга причина — відсутність тестів для змінюваного функціоналу. Якщо код не покритий тестами, розробник дізнається про регресію лише від QA або користувачів. За даними Google Testing Blog, проєкти з покриттям тестів >75% мають у 5 разів менше регресій, ніж проєкти з покриттям <25%. TDD (Test-Driven Development) гарантує, що тести написані до коду, а не «коли буде час».

Третя причина — людський фактор. Розробник не знає про існування суміжного функціоналу, не розуміє всіх залежностей або просто поспішає. Причина — недостатній knowledge sharing кодової бази. Рішення: code review з участю розробників з інших модулів, pair programming, документація архітектури. Bus factor проєкту обернено пропорційний кількості задокументованих архітектурних рішень.

Регресійне тестування та його роль

Регресійне тестування — це процес повторного виконання існуючих тестів після кожної зміни для перевірки, що стара функціональність не зламалася. Це єдиний спосіб гарантувати, що нова зміна не порушила роботу існуючого коду. Без регресійного тестування кожен реліз — це лотерея: розробник сподівається, що нічого не зламав, але не може це підтвердити.

Ручне регресійне тестування — найдорожчий і неефективний підхід. У міру зростання проєкту кількість регресійних тестових сценаріїв зростає лінійно, а час на їх ручний прогін — експоненційно. Через 2–3 роки розробки ручний прогін регресії може займати 2–3 тижні, що робить часті релізи неможливими. Єдиний вихід — автоматизація.

Автоматизоване регресійне тестування ділиться на рівні за пірамідою тестування:

• Unit-тести — швидкі, ізольовані, покривають окремі функції та методи
• Інтеграційні тести — перевіряють взаємодію між модулями, БД, зовнішніми сервісами
• E2E-тести — перевіряють повні користувацькі сценарії через UI або API
• Snapshot-тести — порівнюють поточний вивід компонента з еталонним

За даними Google Testing Blog, оптимальне співвідношення: 70% unit-тестів, 20% інтеграційних, 10% E2E. Відхилення від цієї пропорції знижує ефективність регресійного тестування: надлишок E2E-тестів уповільнює пайплайн, нестача unit-тестів залишає мікробаги непоміченими.

Стратегії автоматизації регресійного тестування

Перша стратегія — Full Regression. Запускаються всі тести проєкту. Найнадійніший, але й найповільніший підхід. Застосовний для невеликих проєктів (до 10 000 тестів, час прогону <30 хвилин). Для великих проєктів full regression може займати години, що робить CI/CD пайплайн непрактичним.

Друга стратегія — Selective Regression. Запускаються лише тести, пов'язані зі зміненим кодом. Для визначення зв'язків використовується dependency graph коду. Інструменти: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression економить 60–80% часу прогону, але вимагає точного побудування dependency graph — помилки призводять до пропущених регресій.

Третя стратегія — Prioritized Regression. Всі тести ранжуються за пріоритетом: critical path (найважливіші користувацькі сценарії), high risk (код з історією багів), changed code (код, зачеплений зміною). Спочатку запускаються найпріоритетніші тести — якщо вони проходять, розробник отримує швидкий зворотний зв'язок. Time-boxed прогін: за 10 хвилин перевіряються critical-тести, решта — у фоні.

Як запобігти регресіям у проєкті

Перший і найважливіший крок — культура написання тестів. Кожна зміна повинна супроводжуватися тестом, який перевіряє, що зміна працює, і тестом, який перевіряє, що нічого не зламалося. TDD (Test-Driven Development) дає найкращі результати: розробник спочатку пише тест, що падає, потім — код, який його проходить. Це гарантує, що тест існує до коду.

Другий крок — CI/CD пайплайн з обов'язковим прогоном тестів. Pull request не може бути змерджений, поки всі тести не пройдені. Не можна «пропустити» тести через терміновість — термінові зміни проходять прискорений, але обов'язковий набір тестів. За даними Google DevOps Research, команди з обов'язковим CI/CD мають у 3 рази менше регресій у production.

Третій крок — моніторинг у production. Навіть найкращі тести не гарантують 100% захисту від регресій. Інструменти observability (Sentry, Datadog, New Relic) повинні відстежувати ключові метрики після кожного деплою: error rate, latency, throughput. Автоматичний відкат (rollback) при перевищенні порогів — подушка безпеки, якщо регресія все ж потрапила в продакшен.

Четвертий крок — code review з регресійним мисленням. Рев'юер повинен ставити питання: «Які ще модулі можуть зламатися від цієї зміни?». Не достатньо перевірити, що код коректний — потрібно перевірити, що він не порушить суміжний функціонал. Чек-лист для code review повинен включати пункт «перевірка на регресії в суміжних модулях».