QA та тестування

Що таке регресійне тестування?

Регресійне тестування (regression testing) — це повторна перевірка функцій, які вже працювали, після змін у коді. Його мета — переконатися, що нова функція чи виправлення помилки не зламали того, що працювало раніше.

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

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

Де застосовується

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

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

Приклад

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

Часті запитання

Чим регресійне тестування відрізняється від повторної перевірки?

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

Як часто треба проводити регресійне тестування?

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

Що робити, якщо регресійне тестування займає забагато часу?

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

Чи можна обійтися без регресійного тестування?

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

Навчання тестуванню в OWU

Опануйте професію QA-інженера на практичних курсах із менторами та реальними проєктами.

Обрати курс