Сезон распродаж всегда приносит всплеск трафика и повышенные ожидания клиентов. В такие моменты даже мелкий дефект на сайте или в приложении интернет-магазина может обернуться потерянными заказами и испорченным опытом. В этом гайде разберемся, как правильно тестировать платформу перед пиковой нагрузкой, подсветим распространенные проблемы и дадим чек-лист проверок, которые помогут пройти горячий сезон без потерь.
Функциональные проверки
Функциональное тестирование проверяет, что сайт делает именно то, что должен делать. По кнопке «Купить» товар добавляется в корзину, при вводе промокода сумма пересчитывается правильно и так далее.
Если сильно упростить, все проверки можно разделить на три группы:
Проверки ключевых пользовательских действий
То, что клиент делает ежедневно: поиск товара/услуги, добавление в корзину, оформление заказа, оплата. Иными словами, путь клиента от первого клика до поступления денег.
Проверки бизнес-логики
Всё, что связано с правилами бизнеса: скидки, промокоды, наличие товаров на складе. Те места, где чаще всего находятся дефекты.
Проверки интеграций и связок
Уровень выше и сложнее. Смотрим, что работает «за сценой», но может сломаться: подключенные платежные системы, CRM, касса, сервис email-рассылок, доставка и пункты выдачи, подписки и автосписания.
Если одна из этих связок дает сбой, клиент может оплатить, а заказ не создастся. Это самый болезненный сценарий, который очень бьет по репутации. Второй по степени урона сценарий — сбой на этапе оплаты.
До 74% посетителей не возвращаются, если попали на стандартную «голую» 404-страницу — то есть столкнулись с битой ссылкой и не получили нормального «выхода из тупика». 32% клиентов в среднем по миру готовы бросить бренд после одного плохого опыта, до 70% — после двух негативных эпизодов.
Владелец бизнеса или сотрудники могут пройтись по сайту/приложению и что-то проверить — это уже отлично. Но профессиональный тестировщик нужен потому, что он:
Проверяет самые неожиданные сценарии
- что будет, если я удалю товар на последнем шаге?
- что будет, если введу неправильный телефон?
- а если промокод просрочен?
- а если клиент сделает всё в другой валюте?
Знает, где чаще всего происходят поломки
У тестировщика есть наработанные чек-листы, опыт и интуиция. Он обращает внимание на вещи, которые никогда не придут в голову обычному сотруднику или владельцу.
Проверяет то, что нельзя увидеть глазами
Например, корректность передачи данных в CRM, правильные статусы заказа, корректность фискализации (чеков), технические дефекты, которые видит только администраторы или лог.
Бывает, что распродажа завтра, а тестировщика нет. На этот случай мы подготовили простой и понятный чек-лист функциональных проверок, который можно пройти за вечер, без технических навыков, пользуясь только браузером.
Внимание: это не заменит работу тестировщика! Но спасет от 80% самых неприятных дефектов, которые могут сорвать распродажу.
Нажимайте кнопку ниже — пришлем полный чек-лист, чтобы вы ничего не упустили.
Что происходит на практике: топ-3 дефектов функционала
Дефекты промокодов и скидок
промокод «до —70%» применяется ко всем товарам
1. Выберите 3–5 товаров, которые точно должны участвовать в акции.
2. Выберите 3–5 товаров, которые точно не должны участвовать.
3. Примените промокод в корзине.
4. Проверьте:
- Скидка применяется только там, где надо.
- В карточке товара / каталоге нет противоречий («без скидки», а в корзине — скидка).
- На мобильной версии логика такая же.
💡 Подсказка: обязательно тестируйте товары с разными ценами, ставками НДС, наборами вариантов.
- В админке или CMS нужно корректно задать условия применения:
- Если CMS не поддерживает сложные условия — просить разработчика добавить фильтры (по тегам, по типам товара, по ID).
- Обязательно обновить текст акции, если правила меняются.
1. только выбранные категории / коллекции / SKU
2. исключить товары со скидками;
3. исключить товары- подарки или товары по спецумовиям.
Промокод можно вводить бесконечно (нет лимита использования).
- Примените промокод → скидка есть.
- Удалите товар → снова примените промокод.
- Измените количество → снова попробуйте.
- Попробуйте оформить несколько заказов с тем же кодом.
- Проверьте разные браузеры / инкогнито / мобильный — иногда валидация работает только для авторизованных клиентов.
1. Включите в административной панели ограничение:
- 1 применение на пользователя или
- на 1 корзину или
- пока действует акция, но не более X раз.
2. Добавьте проверку на фронтенде: «Этот промокод уже был использован».
3. Если CMS не позволяет ограничивать — разработчик должен:
- Проверять по e-mail/телефону,
- или по ID пользователя,
- или по fingerprint браузера (как временная мера).
Промокод снижает цену ниже себестоимости.
1. Возьмите самый дешевый товар в каталоге.
2. Примените промокод с максимальной скидкой.
3. Проверьте:
- не падает ли цена ниже себеcтоимости,
- не появляется ли «0₽»,
- не превращается ли товар в «подарок» случайно.
4. Попробуйте комбинировать с акциями:
- автоматическая скидка,
- скидки по количеству,
- скидки по категориям.
1. В CMS включить опцию «не снижать цену ниже минимальной» / «не суммировать скидки».
2. Установить ценовой порог — минимальную цену продажи.
3. Если CMS не умеет:
- разработчик добавляет проверку в логику корзины,
- либо создается «страховочный» слой расчетов, который фиксирует минимальный порог.
Перед запуском акции всегда тестируйте промокоды на крайних сценариях: самые дешевые товары, товары с уникальными условиями, товары с разными скидками. 90% неожиданных дефектов всплывают именно там.
Ломается мобильная версия
кнопка «купить» уезжает за пределы экрана
1. Открыть сайт на:
- айфоне,
- андроиде,
- разных ширинах экранов через DevTools.
2. Проверить карточку товара:
- видна ли кнопка «Купить»?
- перекрывает ли её нижняя навигация браузера?
3. Прокрутить вниз/вверх:
- остаётся ли кнопка в зоне видимости?
4. Повернуть телефон в горизонтальный режим.
Если кнопка «живет своей жизнью» — это дефект.
1. Задать кнопке гибкую ширину (width: 100% без фиксированных пикселей).
2. Не использовать фиксированные высоты.
3. Перейти на svh/lvh/dvh вместо старого vh на iOS/Android.
4. Если кнопка липкая («fixed»), проверить:
- не перекрывает ли её системная панель браузера,
- не нужно ли добавить padding-bottom к странице.
5. Проверить через инструменты Chrome Lighthouse/Responsive.
Боковое меню перекрывает кнопки.
1. Открыть мобильное меню.
2. Закрыть его.
3. Попробовать нажать на элементы под ним:
- кнопку «Купить»,
- фильтры,
- поиск.
4. Если что-то не кликается, значит меню оставило поверх прозрачный слой.
5. Проверить на iOS и Android — они ведут себя по-разному.
1. Проверить и поправить z-index: меню должно уходить под контент при закрытии.
2. Убедиться, что после закрытия меню:
- исчезает элемент <div class="overlay">,
- отключается pointer-events.
3. Добавить анимации, которые полностью скрывают блок, а не смещают его в сторону.
4. Проверить правильность размеров крестика закрытия.
Невозможно удалить товар из корзины на мобильном.
1. Открыть корзину на телефоне (не через DevTools!).
2. Нажать на крестик удаления: он должен удалять товар без увеличения экрана.
3. Проверить:
- можно ли нажать крестик одной рукой?
- не блокируется ли элемент другой кнопкой?
4. Протестировать в реальных сценариях:
- добавить 3–4 товара, попробовать удалить не первый, а средний.
- уменьшить количество товара до 0 (если логика такая).
5. Проверить на разных браузерах:
- Safari,
- Chrome,
- Samsung Internet.
1. Увеличить область клика до рекомендуемых 44×44 px (стандарт Apple).
2. Перенести кнопку удаления в более доступную зону.
3. Убедиться, что кнопка не смещается при изменении ширины контейнера.
4. Настроить корректную адаптивность блока корзины:
- не использовать float,
- перейти на flex или grid.
5. Проверить, что кнопка не перекрывается плавающими элементами.
Если элемент сложно нажать одной рукой — клиент его не нажмет. А если кнопка «Купить» или «Удалить товар» недоступна, продажи теряются мгновенно.
Платеж проходит, заказ — нет
Самая болезненная проблема.
1. Проверить успешный сценарий — несколько раз подряд.
1.1. Оформить заказ.
1.2. Оплатить реальной картой (минимальная сумма).
1.3. Проверить:
- появился ли заказ в CMS,
- ушло ли письмо,
- корректный ли статус («оплачен»),
- корректно ли синхронизировалось в CRM.
Повторить 3–5 раз подряд — дефект проявляется не всегда.
2. Проверить отмену оплаты
На платежной странице нажать:
- «Отменить»
- или вернуться назад стрелкой браузера.
После этого сайт должен:
- корректно вернуть на страницу;»
- создать неоплаченный заказ или не создавать вовсе (зависит от логики);
- понятно объяснить пользователю, что произошло.
3. Проверить задержку платежа
У некоторых банков можно сделать «долгую» оплату:
- начать вводить данные,»
- подождать 1–2 минуты,
- завершить.
Цель: увидеть, не даст ли задержка таймаут и сбой.
4. Проверить, что заказ создается и при повторном callback.
Попросить разработчика временно сделать тест:
- отправить несколько уведомлений success от платежной системы.
Сайт должен:
- не создавать 10 дублей,
- но корректно обновлять статус
5. Отключить интернет при переходе назад
Реальный кейс: человек оплатил → связь пропала → сайт не получил ответ.
Проверка:
- во время оплаты выключить сеть на телефоне,
- включить обратно → перейти в личный кабинет.
Система должна «догнать» статус заказа после восстановления сети.
1. Настроить «страховочный» запрос (reconciliation)
Если заказ не создался при первом уведомлении, сайт должен повторить запрос к платёжному шлюзу:
- сразу,
- через 10 секунд,
- через 1 минуту.
Любой современный шлюз позволяет сделать запрос наподобие: “GET /payments/{id}/status”
Это самое важное исправление.
2. Добавить повторную обработку вебхуков (retry)
Если вебхук пришёл в момент, когда сервер был перегружен, сайт должен иметь логику:
- повторить попытку принять вебхук,
- повторно обработать платеж.,
Без этой функции «потерянные» оплаты — вопрос времени.
3. Хранить предзаказ до получения статуса оплаты
Правильная логика такая:
- пользователь переходит на оплату → создается заказ «в ожидании оплаты»,
- когда приходит success → заказ обновляется.
Если заказ создается только после success — почти всегда происходят «потеряшки».
4. Включить detailed-логи
Хороший лог поможет понять:
- пришел ли вебхук,
- какой статус передал банк,
- был ли дефект на стороне сайта,
- был ли дефект в CRM.
Без логов проблему не поймать и не воспроизвести.
5. Проверить очереди и таймауты
Для нагруженных распродаж:
- увеличить таймауты обработки,,
- оптимизировать код создания заказа,
- вынести CRM-синхронизацию в фон (чтобы заказ создавался мгновенно, а CRM догоняла позже).
6. Сделать пользовательскую защиту
Когда всё-таки произошёл сбой (а они могут случиться)
- Показать клиенту сообщение: «Оплата проходит дольше обычного. Мы автоматически обновим статус заказа. Проверьте почту через 1–2 минуты».
- Дать кнопку «Проверить статус платежа».
Если платеж прошел, заказ должен создаться — при любых условиях. Именно для этого и нужны страховочные запросы, повторные вебхуки и логирование.
Нагрузочные проверки
Нагрузочные тесты показывают, как сайт ведет себя при большом количестве одновременных посетителей.
Если функциональные проверки отвечают на вопрос «работает ли сайт правильно?»,
то нагрузочные проверки отвечают на вопрос «выдержит ли сайт, когда на него придёт много людей?». Это проверка прочности, как у моста: он может быть идеально спроектирован, но если по нему проедут сразу 200 машин вместо 20, он треснет.
Нагрузочное тестирование выявляет один из самых дорогих видов дефектов — недоступность сайта в момент максимального спроса. Еще один критический параметр — скорость загрузки. Каждая секунда влияет на то, останется ли человек на сайте или уйдет. Согласно исследованиям Google, идеально, если сайт открывается до 3 секунд. Для e-commerce норма ещё строже — до 2 секунд. Страницы, которые попадают в топ Google, в среднем грузятся 1,65 секунды. После отметки 2–3 секунды начинается резкий рост отказов: 40% пользователей покинут сайт, если он загружается дольше трёх секунд.
Нагрузочное тестирование проводят специальными инструментами: JMeter, Gatling, k6, Locust, «Яндекс.Танк» и «Бумк». Они запускают сотни и тысячи «виртуальных пользователей», которые одновременно ходят по сайту, как живые: открывают главную, заходят в каталог, проверяют карточки товаров, добавляют что-то в корзину, пытаются оформить заказ.
Инженер берет эти типичные действия и превращает их в сценарий: как будто на сайт за секунду пришло 100 человек. Смотрит, что происходит. Потом увеличивает нагрузку — 300 человек. Потом 500. На каком этапе начинаются проблемы? Где именно появляются дефекты? Почему корзина вдруг отвечает по 12 секунд?
После прогона он получает набор метрик: скорость отклика, стабильность, пропускную способность, процент дефектов. Эти данные превращаются в понятный список проблем, который передают разработчикам — что именно тормозит, где узкое место, что нужно оптимизировать.
Как проверить сайт на нагрузку?
Коротко: самому — никак. Можно попросить друзей, коллег или подписчиков «зайти на сайт одновременно», но это никак не похоже на реальную распродажу. Даже если вы соберете 20 человек, они не создадут нагрузку, похожую на ситуацию, когда 500–1000 пользователей одновременно листают каталог, а сотни добавляют товары в корзину.
Полноценное нагрузочное тестирование — работа нескольких специалистов. Если нет времени и ресурсов, можно быстро улучшить ситуацию хотя бы мини-проверками:
- прогнать сайт через Google Lighthouse,
- убедиться, что изображения не весят по 5–10 МБ,
- отключить лишние виджеты и тяжелые скрипты,
- проверить, что корзина и оформление заказа грузятся быстрее двух секунд.
❗Это не заменит настоящего теста, но поможет сайту пережить первые часы распродажи.
Не рискуйте — закажите профессиональное экспресс-тестирование
Падение сайта — не просто досадная проблема, а сорванные заказы, расходы на рекламу впустую, негатив в соцсетях и репутационный провал. Один час простоя порой стоит дороже, чем полный цикл подготовительных тестов.
Если вам важно пройти распродажу спокойно и защитить продажи, можно сделать полноценное нагрузочное тестирование под ключ:
- разработаем сценарии под ваш бизнес;.
- протестируем на нужных объемах;
- найдем слабые места;
- поможем устранить дефекты;
- проверим повторно после исправлений.
