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

Работает новая функция — а прежние?

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

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

Что запросить до начала испытаний

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

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

Выберите сценарии по связям и последствиям

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

Обязательные пути для новой скидки

• Покупка без скидки. Обычный товар сохраняет цену и проходит оформление.
• Изменение количества. Корзина пересчитывается, а доставка и итог используют актуальный состав.
• Удаление товара. Исчезнувшая позиция больше не участвует в расчёте условий акции.
• Вход в аккаунт. Цена пересчитывается с учётом прав покупателя, если магазин применяет разные условия после авторизации.
• Завершение заказа. В кабинете и у менеджера сохраняются те же позиции и суммы, которые покупатель подтвердил.

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

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

Подготовьте копию, которая даст полезный ответ

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

Данные и внешние подключения

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

В рекомендациях Playwright тесты предлагается изолировать друг от друга, включая cookies и локальное хранилище браузера. Для внешних зависимостей документация показывает подмену сетевого ответа. Заказчику не нужно писать такой код. От исполнителя требуется объяснить, где проверено поведение магазина, а где дополнительно нужен отдельный контроль настоящего подключения к сервису.

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

Что оставить человеку, а что повторять автоматически

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

Автоматические сценарии

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

Playwright рекомендует обращаться к элементам по признакам, понятным пользователю, например роли кнопки и её названию, а не привязывать испытание к случайным классам оформления. Средства поиска элементов — локаторы — умеют автоматически ждать их готовности к действию. Эти свойства описаны в руководстве по устойчивым тестам. Поэтому после простого изменения дизайна не всякое падение теста означает поломку заказа: исполнитель сначала выясняет, что именно перестало совпадать.

Ручной проход

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

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

Как читать снимки экрана и отчёт об ошибке

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

Снимок как дополнительный контроль

• Одинаковые условия. Для двух снимков используют одинаковые ширину окна, браузер, платформу и данные.
• Смысл отличия. Исполнитель показывает область расхождения и объясняет, связано ли оно с заказанной правкой.
• Новый образец. Эталон обновляют после просмотра изменения, чтобы случайно не принять поломку за новый нормальный вид.

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

Что приложить к найденному сбою

В Trace Viewer разработчик сопоставляет шаги испытания, состояние страницы, ошибки и сетевую активность, чтобы определить, на каком действии возник сбой и какой ответ получил магазин вместо ожидаемого результата. Заказчику достаточно краткого вывода: какой путь нарушен, при каких данных, можно ли повторить сбой и какое исправление предложено. Для общения с подрядчиком сохраняйте адрес страницы, шаги и ожидаемый результат. Материал о том, как описать ошибку сайта, поможет подготовить задачу с понятным признаком исправления.

Основание для выпуска

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

Что остаётся в итоговом перечне

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

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

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