Что такое регрессионное тестирование?

Регрессионное тестирование — задача, с которой сталкивается каждый тестировщик. Ведь любой предмет после изменений в одном месте может начать ломаться в месте, где раньше работал исправно. То же самое касается и ПО, которое мы тестируем. В этой статье мы чуть-чуть подробнее рассмотрим этот вид тестирования и разберём готовую стратегию, которая поможет сэкономить время, и поддержать качество на нужном уровне.

Что это такое?

Для начала разберём 2 понятия:

Перепроверка (Retest, Defect Validation) — Процесс перепроверки упавших (failed) тестов, связанных с исправленным багом.

Регрессионное тестирование (Regression testing) — Тестирование уже протестированной программы,
проводящееся после модификации для уверенности в том, что процесс модификации не внес
или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после
изменений в коде программного продукта или его окружении.

В чём разница?

Оба вида тестирования выполняются после любых изменений в коде продукта или его окружении.

Retest проверяет ранее упавшие тесты со статусом Failed.

Regression testing проверят ранее пройденные успешно тесты со статусом Passed c целью удостовериться, что изменения не поломали ранее рабочий функционал.

А зачем это делать регрессионное тестирование?

Так получилось, что любое изменение в коде или окружении нашего приложения может вызвать совсем неожиданные последствия.

Нашу систему можно представить как сказку о репке.

И вот мы захотели убрать из истории собачку Жучку, чтобы сэкономить количество текста в сказке.

Как фикс, мы убрали её в моменте, где внучка позвала Жучку.

И вот оказалось, что дальше наша история ломается:

• Жучка должна позвать кошку
• Во всех следующих моментах в сказке написано, что Жучка тянет за внучку, а кошка за Жучку.

Так и получается регрессия, когда наш продукт из-за каких-то небольших изменений может очень серьёзно поломаться иногда даже в очень неожиданных местах.

Какие изменения могут повлечь за собой регрессию?

Изменения в коде:

• Новый функционал
• Исправление дефекта
• Рефакторинг кода
• Обновление версий библиотек

Изменения в окружении:

• Переход на другой сервер или базу данных
• Обновление версии сервера или базы данных
• Изменения в сторонних системах, с которыми интегрируется наше приложение

В идеале, мы должны проводить регрессионное тестирование на каждой новой сборке либо раз в итерацию. Как правило, этот процесс отнимает очень много времени и заставляет грустить многих тестировщиков. Ведь каждый раз нужно проходить одни и те же действия, что делает работу крайне рутинной.

Таким образом регрессионные тесты являются одним из первых кандидатов на автоматизацию.

Как проводить регрессионное тестирование?

Время — это одно из главных наших ограничений.

Поэтому в зависимости от времени мы делаем либо полную регрессию (Complete regression), либо частичную (Partial Regression).
С полной регрессией, думаю, вопросов быть не должно. Мы просто выполняем все тесты, которые у нас есть.
А вот с частичной регрессией всё куда интереснее.

Как выбрать достаточное количество тест-кейсов из общего числа? Не будем же мы брать наугад?

Это, наверное, один из самых важных вопросов в тестировании.
Попробуем на него ответить.

Для выбора тестов мы будем опираться на 2 фактора:

• Сила влияния и важность для приложения (Impact)
  1. Часто используемый функционал
  2. Нечасто используемый функционал
• Вероятность возникновения дефекта (Likelihood)
  1. Места, где были изменения
  2. Места, которые связаны с местами, где были изменения
  3. Сложные места
  4. Другие места

Исходя из наличия времени, берём по одному пункту из каждого фактора в порядке значимости и выбираем тесты, которые им соответствуют.

Например, мы «кровь из носа» должны зарелизиться к определённой дате и у нас очень мало времени на регрессионное тестирование.

В таком случае, мы возьмём тесты, которые проверяют часто используемый функционал и места, где были изменения.

Если времени чуть больше, то берём ещё и часть нечасто используемого функционала и совмещаем с тестами из пункта 2 в Likelihood.

По этой причине со стратегией регрессионного тестирования можно экспериментировать, добиваясь наилучшего для себя результата с доступными ресурсами.

Подытожим:

Retest — перепроверяет упавшие тесты после исправления дефектов.

Regression testing — проверяет ранее положительно пройденные тесты после любых изменений в коде, либо окружении приложения.

Retest & Regression testing нужно делать как можно чаще. Желательно на каждой сборке либо в каждой итерации.