Как проверить доработку без поломки старых функций

Начните с контракта изменения

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

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

Постройте карту влияния

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

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

Матрица проверок

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

Подготовьте разные данные

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

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

Проверьте ошибки и повтор

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

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

Не ограничивайте права интерфейсом

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

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

Зафиксируйте результат и повторную проверку

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

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

Критерий завершения

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

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

Пример выбора регрессии для общего компонента

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

Если меняется серверная модель обращения, область шире: сохранение, чтение в админке, уведомление и совместимость старых записей. Тест только браузерного сообщения не покрывает эту работу. Карта зависимостей объясняет, почему для похожей внешне задачи нужен другой набор проверок.

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

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

Заполненная карта проверки общего поля формы

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

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

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

После исправления дефекта повторяют конкретный проваленный сценарий и связанные проверки. В протоколе сохраняют версию, результат и свидетельство для каждой строки. Изменение аналитики проверяют по набору после выпуска, а изменение формата данных — по матрице совместимости. Так объём приёмки следует реальному влиянию доработки.