Сравните повторное тестирование исправленного дефекта и регрессионное тестирование: чем различаются их цели?
Повторное тестирование проверяет, устранён ли конкретный ранее обнаруженный дефект. Регрессионное тестирование проверяет, не нарушило ли изменение уже работавшую функциональность; оно может включать связанные и несвязанные с дефектом проверки.
По мере развития программных систем исправление дефекта стало затрагивать не только исходный участок, но и связанные компоненты, интерфейсы и общие данные. Поэтому одной проверки исправленного сценария недостаточно: требуется отдельно подтвердить исправление и оценить побочные эффекты изменения.
Так появились две разные практики. Первая отвечает на вопрос о результате конкретного исправления, вторая — о сохранении ранее достигнутой работоспособности системы.
Если выполнить только повторную проверку дефекта, можно убедиться, что исходная ошибка исчезла, но пропустить новую ошибку в соседнем сценарии. Например, исправление расчёта скидки может повлиять на итоговую стоимость, возвраты или отчётность.
Если считать любую повторную проверку полноценной регрессией, команда переоценивает покрытие. Это приводит к ложному ощущению безопасности и затрудняет выбор тестов при ограниченном времени.
При повторном тестировании используют шаги, данные и условия, при которых дефект был обнаружен. Ожидаемый результат — подтверждение, что исходное несоответствие больше не воспроизводится. Если дефект не воспроизводится по случайной причине или тест изменён так, что больше не проверяет прежнюю проблему, исправление ещё нельзя считать подтверждённым.
Регрессионное тестирование выбирает проверки по риску воздействия изменения. В набор обычно включают изменённую функциональность, её непосредственные интеграции, общие механизмы, критические пользовательские пути и области, где ранее часто возникали дефекты.
Эти практики могут выполняться в одном запуске, но остаются логически разными. Один тест иногда одновременно подтверждает исправление и даёт регрессионное покрытие, однако сам факт успешного повторного теста не доказывает отсутствие побочных эффектов.
Регрессия не обязана означать полный запуск всех тестов. Набор можно сделать риск-ориентированным, но критерии отбора должны учитывать зависимости, критичность функций, размер изменения и историю дефектов. Чем выше цена ошибки и шире область воздействия, тем менее допустима чрезмерная оптимизация набора.
В интернет-магазине исправили ошибку, из-за которой промокод не применялся к заказу с несколькими товарами. Сначала повторно проверили исходный сценарий с теми же условиями и подтвердили исправление.
Затем рассмотрели варианты регрессии. Полный прогон давал наибольшую уверенность, но занимал слишком много времени перед выпуском. Проверка только промокода была бы быстрой, однако могла пропустить влияние на оплату, возврат и расчёт итоговой суммы.
Выбрали риск-ориентированный набор: сценарии применения промокода, расчёт итоговой стоимости, оплату, отмену заказа и возврат. Такой вариант сохранил проверки наиболее вероятных и дорогих последствий изменения, а результат повторного теста был зафиксирован отдельно от результата регрессии.
1. Дополнительный вопрос: Может ли повторное тестирование быть отрицательным, если регрессионные тесты проходят?
Да. Регрессия может не содержать точного сценария исходного дефекта или проверять только косвенные последствия. В таком случае система в целом выглядит стабильной, но конкретное исправление не подтверждено.
2. Дополнительный вопрос: Нужно ли повторять исходный тест без изменений?
По возможности — да, потому что сохранение исходных условий позволяет сопоставить результат до и после исправления. После этого полезны вариации данных и соседние сценарии, но они дополняют повторную проверку, а не заменяют её.
3. Дополнительный вопрос: Всегда ли регрессионный тест должен проверять функциональность, связанную с изменённой строкой кода?
Нет. Важна не только непосредственная близость к изменённому коду, но и путь использования, общие зависимости, интеграции и бизнес-критичность. Изменение общего компонента может повлиять на внешне далёкие функции, поэтому область регрессии определяют по рискам и зависимостям, а не только по расположению кода.