Регрессионное тестирование сайта: матрица проверок и порядок работ

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

Зачем бизнесу регрессионное тестирование сайта и где границы задачи

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

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

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

Границы задачи стоит зафиксировать сразу, иначе проверка расползётся. Регрессионное тестирование сайта не заменяет:

• нагрузочное тестирование — оно про поведение под пиковой нагрузкой, а не про сохранность функций;
• диагностику заражения — это отдельная задача про безопасность и посторонний код;
• проверку восстановления резервной копии — это про аварийное восстановление, а не про регресс.

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

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

Что попадает в матрицу проверок: критические сценарии и устройства

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

Критические пользовательские пути

Начните с путей, где сбой заметен сразу и стоит дорого:

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

Устройства, браузеры и роли

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

Что считать критичным

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

Как выбрать объём регресса

Полный регресс по всей матрице нужен не всегда. Объём выбирают по риску изменения и по цене ошибки. Есть три режима.

• Дымовой — быстрый проход по самым критичным сценариям. Подходит после мелкой правки контента.
• Выборочный — проверка тех участков, которые связаны с изменением. Основной рабочий режим.
• Полный — вся матрица. Оправдан перед крупным релизом, сменой окружения или после серии правок.

Выбор режима проверки зависит от характера изменений:

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

Обновление проверок при изменениях функций

Матрица — живой документ. Если её не обновлять, она быстро перестаёт отражать реальность: сценарии устаревают, шаги не совпадают с новым интерфейсом, проверка превращается в формальность.

Порядок такой:

1. Изменение функции фиксируют в задаче: что было, что стало, какие экраны и роли затронуты. 2. Определяют, какие строки матрицы устарели, какие нужно добавить, какие удалить. 3. Обновляют шаги и тестовые данные, чтобы проверку мог выполнить другой человек. 4. Отмечают, какие сценарии теперь автоматизированы, а какие остаются ручными. 5. Согласуют новую версию матрицы с тем, кто принимает работу.

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

Роли и ответственность в цикле регрессионного тестирования

Регресс ломается не из-за технологии, а из-за размытой ответственности. Разумно закрепить роли письменно.

• Заказчик или руководитель проекта — определяет приоритеты, согласует объём, принимает результат.
• Аналитик или ведущий разработчик — описывает, что именно изменилось и какие участки затронуты.
• Тестировщик — выполняет проверки, фиксирует результат, оформляет найденные расхождения.
• Разработчик или подрядчик — устраняет дефекты и сообщает, что можно перепроверять.
• Ответственный за окружение — готовит тестовую копию, данные и доступы.

Важно, чтобы тестовая копия была отделена от рабочего сайта. Изменения на рабочем сайте делают только после проверки на копии, с резервной копией и планом возврата. Если проверка идёт на живом сайте, любая ошибка сразу видна покупателям — это лишний риск.

Учебный пример: регрессионное тестирование сайта после обновления формы заказа

Учебный пример. Данные условные, компания и количество объектов вымышлены.

Входные условия. Интернет-магазин с каталогом, корзиной, оформлением заказа и обменом с учётной системой. Задача: обновили форму оформления заказа — добавили поле «комментарий» и изменили порядок шагов. Нужно убедиться, что оформление, оплата и уведомления продолжают работать.

Что подготовили:

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

Ход проверки:

1. Прошли оформление заказа как гость и как авторизованный покупатель. 2. Проверили, что новое поле сохраняется и попадает в заказ и в уведомление. 3. Сверили расчёт доставки и скидки до и после изменения. 4. Проверили возврат на сайт после оплаты. 5. Посмотрели, что заказ корректно уходит в учётную систему. 6. Повторили ключевые шаги на мобильном разрешении.

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

Вывод примера: изменение в одном шаге формы потребовало проверки не только самой формы, но и уведомлений, обмена и оплаты. Именно поэтому матрица строится вокруг сценариев, а не вокруг страниц.

Как проверить результат и принять работу

Приёмка регресса — это не «посмотрели, вроде работает». Нужны наблюдаемые признаки.

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

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

Типичные ошибки и ограничения

• Проверяют только изменённый участок и забывают связанные сценарии: уведомления, обмен, оплату.
• Матрица живёт отдельно от задач и не обновляется.
• Нет тестовых данных, и проверка идёт на реальных заказах.
• Регресс проводят сразу на рабочем сайте без копии и резервной копии.
• Сценарии описаны так, что их может выполнить только автор.
• Объём проверки не согласован, и в конце спорят, что считать результатом.
• Отчёт сводится к «всё хорошо», без статусов и деталей.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, исполнителю нужны:

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

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

Чек-лист перед запуском регрессионного тестирования сайта

• Определён повод и границы проверки, соседние задачи вынесены отдельно.
• Согласован объём: дымовой, выборочный или полный.
• Матрица проверок актуальна и содержит приоритеты.
• Подготовлена тестовая копия, отделённая от рабочего сайта.
• Есть резервная копия и план возврата.
• Подготовлены тестовые товары, покупатели, промокоды, адреса.
• Проверены роли: гость, покупатель, менеджер, администратор.
• Учтены мобильные разрешения и основные браузеры.
• Назначены ответственные за проверку и приёмку.
• Согласован формат отчёта и список дефектов.
• Проверены связанные сценарии: уведомления, обмен, оплата.
• После исправлений назначена перепроверка.

Вопросы и ответы