Різниця між Retesting і Regression Testing — коли що застосовувати

Вітаю! Це моя перша стаття на DOU, тож буду вдячна вашій підтримці та коментарям. Мене звати Тетяна, на позиції QA Manual вже майже 2 роки і зараз працюю у компанії JustCoded.

Пам’ятаю, що на момент пошуку роботи одне з найпоширеніших запитань на співбесіді було про типи тестування, їх різновиди та способи застосування. Тож пропоную у цій статті ознайомитись з двома типами тестування Retesting і Regression Testing, які доволі часто використовуються у роботі тестувальників. Обидва напрямки тестування відносяться до типів тестування, пов’язаних зі змінами у системі/програмі тощо.

Отже, розберемось, за яких обставин ми застосовуємо той чи інший вид тестування та яку роль ці типи тестування відіграють у Software Development Life Cycle.

Що ж позначають та на чому базуються Retesting і Regression Testing

На перший погляд, ці види тестування мають співзвучну назву, проти є доволі різні.

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

Регресійне тестування (Regression testing) — це тип тестування функціональності програмного забезпечення після внесення змін на фазі системного тестування або супроводу продукту. Це робиться для того, щоб розуміти, що продукт нормально працює з новими функціями, виправленнями помилок або будь-якими змінами в існуючій функціональності. Та за результатами регресійного тесту можна підтвердити, що зміни не вплинули на працездатність решти функціональності програми або ж спростувати цей факт.

Коли важливе виконання Retesting та Regression testing та в чому сенс тестування

Як Retesting, так і Regression testing, на мій погляд, найважливіші етапи у життєвому циклі продукту. Перш за все треба враховувати основну мету проведення Retesting — перевірка, чи виправлені виявлені дефекти. Для цього потрібно перевірити виправлення і тестові випадки, які щільно пов’язані з дефектом.

Retesting використовується для:

• перевірки конкретної помилки чи проблеми, на яку був створений bug report;
• для підтвердження від тестувальника для розробника, що проблема дійсна та її можна відтворити повторно;
• або, навпаки, для підтвердження від розробника, що дефект був виправлений;
• і навіть Retesting використовується для тестування всього модуля або компонента з метою підтвердження роботи очікуваної функціональності.

Якщо простіше, Retesting застосовується для перевірки якості будь-якої конкретної функції, компонента чи модуля програми, якщо в цих частинах були виявлені баги.

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

Коли необхідно проводити Regression testing:

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

Переваги проведення Retesting та Regression testing

Нижче наведу декілька переваг для проведення Retesting тестування:

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

Стосовно переваг проведення Regression testing:

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

Недоліки у Retesting

• Для проведення повторного тестування потрібна нова збірка для відтворення відповідного процесу перевірки помилки.
• Під час тестування повторне тестування не може бути комп’ютеризоване.
• Якщо результат повторного тестування невдалий, потрібно більше часу та зусиль для усунення всіх проблем.
• Іноді для усунення помилки потрібна лише незначна зміна коду. Але щоб перевірити одну помилку, розробнику все одно потрібно виконати деплой змін. Це може забирати багато часу.

З якими проблемами може зіштовхнутися QA при проведенні Регресійного тестування

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

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

2. Документація. Постійно оптимізувати тест-кейси в регресійному тестуванні іноді важко. Оскільки масштаб регресійного тестування зростає з кожним спринтом.

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

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

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

4. Environment. Проблеми програмного середовища під час виконання регресії можуть затримувати процес виконання та знижувати концентрацію тестувальників на виявленні та звітуванні про дефекти.

Шлях вирішення: виконання продуктивного регресійного тестування на стабільному, заздалегідь підготовленому середовищі.

Висновок

Можна з впевненістю стверджувати, що існує значна різниця між двома типами тестування: Retesting і Regression Testing. І кожен відіграє свою велику і важливу роль та є необхідним у життєвому циклі програмного забезпечення.

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

Дякую за ваш час та вашу увагу!