Регрессионное тестирование после доработок

Разработчик поправил расчёт скидок — задача на пару часов, всё выкатили в пятницу вечером. В понедельник выясняется, что с субботы не оформляется ни один заказ: правка скидок задела общий код корзины. Выходные потеряны, заказы тоже. Знакомая история для любого живого проекта на 1С-Битрикс — и ровно от неё защищает регрессионное тестирование.

Разберём, как выстроить регрессию после доработок на 1С-Битрикс: почему в нём всё так легко ломается, какие сценарии проверять в первую очередь, как собрать чек-лист, где нужны автотесты и staging, и как встроить всё это в релизы. Если доработок много и хочется системного порядка, поможет наша услуга аудита и оптимизации 1С.

Что такое регрессия и зачем она нужна

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

Ключевая мысль: регрессия проверяет не то, что вы дорабатывали, а то, что вы дорабатывать не собирались. Новый функционал тестируют отдельно (это функциональное тестирование), а регрессия следит за уже существующим — особенно за критичными сценариями, поломка которых бьёт по выручке. Без неё каждая доработка — лотерея: повезёт или нет, что ничего не отвалилось.

Почему в Битрикс всё легко ломается

1С-Битрикс — сильно связанная система, и это делает регрессию особенно важной. Причин, по которым правка в одном месте ломает другое, несколько:

• События и обработчики. Многие механизмы висят на событиях (например, при оформлении заказа). Новый обработчик или правка старого влияет на всю цепочку.
• Общие компоненты и код. Скидки, корзина, каталог используют общую логику работы с корзиной — правка одного задевает других.
• Кэш. Изменения могут «не проявиться» из-за кэша или, наоборот, сломаться при его сбросе — отдельный источник сюрпризов.
• Обмен с 1С. Правки свойств, цен или структуры заказа легко ломают формат обмена, а поломка вылезает не сразу.

Классический пример: доработали расчёт скидок, а перестало работать оформление заказа, потому что оба сценария опираются на общий код. Именно поэтому регрессия проверяет сквозные сценарии целиком, а не только изменённый файл. Архитектурные риски связанности мы разбираем в статье про разработку собственного модуля Битрикс.

Критичные сценарии e-commerce

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

Чек-лист регрессии: с чего начать

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

1. Соберите критичный путь. Опишите шаги от поиска товара до успешного заказа и обмена с 1С.
2. Добавьте ключевые роли. Гость и авторизованный клиент своей группы видят правильные цены и условия.
3. Включите деньги. Оплата, скидки, доставка, итоговые суммы — то, где ошибка стоит дороже всего.
4. Зафиксируйте ожидаемый результат. Для каждого шага — что должно произойти, чтобы проверка была однозначной.
5. Держите чек-лист живым. После каждого инцидента добавляйте сценарий, который его бы поймал.

Такой чек-лист превращает регрессию из «потыкали и вроде работает» в воспроизводимую процедуру. Со временем самые повторяемые пункты становятся кандидатами на автоматизацию.

Ручное тестирование и автотесты

Регрессию можно вести руками или автоматизировать — выбор зависит от размера проекта и частоты релизов, и это не «или-или», а баланс.

На старте и при редких доработках достаточно ручного прогона по чек-листу: тестировщик проходит критичные сценарии перед выкладкой. Когда релизов много, ручная проверка становится узким местом и начинает пропускать баги из-за усталости. Тогда автоматизируют самые важные и повторяемые сценарии — прежде всего критичный путь покупки. Оптимальная схема: автотесты на стабильный критичный путь плюс ручная проверка нового и сложного функционала, который ещё меняется. Автоматизацию удобно связывать с процессом деплоя, о котором мы пишем в статье про CI/CD и деплой Битрикс.

Staging-стенд как обязательное условие

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

На staging проверяют и новый функционал, и регрессию критичных сценариев, ловят ошибки и только потом выкатывают в прод. Чтобы проверка была честной, стенд должен быть максимально похож на боевой: те же данные каталога, настройки обмена с 1С, версии платформы и модулей. Стенд, который отличается от прода, даёт ложное спокойствие — «на тесте работало, на бою упало». Организацию таких окружений мы разбираем в материале про хостинг и инфраструктуру на BitrixVM.

