Почему исправление одной ошибки ломает другое: регрессия и тесты
Регрессия — это когда после изменения перестаёт работать то, что раньше работало. Починили форму на странице услуги — сломалась форма на главной, потому что у них общий код. Обновили модуль оплаты — перестали отправляться письма. В старых проектах без тестов это происходит постоянно, потому что никто не знает всех связей в коде. Защита — автоматические тесты на главные сценарии, тестовая копия и короткий чек-лист проверки после каждой выкладки. Первые два-три теста на самые важные сценарии окупаются за пару месяцев.
Почему так происходит
Код сайта — это не отдельные страницы, а связанные части. Одна функция отправки письма используется десятью формами. Один стиль кнопки применяется на всех страницах. Одна таблица в базе используется и каталогом, и корзиной, и отчётами.
| Причина | Пример |
|---|---|
| Общий код у разных частей сайта | Правка шаблона письма для одной формы ломает все |
| Неявные зависимости | Плагин А рассчитывает на версию плагина Б, которую обновили |
| Копипаста | Одна и та же логика в пяти местах; исправили в одном |
| Глобальные стили | Новый стиль для одного блока применился ко всем таблицам |
| Нет тестов | Сломанное обнаруживают клиенты |
| Изменения в базе | Новое поле обязательное, а старый код его не заполняет |
| Правки разных людей | Два подрядчика меняли одно и то же в разные годы |
Чем это плохо для бизнеса
Поломки после исправлений подрывают доверие сильнее, чем исходные ошибки. Заказчик перестаёт просить изменения, потому что боится, что что-то сломается. Сайт застывает, технический долг растёт. Кроме того, регрессии часто не видны сразу: сломанная отправка в CRM обнаруживается через неделю по жалобам менеджеров, а сломанная оплата на одном типе карт — по отзывам клиентов.
Как защищаются от регрессий
Автоматические тесты. Программа, которая после каждого изменения проходит важные сценарии: открывает страницу, заполняет форму, оформляет заказ, проверяет, что письмо отправлено. Если что-то сломалось, выкладка останавливается. Классическая схема — много быстрых тестов на отдельные функции и меньше медленных тестов на целые сценарии (пирамида тестов).
Тестовая копия сайта. Изменение сначала проверяется на копии, а не на рабочем сайте.
Чек-лист после выкладки. 5–10 пунктов, которые человек проверяет за 10 минут: главная, форма, корзина, оплата в тестовом режиме, телефон.
Мониторинг. Сервис, который каждые несколько минут проверяет, что сайт открывается и форма отвечает, и сообщает об ошибках в журнале.
Ревью кода. Второй разработчик смотрит изменения до выкладки и замечает, что правка затрагивает общий код.
С чего начать в проекте без тестов
Не нужно сразу покрывать тестами весь сайт — это дорого и долго. Начните с трёх сценариев, поломка которых стоит денег:
- Заявка с главной формы доходит до CRM и почты.
- Заказ оформляется и доходит до оплаты в тестовом режиме.
- Вход в личный кабинет и просмотр заказов, если он есть.
Сквозные тесты на эти сценарии с помощью Playwright или похожего инструмента — 1–3 дня работы. Дальше добавляйте тест на каждую найденную ошибку: исправили ошибку — написали тест, который её ловит. Через полгода у вас будет набор тестов на всё, что реально ломалось.
Сколько стоят тесты
| Что | Срок | Ориентир |
|---|---|---|
| 3 сквозных теста на главные сценарии | 1–3 дня | 15–40 тыс. ₽ |
| Запуск тестов автоматически при каждой выкладке | 0,5–1 день | 5–15 тыс. ₽ |
| Тест на каждую исправленную ошибку | +10–30% к задаче | в составе задачи |
| Полное покрытие нового проекта | 20–40% от стоимости разработки | в составе проекта |
Для нового проекта тесты дешевле закладывать сразу. Для старого — добавлять постепенно, начиная с самых дорогих поломок.
Как понять, что проект в зоне риска
- Каждая третья задача поддержки — исправление того, что сломалось после предыдущей.
- Подрядчик просит больше времени «на проверку всего» после каждой правки.
- В проекте работали три и больше команд в разное время.
- Обновления CMS и плагинов не ставились годами, потому что «страшно».
- Никто не может сказать, где используется конкретная функция.
Если узнали свой проект в трёх пунктах, начните с аудита: найти главные связи, написать тесты на ключевые сценарии и составить план, что переписать в первую очередь.
Регрессии в интеграциях
Отдельный класс регрессий — в обмене с внешними системами: CRM, 1С, платёжным сервисом, службой доставки. Изменение на вашей стороне ломает формат данных, и внешняя система молча отказывается их принимать. Сайт работает, заявки на экране «отправлены», а в CRM пусто. Такие поломки находят только по журналу обмена или по жалобам. Защита — тест, который отправляет тестовую заявку через интеграцию и проверяет, что она появилась на той стороне, и уведомление, если число ошибок обмена за час больше нуля.
Что делать, если регрессия уже случилась
- Откатить изменение, если поломка критичная: оплата, заявки, вход.
- Найти, какая правка вызвала проблему, — по истории репозитория это быстро.
- Исправить и добавить тест на этот случай.
- Проверить, нет ли похожих мест в коде, где та же проблема может возникнуть.
- Обновить чек-лист проверки после выкладки.
Материалы для проверки
Если нужна реализация
Состав работ зависит от текущего проекта и подтверждённой причины. Можно обсудить диагностику или разработку подходящего решения.
Вопросы и ответы
Что такое регрессионное тестирование?
Проверка, что после изменений продолжает работать то, что работало раньше. Её делают вручную по чек-листу или автоматически набором тестов.
Почему нельзя просто аккуратно программировать?
В проекте с сотнями связей человек не может держать в голове все зависимости. Тесты проверяют их за минуты и не устают.
Сколько стоит покрыть сайт тестами?
Три теста на главные сценарии — 15–40 тысяч рублей. Полное покрытие нового проекта закладывают в 20–40% стоимости разработки.
Нужны ли тесты для сайта на WordPress?
Для визитки — достаточно чек-листа. Для магазина на WooCommerce — желательно хотя бы сквозные тесты на заказ и оплату.
Кто должен писать тесты — разработчик или тестировщик?
Тесты на отдельные функции пишет разработчик вместе с кодом. Сквозные сценарии может писать и тестировщик. Важно, чтобы они запускались автоматически при каждой выкладке.
Что делать, если поломки после каждой правки стали нормой?
Остановить новые изменения на неделю-две, сделать аудит, написать тесты на главные сценарии и только потом продолжать доработки.