Регрессионное тестирование: что это простыми словами

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

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

Регрессионные тесты проверяют не только прежние функции, но и связанные модули, интеграции и пользовательские сценарии, на которые могли повлиять изменения.

Разберём, что такое регрессионное тестирование в QA, какие виды проверок существуют, когда их проводить и как выбрать подходящие тест-кейсы.

Что такое регрессионное тестирование и зачем оно нужно

Regression testing — это повторная проверка ранее протестированной функциональности после изменений в программном обеспечении. Основная задача — найти дефекты, возникшие после изменений и нарушившие работу существующих функций.

Регрессионное тестирование нужно, чтобы проверить:

• Не сломались ли функции, которые раньше работали корректно.
• Не вернулись ли ранее исправленные ошибки.
• Не нарушилось ли взаимодействие между модулями.
• Сохранилась ли работоспособность интеграций с внешними сервисами.
• Не повлияли ли изменения на критические пользовательские сценарии.

Откуда берутся регрессионные ошибки

Регрессионные ошибки могут возникать и за пределами изменённого модуля. Например:

• Разработчик поменял общий метод, который используют несколько компонентов.
• Изменили структуру базы данных, а старый запрос перестал работать.
• Обновили библиотеку, и она изменила поведение отдельных функций.
• Переработали авторизацию, из-за чего пользователи перестали входить через сторонний сервис.
• Изменили конфигурацию сервера, и приложение стало работать иначе.

Чем больше зависимостей между компонентами, тем сложнее заранее определить, какие функции затронут изменения.

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

Когда проводится регрессионное тестирование

Регрессию проводят на разных этапах разработки и сопровождения ПО, а не только перед релизом.

Регрессионные тесты проводят в следующих случаях:

1. После исправления бага. Проверяют, что ошибка устранена, а связанные функции продолжают работать.
2. После добавления функциональности. Например, в приложении появилась оплата через СБП. Помимо новой функции проверяют существующие способы оплаты и оформление заказа.
3. После рефакторинга. Код меняется без намеренного изменения поведения, поэтому важно убедиться, что внешние результаты остались прежними.
4. После обновления зависимостей. Проверяют совместимость библиотек и компонентов.
5. После изменения базы данных или API. Особое внимание уделяют интеграциям и обработке данных.
6. Перед выпуском версии. Команда проверяет критичные сценарии и функциональность, которую могли затронуть изменения.
7. После изменений окружения. Например, при переносе приложения на другую инфраструктуру или обновлении операционной системы.

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

На каком этапе не проводится регрессионное тестирование

У регрессии нет единственного обязательного этапа жизненного цикла разработки, на котором она должна выполняться. Ее можно проводить при разработке, тестировании, выпуске и сопровождении продукта.

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

Виды регрессионного тестирования

Команды классифицируют регрессию по объёму проверок, способу отбора тестов и характеру изменений. Единой классификации для всех проектов нет.

Полная регрессия

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

Метод используется, когда:

• Изменения затрагивают архитектуру.
• Обновляется крупная зависимость.
• Нельзя надежно определить область влияния правок.
• Выпускается значительное обновление.

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

Выборочная регрессия

Команда выбирает тест-кейсы для изменённых компонентов и функций, которые зависят от них.

Например, если поменялся модуль формирования чека, проверяют:

• Расчёт стоимости.
• Применение скидок.
• Налоговые суммы.
• Формирование чека.
• Возвраты, если они используют изменённую логику.
• Соседние процессы, которые зависят от этого модуля.

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

Приоритетная регрессия

Тесты выполняют в порядке важности. Сначала проверяют сценарии, сбой которых сильнее влияет на пользователей или бизнес.

Например, для интернет-магазина приоритет могут получить авторизация, оформление заказа и оплата. Проверка редкой настройки профиля может подождать.

Приоритетная регрессия определяет порядок выполнения тестов. Набор может остаться полным, даже если сначала проверяют только самые важные сценарии.

Корректирующая и прогрессивная регрессия

В учебных материалах также выделяют корректирующую и прогрессивную регрессию.

