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