Журнал событий и отладка

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

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

Тестирование обмена с 1С

Обмен с 1С — один из самых хрупких узлов, и его тестируют отдельно и внимательно. Доработки, затрагивающие свойства товаров, цены или структуру заказа, особенно легко ломают формат обмена, а поломка часто вылезает не сразу.

• Выгрузка каталога. Товары, свойства, торговые предложения приходят корректно.
• Цены и остатки. Обновление проходит без потерь и рассинхрона.
• Передача заказов. Заказ уходит в 1С в правильном формате со всеми данными.
• Возврат статусов. Статусы и документы возвращаются на сайт и в кабинет клиента.

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

Регрессия в процессе релизов и CI/CD

Регрессия работает, когда она обязательный этап релиза, а не разовая акция «когда вспомнили». Типовой цикл выглядит так: доработка на отдельной ветке, деплой на staging, прогон чек-листа регрессии и проверка журнала, релиз в продакшн, постпроверка на бою.

При частых релизах часть проверок автоматизируют и запускают через CI/CD: автотесты критичного пути стартуют при деплое, и релиз не проходит, если они падают. Это снимает человеческий фактор и ускоряет выпуск. Главное правило — ни одна доработка не уходит в прод без регрессии критичных сценариев, каким бы «мелким» ни казалось изменение. Настройку такого конвейера мы разбираем в материале про CI/CD и деплой Битрикс.

Постпроверка на боевом сайте

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

• Смоук-проверка. Быстро: открыть товар, добавить в корзину, дойти до оформления.
• Тестовый заказ. По возможности оформить и проверить, что он ушёл в 1С.
• Журнал после релиза. Заглянуть в журнал событий — не посыпались ли ошибки под боевой нагрузкой.
• План отката. Держать наготове возможность быстро вернуть предыдущую версию, если что-то пошло не так.

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

Частые ошибки

• «Правка мелкая, проверять нечего». Именно мелкие правки через общий код ломают критичные сценарии.
• Тестируют только новое. Проверяют доработку, но не то, что она могла задеть рядом.
• Нет staging. Доработки обкатывают на живых клиентах и их заказах.
• Не смотрят журнал. На витрине всё хорошо, а обмен с 1С тихо падает в журнале событий.
• Релиз в пятницу вечером. Поломку обнаруживают в выходные, когда некому чинить.
• Регрессия «когда вспомнили». Проверка не встроена в релиз, поэтому её пропускают под давлением сроков.
• Нет плана отката. Что-то сломалось на бою, а вернуть предыдущую версию быстро нельзя.

Чек-лист внедрения процесса

1. Собран чек-лист регрессии. Критичный путь покупки, роли клиентов, деньги и обмен с 1С с ожидаемым результатом.
2. Есть staging. Стенд-копия прода с теми же данными, обменом и версиями.
3. Определён баланс проверок. Автотесты на стабильный критичный путь, ручная проверка нового.
4. Журнал в процессе. Проверка журнала событий — обязательный шаг после прогона.
5. Обмен тестируется отдельно. Полный цикл обмена с 1С проверяется на staging и мониторится на бою.
6. Регрессия в релизе. Ни одна доработка не уходит в прод без прохождения регрессии, при частых релизах — через CI/CD.
7. Постпроверка и откат. После выкладки смоук на бою и готовый план быстрого отката.

Вывод

Регрессионное тестирование — это страховка выручки от собственных доработок. В сильно связанной системе 1С-Битрикс правка в одном месте легко ломает другое через общий код, события и обмен с 1С, поэтому проверять нужно не только изменённое, но и критичные сквозные сценарии целиком.

Соберите чек-лист критичного пути к деньгам, заведите staging-стенд, не забывайте про журнал событий и отдельно тестируйте обмен с 1С — и встройте всё это в каждый релиз, а при частых выкладках подключите автотесты и CI/CD. Тогда доработки перестанут быть лотереей, а релизы будут проходить без сюрпризов в выходные.