• Корректирующий подход применяют, когда требования и существующее поведение существенно не меняются. Команда может использовать прежние тест-кейсы.
• Прогрессивный подход нужен, когда функциональность меняется или расширяется. Тесты приходится дополнять новыми сценариями.

Это не обязательные этапы регрессии. На одном проекте могут одновременно происходить изменения, требующие обоих подходов.

Регрессионное, функциональное и smoke-тестирование: отличия

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

Регрессионное и smoke-тестирование не заменяют друг друга. Smoke обычно представляет собой короткую проверку основных функций. Он помогает понять, можно ли переходить к более глубокому тестированию.

Например, после сборки приложения тестировщик проверяет запуск, авторизацию и открытие каталога. Если эти сценарии проходят, можно переходить к регрессии: проверять поиск, фильтры, корзину, оплату и другие процессы.

Smoke-тесты могут входить в регрессионный набор, если проверяют функции, которые уже работали до изменений.

Регрессионное тестирование и повторная проверка бага

Например, пользователь сообщил, что скидка не применяется к заказу. После исправления нужно проверить и сам дефект, и связанные функции. 

После исправления выполняют две группы проверок:

• Повторное тестирование: тестировщик повторяет сценарий, который раньше выявлял ошибку. Нужно подтвердить, что дефект устранён.
• Регрессионное тестирование: тестировщик проверяет, не сломались ли другие сценарии расчёта стоимости, например применение промокода, доставка и возврат.

Обе проверки нужны. Успешное повторное тестирование не доказывает, что изменения не вызвали побочных эффектов. Такое разделение соответствует терминологии ISTQB.

Как проводится регрессионное тестирование: этапы

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

1. Изучить изменения. Получить описание задачи, список изменённых компонентов и требования.
2. Определить область регрессии. Оценить зависимости, риски и возможные побочные эффекты.
3. Отобрать тест-кейсы. Выбрать проверки, подготовить данные и окружение.
4. Выполнить тесты. Запустить smoke при необходимости, затем выбранный регрессионный набор.
5. Проанализировать результаты. Разобрать ошибки, проверить логи, исключить ложные срабатывания.
6. Повторить проверки после исправлений. Проверить устранение дефектов и при необходимости обновить объём регрессии.

Разберём отдельные этапы подробнее.

1. Анализ изменений

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

Важно определить область правок и все их зависимости.

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

2. Выбор тест-кейсов

Тестировщик отбирает сценарии из существующего набора. Если проверок недостаточно, добавляет новые.

Приоритет зависит от нескольких факторов:

• Критичность функции для пользователя.
• Вероятность появления дефекта.
• Частота использования сценария.
• Сложность и масштаб изменений.
• Количество зависимых компонентов.
• История ошибок в этой области.

3. Подготовка тестового окружения и данных

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

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

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

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

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

4. Выполнение тестов и анализ результатов

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

При обнаружении ошибки проверьте: 

• Шаги воспроизведения.
• Ожидаемый и фактический результат.
• Версию сборки и окружение.
• Логи приложения и сетевые запросы.
• Состояние тестовых данных.

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

После анализа тестировщик оформляет дефект и передаёт его команде разработки.

Пример регрессионного тестирования

Рассмотрим интернет-магазин, в котором разработчики изменили правила применения промокодов.

Раньше покупатель мог применить скидку 10% к подходящему товару. Теперь добавили ограничения: промокод не действует на товары из определённой категории.

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

Последний сценарий важен, корзина может показывать правильную стоимость, а сервер при создании заказа — использовать старую логику расчёта.

Регрессионное тестирование: пример с обязательным полем

Рассмотрим форму регистрации. Разработчик сделал поле «Телефон» обязательным.

Регрессионные тесты должны подтвердить, что поле телефона обязательно и что остальные сценарии регистрации работают по-прежнему.

Тест-кейсы:

