У ЧОМУ ПОЛЯГАЄ ВІДМІННІСТЬ SMOKE, SANITY, REGRESSION, RE – TEST ТА ЯК ЇХ РОЗРІЗНЯТИ?

Всім Привіт!
Мене звати Анастасія, я працюю QA engineer в AllStars-IT Ukraine. В цій статті хочу розповісти про види тестування Smoke, Sanity, Regression та Re – test. Для новачків в тестуванні (і навіть досвідчених тестувальників) розподіл цих понять може бути важким. І справді, як відрізнити де починається Sanity і закінчується Smoke?

Розглянемо ці види тестування:

• Smoke testing – виконується кожен раз, коли ми отримуємо новий білд (версію), проекту (системи) на тестування, при цьому вважаючи її відносно нестабільною. Нам потрібно переконатися, що критично важливі функції AUT (Application Under Test) працюють відповідно до очікувань. Ідея даного виду тестування полягає в тому, щоб виявити серйозні проблеми якомога раніше та відхилити цей білд (повернути на доопрацювання) на ранньому етапі тестування, щоб не заглиблюватися в довгі і складні тести, не витрачаючи тим самим час на свідомо браковане ПЗ. Smoke testing виконується перед регресійним. Мета – перевірити «стабільність» системи в цілому. Може виконуватися автоматизовано або вручну.

• Sanity testing – використовується кожен раз, коли ми отримуємо відносно стабільний білд ПЗ, щоб визначити працездатність в деталях. Націлене на встановлення факту, що певні частини AUT працюють як слід, після мінорних змін або виправлень багів, щоб приступити до більш ретельного тестування. Sanity testing виконується перед регресійним і після smoke – тестів і частіше виконується вручну. Sanity може виконуватися без тест – кейсів, але знання тестованої системи обов’язково.

• Regression testing – власне те, що займає найбільше часу та для чого існує автоматизація тестування. Проводиться регресійне тестування AUT тоді, коли потрібно переконатися що нові (додані) функції програми / виправлені дефекти / свіжі зміни в коді не вплинули на поточну, вже наявну функціональність, яка працювала раніше. Проводиться на підставі вимог проекту і доступності ресурсів, regression testing може проводитися в паралелі з re – test. Кращий привід для автоматизації даного виду тестування, оскільки ручне може бути вкрай витратним за ресурсами або часом. Тест – кейси regression testing можуть бути отримані з функціональних вимог або специфікацій та проводяться незалежно від того, що виправили розробники.

• Re – test – проводиться в разі, якщо фіча / функціональність вже мала дефекти, і ці дефекти були недавно виправлені. Факт того, що дефект виправлений підтверджує Re – Test. Даний вид тестування виконується перед sanity testing на виправленій збірці з використанням тих же даних, на тому ж оточенні, але з різним набором вхідних даних.
Re – test не піддається автоматизації. Він вище регресійних перевірок, тому має виконуватися перед ними. Використовується той же самий тест – кейс, який виявив дефект.

Сподіваюсь, що ця стаття була для вас цікава та корисна буду вдячна за “Like” та за “Share”. Дякую, до зустрічі.

Анастасія Березова
QA engineer в AllStars-IT Ukraine