Що таке регресійне тестування?
Регресійне тестування — повторна перевірка вже працюючої функціональності після змін у коді. Його мета — переконатися, що нова функція чи виправлення бага не зламали нічого з того, що раніше працювало.
Потреба виникає через звʼязність коду: правка в розрахунку знижки може несподівано вплинути на формування чека чи звітність. Що більша система, то менш очевидні такі звʼязки й то важливіше регулярно перевіряти старі сценарії.
Регресію проводять перед кожним релізом, і саме вона — головний кандидат на автоматизацію: набір перевірок стабільний, повторюється постійно й вручну займає забагато часу. У зрілих командах регресійний набір запускається автоматично за кожної збірки.
Де застосовується
Регресію проганяють перед кожним релізом, а в командах із частими викочуваннями — при кожній зміні коду через конвеєр CI. Набір збирають із перевірок критичних сценаріїв: вхід у систему, оформлення й оплата замовлення, ключові розрахунки, інтеграції із зовнішніми сервісами.
З часом набір розростається і починає гальмувати випуск версій. Тому його регулярно переглядають: прибирають дублювальні перевірки, розбивають на швидкий прогін для кожної зміни і повний — перед релізом, а найдовші тести запускають уночі.
Приклад
Команда виправила розрахунок знижки для нових клієнтів. Перевірка показала, що знижка рахується правильно — але регресія виявила, що разом із нею зламався розрахунок для постійних покупців, якого виправлення взагалі не стосувалося.
Часті запитання
Чим регресійне тестування відрізняється від ретесту?
Ретест перевіряє, що конкретний дефект справді виправлений. Регресія перевіряє, що це виправлення не зламало нічого навколо. Ретест точковий і короткий, регресія охоплює функціональність, що працювала раніше, і зазвичай виконується набором перевірок.
Як часто потрібно проганяти регресію?
Мінімум перед кожним релізом. Якщо перевірки автоматизовані, їх запускають при кожній зміні коду — це найдешевший спосіб ловити поломки одразу. Ручну регресію через трудомісткість зазвичай проводять за скороченим набором і лише на критичних сценаріях.
Що робити, коли регресія займає забагато часу?
Переглядають набір: видаляють дублювальні й такі, що втратили сенс, перевірки, розставляють пріоритети за ризиками, автоматизують найбільш повторюване. Допомагає й поділ на рівні — швидкі перевірки при кожній зміні, повний прогін рідше, важкі сценарії вночі.
Чи можна обійтися без регресійного тестування?
На разовому проєкті, який більше не змінюватимуть, — так. У живому продукті це найчастіше джерело неприємних сюрпризів: код повʼязаний сильніше, ніж здається, і правка в одному місці регулярно проявляється зовсім в іншому.