1. Отправить форму без телефона. Система должна показать ошибку валидации.
2. Ввести корректный телефон. Регистрация должна пройти при соблюдении остальных условий.
3. Ввести некорректный номер. Форма должна отклонить значение согласно правилам валидации.
4. Проверить регистрацию с существующим email. Система должна корректно обработать дубликат.
5. Проверить восстановление пароля и вход в существующий аккаунт.

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

В реальном тестировании нужно учитывать, где выполняется валидация: на клиенте, сервере или обоих уровнях.

Сколько времени занимает регрессионное тестирование

Предположим, в проекте есть 240 регрессионных тест-кейсов.

• 60 критичных сценариев выполняются в среднем за 2 минуты.
• Остальные 180 занимают в среднем 3 минуты.

Полный последовательный прогон:

60 × 2 + 180 × 3 = 660 минут.

Это 11 часов чистого выполнения тестов без учёта подготовки, анализа результатов и исправления ошибок.

Если команда выбрала 80 тестов со средней длительностью 3 минуты, проверка займёт 240 минут, или 4 часа.

Экономия составляет 7 часов выполнения.

Автоматизация регрессионного тестирования

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

Автоматизировать можно проверки на разных уровнях:

• Модульные тесты. Проверяют отдельные функции и классы.
• Интеграционные тесты. Проверяют взаимодействие компонентов и сервисов.
• API-тесты. Проверяют контракты, статусы ответов, структуру данных и бизнес-логику.
• UI-тесты. Проверяют пользовательские сценарии через интерфейс.

Для автоматизации применяют разные инструменты:

Как встроить регрессию в CI/CD

Типичный сценарий автоматизации выглядит так:

1. Разработчик отправляет изменения в репозиторий.
2. CI собирает приложение и запускает быстрые проверки.
3. Выполняются модульные и интеграционные тесты.
4. При необходимости запускается smoke-набор.
5. На тестовом окружении выполняются выбранные регрессионные сценарии.
6. Результаты передаются команде.

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

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

Какие ошибки допускают при регрессионном тестировании

Даже формально пройденная регрессия не всегда говорит о хорошем качестве проверки.

• Слишком маленький набор тестов. Команда проверяет только изменённую функцию, забывая о связанных компонентах.
• Устаревшие тест-кейсы. Сценарии описывают старые требования и ожидаемые результаты. Из-за этого реальные дефекты могут оставаться незамеченными.
• Неподготовленные данные. Результаты зависят от состояния базы, предыдущих запусков или действий других тестировщиков.
• Избыточное количество UI-тестов. Большой набор медленных и нестабильных проверок затрудняет выпуск изменений.
• Отсутствие приоритетов. Критичные сценарии проверяются в конце, когда времени на исправление уже мало.
• Игнорирование нефункциональных рисков. Регрессия может включать не только функциональные проверки. Если изменения затрагивают производительность, безопасность или совместимость, могут потребоваться соответствующие тесты. Обычного функционального набора здесь недостаточно.

Как понять, что регрессионное тестирование завершено

Перед завершением проверки убедитесь, что:

• Выполнены обязательные сценарии.
• Критичные риски проверены.
• Результаты зафиксированы.
• Ошибки проанализированы.
• Блокирующие дефекты исправлены или согласованы с ответственными.
• Повторные проверки выполнены.
• Остаточные риски понятны команде.

Если часть тестов пропущена, это нужно отразить в отчёте. Нельзя считать регрессию полностью пройденной только потому, что все запущенные сценарии завершились успешно.

Как научиться проводить регрессионное тестирование

Важно научиться анализировать требования, составлять тест-кейсы, работать с тестовыми данными, находить зависимости между модулями и оформлять дефекты.

Для начинающего QA-инженера полезен следующий порядок:

1. Освоить основы тестирования и техники тест-дизайна.
2. Научиться работать с чек-листами, тест-кейсами и баг-репортами.
3. Разобраться в HTTP, API, SQL и клиент-серверной архитектуре.
4. Потренироваться на учебном приложении: провести проверку до изменений и после них.
5. Освоить автоматизацию и работу с CI/CD.

Тем, кто хочет освоить профессию системно, подойдёт онлайн-курс «Тестировщик ПО (QA)».

Вывод

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

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