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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Вітаю! Це моя перша стаття на 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. І кожен відіграє свою велику і важливу роль та є необхідним у життєвому циклі програмного забезпечення.

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

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось48
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

«Коли необхідно проводити Regression testing:
— якщо на етапі тестування було виявлено багато критичних помилок;»

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

Моє бачення:
регрешн після зміни. Якщо регрешн знайшов баг, то після фікса проводимо ретестінг

Дякую за запитання!

Типу обидва типи тестування проводяться після виявлення помилок?

Re-testing виконується, коли був знайден баг, проте цей баг\дефект може торкатися не тільки конкретное функції, а й компонента чи модуля системи. Але сам процес ретестінгу від цього не змінюється. Перевірка проводиться лише за шагами баг-репорту, який був написан під конкретний баг.
Regression testing може бути розпочат після того, як дуже часто знаходились критичні баги і виправлялись (Retesting). Бо це вже вказує на не стабільність системи і скоріш за все треба перевіряти вже не за конкретними флоу багів. А й функціональність, яка може торкатися данними багами.
Та на мій погляд, виправлення великої кількості багів, особливо критичних, вносить зміни у программу. Але звісно, раціональність проведення регресії у данному випадку, залежить від конкретної ситуації та наявності ресурсів на проєкті. Це більше, як додатковий запобіжний захід, ніж необхідність.

Моє бачення:
регрешн після зміни. Якщо регрешн знайшов баг, то після фікса проводимо ретестінг

Погоджуюсь з вашим баченням.
Re-testing також може бути після регресії, для дефектів, які були виявленні під час регресії.

По суті виходить, що ретестінг — це саме те першочергове та звичне, чим займаються manual qa на усіх без вийнятку проектах ) А ось реально ефективна та якісна регресія реально можлива тільки через автоматизацію цього процеса

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

Крім того, автотести зазвичай не дуже гнучкі

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

Кажуть, після 7 циклів регресії автоматизація виправдовується за ціною

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

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

Та нi, це фантастика ©

’Під час тестування повторне тестування не може бути комп’ютеризоване." — не зовсім зрозумів цей момент, що означає комп’ютеризоване?

Можливо мала на увазі, що повторне тестування не можливо автоматизувати??

А чому не може бути? якщо тести які проходили вперше, були вже автоматизованні(чи автоматизували після першого проходу) і в них знайшлі і завели баги, то після фікса можна прогнати вдруге ці тести

Можна так зробити, але автотест не помітить, якщо фікс зламав щось поруч, на що теста нема. Це може бути непокритий функціонал чи просто верстку, яку зазвичай автотести не покривають

Всі автотести так працюють

Саме тому просто перевірити, що автотест працює недостатньо. І, до речі, не всі. Якщо в пару з функціональним тестом є ще тест, який порівнює скріншоти попіксельно, то руками можна вже і не перевіряти, але то вже утопія

Дякую за питання. Мала на увазі неможливість автоматизувати Retesting тестування.

Підписатись на коментарі