Повторная проверка исправления и регрессия

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

Два вопроса после изменения

Повторная проверка исправления — confirmation testing — отвечает, устранён ли исходный дефект. Регрессионное тестирование ищет нежелательные последствия изменения. Объём зависит от затронутых связей и риска; он не ограничивается только другим экраном. Основание: ISTQB CTFL v4.0.1, §2.2.3, с. 30–31.

В командах можно встретить слово retest. Уточняй, что им называют, и записывай цель проверки: «повторно запустили тест» само по себе ещё не объясняет, почему он нужен.

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

Зафиксируй исходную проблему

Возьмём вымышленную форму заказа. Правило: целое количество от 1 до 100 включительно допускает переход; 101 вызывает «Введите целое количество от 1 до 100», переход запрещён. Ранее на сборке demo-17 при 101 происходил переход без ошибки. Это заданное условие учебного примера, не результат тестирования нашего продукта.

Теперь дана сборка demo-18 с заявленным исправлением. По условиям задачи изменён общий валидатор количества, который используется ещё и в корзине. Требования к диапазону не менялись. В корзине правило такое же; при допустимом количестве 2 её итог при цене 50 равен 100. Сохранение адреса доставки использует отдельный модуль; других сведений о связях у нас нет.

Заявление разработчика «исправлено» — повод проверить нужную сборку, а не готовый результат. До запуска отметка проверки остаётся «не выполнено». Сначала нужно убедиться, что стенд действительно содержит demo-18, и восстановить условия исходного репорта.

Раздели готовый набор по цели

Для упражнения уже предложены такие проверки:

1. На форме заказа ввести 101, нажать «Продолжить», сравнить сообщение и отсутствие перехода с исходным репортом.
2. На форме заказа ввести 100 и убедиться, что допустимый максимум по-прежнему открывает следующий шаг.
3. В корзине установить количество 2 при цене 50 и проверить итог 100.
4. В корзине ввести 101 и проверить сообщение диапазона и запрет применения количества.

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

Такое разделение описывает наш план, а не свойство числа 101 или расположения кнопки. Новая проверка, добавленная именно для подтверждения полноты конкретного исправления, тоже может относиться к confirmation testing. Один тест допустимо переиспользовать в разных наборах; укажи, на какой вопрос отвечает его запуск сейчас.

Не выводи полный объём из четырёх пунктов

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

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

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

Запиши наблюдение после выполнения

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

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

Разобранные примеры

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

Попробуй по образцу

Другая синтетическая ситуация: поле билетов допускает целое от 1 до 8. Исходный дефект — 9 пропускается без ошибки; исправлена общая функция, используемая также при редактировании брони. В готовом плане есть:

1. Повторить исходный сценарий с 9 и проверить заданную ошибку и запрет перехода.
2. Проверить, что ранее работавшая покупка 8 билетов по-прежнему проходит.
3. Проверить ранее работавшее изменение брони на 2 билета через ту же функцию.

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

Что оставить себе

Записывай отдельно: какое исходное расхождение перепроверяешь, какие побочные последствия ищешь и какой набор реально выполнен. Чтобы компактно оформить готовые проверки, переходи к чек-листу по шаблону.

Источник понятий: ISTQB CTFL Syllabus v4.0.1, §2.2.3, проверен 06.11.2026; © ISTQB и авторы, перечисленные в Copyright Notice syllabus. Формы, сборки, связи модулей, числа и планы — собственные синтетические примеры «Твой Ментор». Это не отчёт о реальном тестировании, не официальный курс ISTQB и не подтверждение уровня навыка.