Тестирование и QA интернет-магазина на 1С-Битрикс

Интернет-магазин на 1С-Битрикс — это не одна страница, а десятки взаимосвязанных сценариев: каталог с фильтром, карточка товара с торговыми предложениями, корзина, многошаговое оформление, оплата разными способами, расчёт доставки по регионам, личный кабинет и обмен с 1С по расписанию. Каждый из них может сломаться незаметно — не «упасть с ошибкой на главной», а тихо перестать работать в одном браузере, для одного региона или после очередного обмена. И пока кто-то случайно не заметит, магазин будет терять заказы каждый день. Тестирование интернет-магазина нужно именно для того, чтобы находить такие дефекты дёшево — до релиза, а не по жалобам клиентов.

Эта статья — практическая карта QA для магазина на 1С-Битрикс. Разберём, зачем нужно тестирование и сколько на самом деле стоит баг в продакшене, какие бывают виды тестирования (функциональное, регресс, интеграционное, нагрузочное, юзабилити, безопасность, кроссбраузерное и мобильное), какие сценарии магазина критичны и как их проверять, как строить чек-листы и тест-кейсы, где проходит граница между ручным и автоматизированным тестированием, что такое unit и e2e (Selenium, Playwright обзорно), как устроены тестовые окружения и данные, как проводить нагрузочное тестирование и тест обмена с 1С на копии, что входит в приёмку сайта (UAT) и критерии приёмки, как вести баг-трекинг и выстроить цикл релиза с регрессом и smoke-тестом после деплоя. Материал — выжимка из практики поддержки и развития магазинов на 1С-Битрикс, где качество каждого релиза измеряется в деньгах.

Зачем магазину QA: цена бага в проде

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

Проблема магазина в том, что дефекты здесь редко «кричат». Ошибка PHP видна сразу, но большинство коммерчески опасных багов выглядят иначе:

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

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

Тестирование и QA: разбираемся в терминах

Часто «тестирование» и «QA» используют как синонимы, но это разные по объёму понятия, и разница помогает выстроить процесс правильно.

• Тестирование (Testing) — это процесс проверки: прогон сценариев, поиск расхождений между ожидаемым и фактическим поведением. Это конкретная деятельность — «нашёл баг».
• Контроль качества (QC, Quality Control) — более широкая проверка того, что продукт соответствует требованиям: не только функции, но и вёрстка, тексты, скорость, доступность.
• Обеспечение качества (QA, Quality Assurance) — процесс, встроенный в разработку так, чтобы дефектов возникало меньше: код-ревью, тестовые окружения, чек-листы, автотесты, культура релизов. QA отвечает на вопрос «как сделать, чтобы баги не доезжали до прода», а не только «как их найти».

На практике для магазина важна вся цепочка, но фокус — на QA как процессе. Один талантливый тестировщик, который героически ловит баги руками перед каждым релизом, — это лучше, чем ничего, но это хрупко: он заболеет, уйдёт в отпуск, устанет. Устойчивое качество даёт система: понятные окружения, регрессионные чек-листы, автоматизированный smoke, процесс работы с дефектами. Дальше в статье мы говорим именно про систему.

Ещё одно полезное различение — уровни серьёзности того, что мы ищем. Дефект (баг) — расхождение поведения с ожидаемым. Инцидент — проявление дефекта в проде, влияющее на пользователей. Регрессия — дефект, который сломал ранее работавшую функциональность. Магазин особенно чувствителен к регрессиям, потому что живёт долго и постоянно меняется: новый функционал легко ломает старый, и без регресс-тестирования это выясняется уже на клиентах.

Виды тестирования интернет-магазина

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

Виды удобно делить и по другому признаку — на функциональные (проверяют, что система делает) и нефункциональные (проверяют, как она это делает: быстро, безопасно, удобно). Для магазина критичны обе группы: функциональные ловят «не работает», нефункциональные — «работает, но медленно / небезопасно / неудобно», а это тоже теряет деньги. Дальше разберём ключевые виды подробнее, начав с того, как они соотносятся между собой по цене и объёму.

Пирамида тестирования: от unit до e2e

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

• Unit-тесты (основание). Проверяют отдельные функции и классы в изоляции: калькулятор скидки, парсер артикула, метод расчёта веса корзины. Быстрые (миллисекунды), стабильные, дешёвые в поддержке. Их может быть много.
• Интеграционные тесты (середина). Проверяют связки: работает ли выборка вместе с базой, корректно ли модуль общается с платёжным шлюзом на тестовом контуре. Медленнее unit, но покрывают стыки, где чаще всего живут баги.
• E2E-тесты (вершина). Эмулируют реального пользователя в браузере: «открыл каталог → добавил в корзину → оформил → дошёл до оплаты». Самые ценные по смыслу и самые дорогие в поддержке — медленные и хрупкие. Их держат мало, только на критичный путь.

Типичная ошибка — перевернуть пирамиду: написать десятки хрупких e2e-тестов и ни одного unit. Такой набор долго гоняется, часто ломается по мелочам (сдвинулась вёрстка — упал тест) и team перестаёт ему доверять. Здоровая структура — много быстрых нижних тестов и несколько устойчивых верхних. Для магазина на Битриксе прагматичный минимум: unit на собственную бизнес-логику (скидки, расчёты), пара e2e на оформление и оплату, всё остальное — ручные чек-листы.

Функциональное тестирование

Функциональное тестирование — фундамент всего QA. Оно отвечает на прямой вопрос: делает ли функция то, что от неё ожидают по требованиям? Фильтр по цене должен отбирать товары в диапазоне; добавление в корзину — увеличивать счётчик и сумму; купон — применять скидку; форма оформления — валидировать телефон и не пропускать пустой адрес. Каждая такая проверка — функциональный тест.

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

• Классы эквивалентности. Для поля «количество товара» вводы делятся на группы: валидное число, ноль, отрицательное, дробное, текст. Достаточно по одному представителю каждой группы, а не сто разных чисел.
• Граничные значения. Больше всего багов живёт на границах: 0 и 1 в количестве, минимальная и максимальная сумма для бесплатной доставки, последний товар на складе. Их проверяют отдельно.
• Негативные сценарии. Проверяют не только «как надо», но и «как не надо»: буквы в поле телефона, отправка формы с пустыми полями, применение просроченного купона. Магазин должен корректно отказывать, а не падать.

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

Регресс-тестирование перед релизом

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

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

1. Соберите регрессионный набор. Выпишите все критичные сценарии магазина: каталог, фильтр, карточка, корзина, оформление, оплата, доставка, регистрация, обмен с 1С. Это основа набора.
2. Приоритизируйте. Пометьте, что критично (оплата, оформление) и должно проверяться всегда, а что можно проверять реже. Полный регресс дорог — приоритеты позволяют не гонять всё каждый раз.
3. Определите объём под релиз. Для крупного релиза — полный набор; для точечной правки — затронутая область плюс smoke критичного пути.
4. Прогоните на stage. Регресс всегда идёт на копии, максимально похожей на прод, а не на боевом сайте.
5. Автоматизируйте повторяющееся. Сценарии, которые вы гоняете каждый раз и которые стабильны, — первые кандидаты на e2e-автоматизацию. Это снимает рутину и ускоряет релизы.

Ключевая мысль: регресс — это не разовое усилие, а дисциплина каждого релиза. Даже без автоматизации простой прогон регрессионного чек-листа перед выкладкой ловит большинство дорогих регрессий. А по мере роста магазина именно регресс автоматизируют в первую очередь, потому что он повторяем и предсказуем. Как встроить регресс в процесс выкатки, мы разбираем в статье про CI/CD и деплой для 1С-Битрикс.

Интеграционное тестирование

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

Для магазина на Битриксе ключевые интеграции, которые нужно тестировать, такие:

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

Главный принцип интеграционного тестирования — проверять не только «счастливый путь», но и сбои. Что произойдёт, если платёжный шлюз не ответил вовремя? Если 1С прислала товар без цены? Если служба доставки недоступна в момент оформления? Хорошо спроектированный магазин обрабатывает такие ситуации предсказуемо — показывает понятную ошибку, ставит заказ в очередь, откладывает обмен, — а не падает и не теряет заказ. Проверка этих деградаций и есть суть интеграционного тестирования. Подробнее про саму интеграцию — в материале про интеграцию магазина с 1С.

Критичные сценарии магазина

В любом магазине есть сценарии, поломка которых напрямую бьёт по выручке, и есть второстепенные. QA всегда начинают с критичных — тех, что образуют путь клиента к оплате. Если ресурсов на тестирование мало, покрывайте сначала их, а не редкие страницы. Ниже — карта критичных сценариев магазина на Битриксе, которые обязаны попасть в любой чек-лист и регрессионный набор.

• Каталог и разделы. Открытие категорий, пагинация, сортировка, вывод цен и остатков, доступность товаров.
• Фильтр (умный фильтр). Отбор по свойствам и цене, комбинации условий, корректность счётчиков, пустая выдача, работа ЧПУ-адресов фильтра.
• Карточка товара. Галерея, выбор торговых предложений (SKU) — цвет/размер, смена цены и остатка при выборе, кнопка «В корзину».
• Корзина. Добавление и удаление, изменение количества, пересчёт суммы, применение купона, лимиты и остатки.
• Оформление заказа. Шаги оформления, валидация полей, выбор доставки и оплаты, авторизация и оформление без регистрации.
• Оплата. Все боевые способы оплаты, возврат статуса, поведение при отмене и ошибке оплаты.
• Доставка. Расчёт стоимости и сроков по регионам, выбор ПВЗ, порог бесплатной доставки.
• Регистрация и личный кабинет. Регистрация, вход, восстановление пароля, история заказов, повтор заказа.
• Обмен с 1С. Актуальность каталога, цен и остатков, корректная передача заказов в учёт.

Эти девять блоков — «денежный контур» магазина. Схема ниже показывает их как единый путь: сбой на любом шаге обрывает воронку, поэтому тестируют не только каждый блок по отдельности, но и весь путь целиком (это и есть e2e-сценарий).

Чек-листы и тест-кейсы

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

Чек-лист

Чек-лист — это список того, что нужно проверить, без детальных шагов. «Фильтр по цене работает», «Купон применяется», «Оплата картой проходит». Он компактный, быстро проходится и удобен для регресса и smoke-тестов. Чек-лист не объясняет, как проверять, — он полагается на опыт проверяющего. Это его сила (гибкость, скорость) и слабость (зависимость от квалификации).

Тест-кейс

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

Практическое правило: детальные тест-кейсы пишут для критичных и сложных сценариев (оформление, оплата, обмен с 1С), а для остального достаточно чек-листов. Не нужно документировать каждую кнопку по всей строгости — это дорого и быстро устаревает. Держите подробную документацию там, где цена ошибки высока и где сценарий неочевиден, а рутину закрывайте чек-листами.

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

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

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

E2E-автотесты: Selenium и Playwright

Когда речь заходит об автоматизации сквозных сценариев магазина, используют инструменты, управляющие настоящим браузером. Два самых известных — Selenium и Playwright. Оба эмулируют пользователя: открывают страницы, кликают, вводят текст, проверяют содержимое. Разберём их обзорно, без погружения в код, — чтобы понимать, что это и когда применять.

• Selenium — ветеран автоматизации браузера, огромная экосистема и поддержка множества языков. Универсален, но исторически чувствителен к нестабильности: тесты часто требуют ручных ожиданий и «падают» на таймингах, если элемент не успел появиться.
• Playwright — более современный инструмент, спроектированный с учётом болей Selenium: умные автоожидания элементов, работа с несколькими браузерами из коробки, стабильнее на динамических интерфейсах. Для новых проектов чаще выбирают его.

Что именно автоматизируют e2e-тестами в магазине? Прежде всего — критичный путь покупки: открыть каталог, применить фильтр, зайти в карточку, выбрать торговое предложение, добавить в корзину, оформить, дойти до оплаты. Этот сценарий дорого проходить руками каждый релиз, он стабилен по логике и максимально ценен по смыслу — поэтому он первый кандидат на автоматизацию. Хороший e2e-набор для магазина — это не сотня тестов, а 5–15 сценариев на самые дорогие пути.

Важные оговорки. E2E-тесты — самые хрупкие: они ломаются при изменении вёрстки, идентификаторов элементов, текстов. Чтобы они были устойчивыми, элементы помечают стабильными атрибутами (например, специальными data-атрибутами для тестов), а не привязываются к случайным CSS-классам. И e2e гоняют на выделенном тестовом окружении с предсказуемыми данными, а не на живом каталоге, который меняется от обмена к обмену. Про интеграцию таких прогонов в конвейер выкатки — снова к статье про CI/CD и деплой для 1С-Битрикс.

Тестовые данные и окружения

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

• dev (разработка) — окружение разработчика или общая dev-площадка. Здесь пишут и проверяют код, данные могут быть неполными и «грязными». Нестабильность допустима.
• stage (тестовое / предпродакшен) — копия продакшена, максимально к нему приближённая: та же версия Битрикса, те же модули, копия базы, отдельная тестовая 1С. Именно здесь проводят регресс, интеграционное и приёмочное тестирование. Ключевое требование к stage — быть похожим на прод настолько, чтобы поведение совпадало.
• prod (продакшен) — боевой сайт, куда выкатывают только проверенное. На проде допускается лишь короткий smoke-тест после деплоя, и то аккуратно.

Отдельная тема — тестовые данные. На stage нужны данные, покрывающие крайние случаи: товар в наличии и без остатка, товар с торговыми предложениями и без, разные ценовые диапазоны для фильтра, адреса в зоне доставки и вне её, тестовые карты платёжных систем. Персональные данные реальных клиентов при копировании базы на stage правильно обезличивать — заменять телефоны, e-mail и адреса на тестовые, чтобы случайно не отправить письмо или SMS реальному человеку с тестового контура.

Нагрузочное тестирование

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

Инструменты

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

• Apache JMeter — популярный инструмент с графическим интерфейсом, богатыми возможностями и большим сообществом.
• k6 — современный инструмент, где сценарии описываются кодом; удобен для интеграции в конвейер.
• Yandex.Tank — инструмент для высоконагруженных стрельб, распространённый в русскоязычной среде.
• Gatling — ещё один мощный инструмент с акцентом на сценарии и отчётность.

Метрики

Смысл нагрузочного теста — не «положить сайт», а измерить его поведение. Ключевые метрики:

• Время отклика. Смотрят не только среднее, но и перцентили — p95 и p99. Среднее обманчиво: при среднем «полсекунды» p99 может быть «десять секунд», и именно эти десять секунд видит часть клиентов.
• Пропускная способность — сколько запросов в секунду система обрабатывает без деградации.
• Доля ошибок — процент запросов, завершившихся ошибкой под нагрузкой.
• Точка деградации — при каком числе одновременных пользователей отклик начинает резко расти. Это и есть «потолок» текущей конфигурации.

Узкие места

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

Тест обмена с 1С на копии

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

Правильная схема теста обмена такая: разворачивается stage-копия сайта и отдельная тестовая информационная база 1С (или копия боевой). Обмен настраивается между копиями, и никакие тестовые выгрузки физически не могут долететь до продакшена. Что проверяют:

• Выгрузку каталога: разделы, товары, торговые предложения (SKU), свойства, изображения — всё пришло, ничего не потерялось и не задвоилось.
• Цены и остатки: корректность по типам цен и по складам, обновление при повторной выгрузке.
• Заказы обратно в 1С: заказ создаётся в учёте с правильным составом, суммой, покупателем и статусом; статусы синхронизируются в обе стороны.
• Идемпотентность: повторный обмен не должен создавать дубли товаров и заказов — критично для устойчивости.
• Крайние случаи: товар удалён в 1С, изменился артикул или код, обмен прервался посередине, частичная выгрузка. Магазин должен обработать это предсказуемо.

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

Юзабилити-тестирование

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

Что оценивают в юзабилити-тестировании магазина:

• Длина пути к покупке. Сколько шагов и кликов от карточки до подтверждённого заказа, нет ли лишних обязательных полей, можно ли купить без регистрации.
• Понятность интерфейса. Видна ли кнопка «В корзину», ясно ли, что товара нет в наличии, понятен ли выбор размера/цвета, работает ли навигация по каталогу интуитивно.
• Тексты и ошибки. Понятны ли сообщения об ошибках («Введите телефон в формате...» вместо «Ошибка валидации поля PHONE»), ясны ли условия доставки и оплаты.
• Обратная связь системы. Показывает ли магазин, что товар добавлен, что заказ принят, что оплата в процессе — или пользователь остаётся в неведении.

Юзабилити-тестирование почти всегда ручное и часто исследовательское: тестировщик или реальный пользователь проходит типовые задачи («купи вот этот товар с доставкой в свой город») и отмечает, где спотыкается. Это область, которую невозможно свести к автотестам, — она требует человеческого суждения. Юзабилити-проблемы напрямую влияют на конверсию, поэтому их находки часто ценнее, чем очередной технический баг.

Тестирование безопасности

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

• Обработка пользовательского ввода. Формы, поиск, фильтр, параметры URL не должны пропускать инъекции. На Битриксе штатное ядро и ORM защищают от многого, но собственный код может открывать дыры.
• Права доступа. Проверяют, что обычный пользователь не может открыть чужой заказ по прямой ссылке, попасть в админку или получить данные другого клиента. Разграничение прав — частый источник утечек.
• Аутентификация. Устойчивость к перебору пароля, безопасное восстановление доступа, отсутствие раскрытия «существует ли такой e-mail» на форме входа.
• Обновления и уязвимости. Актуальность версии платформы и модулей, отсутствие известных уязвимостей. Проверка сканером безопасности Битрикса как базовая гигиена.
• Защита платёжных данных. Магазин не должен хранить данные карт у себя — оплата идёт через сертифицированный шлюз, а на сайте обязателен HTTPS.

Тестирование безопасности проводят периодически и обязательно — при работе с платежами и персональными данными. Хорошая практика — включить базовые проверки безопасности в регрессионный чек-лист (например, «чужой заказ недоступен по прямой ссылке»), чтобы случайная доработка не открыла доступ. Более глубокий анализ — задача для профильного аудита, который стоит заказывать при серьёзных изменениях архитектуры или работе с чувствительными данными.

Кроссбраузерное и мобильное тестирование

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

Кроссбраузерное

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

Мобильное и адаптивное

Мобильное тестирование — это не «уменьшить окно браузера». На телефоне другое: тач-взаимодействия вместо мыши, экранная клавиатура, перекрывающая поля, фиксированные панели, жесты. Что проверяют:

• Адаптивная вёрстка на реальных ширинах экрана: ничего не уезжает, не перекрывается, кнопки доступны для пальца.
• Кнопка «Купить» и корзина — не скрыты фиксированной панелью, нажимаются с первого раза.
• Формы оформления — удобный ввод, правильные типы клавиатуры (цифровая для телефона), поля не перекрываются клавиатурой.
• Фильтр на мобильном — обычно это отдельный сценарий (шторка/попап), который надо тестировать отдельно от десктопного.

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

Приёмочное тестирование (UAT) и критерии приёмки

Приёмочное тестирование (UAT, User Acceptance Testing) — финальная проверка перед тем, как заказчик примет работу или магазин выйдет в продакшен. Его принципиальное отличие от технического тестирования — точка зрения. Техническое QA спрашивает «работает ли корректно», UAT спрашивает «решает ли это задачи бизнеса и соответствует ли тому, о чём договаривались». UAT обычно проводит заказчик или выделенный представитель на stage-копии.

Чтобы приёмка не превратилась в бесконечный спор «а я думал, будет иначе», её строят на критериях приёмки — заранее согласованном списке того, что должно быть выполнено. Согласовать критерии нужно до начала работ, тогда приёмка становится прохождением чек-листа, а не переговорами. Ниже — пример чек-листа приёмки магазина.

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

Баг-трекинг и процесс работы с дефектами

Найти баг — половина дела; вторая половина — чтобы он не потерялся и был исправлен. Для этого дефекты ведут в баг-трекере (Jira, YouTrack, встроенные трекеры Git-платформ или любой удобный инструмент). Ключевое — не сам инструмент, а дисциплина: каждый дефект зафиксирован, у него есть статус, приоритет и ответственный.

Хороший баг-репорт содержит минимум, без которого дефект невозможно воспроизвести и починить:

• Шаги воспроизведения — что именно сделать, чтобы увидеть баг. Без этого разработчик тратит время на догадки или закрывает как «не воспроизводится».
• Ожидаемый и фактический результат — что должно быть и что есть на самом деле.
• Окружение — где воспроизводится: браузер, устройство, окружение (stage/prod), пользователь.
• Приоритет и серьёзность — насколько это критично для бизнеса и насколько сильно ломает функциональность.
• Доказательства — скриншот, видео, лог. Одна картинка часто заменяет абзац описания.

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

Жизненный цикл дефекта обычно такой: открыт → в работе → исправлен → на проверке → закрыт (или переоткрыт, если правка не помогла). Важно, чтобы исправленный баг обязательно перепроверялся тем, кто его завёл, — «исправил» и «действительно работает» это разные состояния. И полезно после исправления добавить проверку в регрессионный набор, чтобы этот дефект не вернулся в будущем.

Цикл релиза: регресс и smoke после деплоя

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

1. Разработка и unit-тесты. Код пишется на dev, покрывается unit-тестами на бизнес-логику, проходит код-ревью. Дефекты ловятся на самой дешёвой стадии.
2. Выкладка на stage. Изменения разворачиваются на копию продакшена с тестовыми данными и тестовой 1С.
3. Функциональное тестирование правки. Проверяется то новое, что добавили или изменили, — по тест-кейсам.
4. Регресс. Прогоняется регрессионный набор критичных сценариев — вручную или автотестами. Убеждаемся, что ничего не сломалось.
5. Приёмка (при необходимости). Для значимых изменений — UAT заказчиком по критериям приёмки.
6. Деплой на прод. Проверенные изменения выкатываются на боевой сайт по отлаженной процедуре с возможностью отката.
7. Smoke-тест на проде. Сразу после деплоя — короткая проверка критичного пути на боевой конфигурации: сайт открывается, товар кладётся в корзину, оформление доходит до оплаты, обмен с 1С проходит.
8. Мониторинг. После релиза следят за логами, ошибками и метриками — часть проблем всплывает только на реальном трафике.

Два шага здесь особенно важны и часто недооценены. Регресс перед релизом ловит поломки того, что уже работало, — главную причину внезапных инцидентов. Smoke-тест после деплоя ловит то, что ведёт себя иначе именно на боевой конфигурации: реальные настройки платёжки, боевые домены, кэш, права. Успешный прогон на stage не гарантирует идентичного поведения на проде — поэтому smoke на бою обязателен, даже если релиз «точно такой же».

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

Тестирование магазина порождает свой набор типовых граблей. Зная их заранее, вы избежите большинства болезненных инцидентов на проде.

• Тестирование на боевом сайте. Тестовые заказы, прогон обмена и правки на проде задевают реальных клиентов и данные. Нужен отдельный stage-контур.
• Обмен с 1С «на живую». Тест обмена на связке боевого сайта с боевой 1С — прямой риск рассинхронизации цен и остатков. Только копии, физически изолированные от прода.
• Нет регресса перед релизом. Проверили только новую правку, а она сломала соседний участок. Без регрессионного прогона это выясняется на клиентах.
• Пропущенный smoke после деплоя. Релиз прошёл на stage — значит «точно работает». А на боевой конфигурации отвалилась оплата, и никто не проверил. Smoke на проде обязателен.
• Тестирование только «счастливого пути». Проверили, как всё работает «когда правильно», и не проверили сбои: ошибку оплаты, недоступность доставки, товар без остатка. Негативные сценарии критичны.
• Игнорирование мобильных и других браузеров. Проверили в одном браузере на десктопе, а половина трафика — мобильная, где кнопка «Купить» перекрыта панелью.
• Перевёрнутая пирамида тестов. Десятки хрупких e2e и ни одного unit. Такой набор долго гоняется, часто ломается и теряет доверие команды.
• Автоматизация нестабильного. Пишут автотесты на функциональность, которая ещё меняется каждый день. Тесты ломаются чаще, чем ловят баги. Автоматизируют стабильное и дорогое.
• Баги в голове, а не в трекере. Дефекты обсудили устно и забыли. Без баг-трекера с шагами воспроизведения и приоритетами часть просто теряется.
• Нагрузочный тест по проду в пик. Стрельба по боевому сайту в рабочее время устраивает реальный отказ. Нагрузку дают по копии или в согласованное тихое окно.
• Реальные данные клиентов на stage. Копию базы залили на тестовый контур без обезличивания — и тестовое письмо ушло реальному человеку. Персональные данные обезличивают.

Чек-лист QA

Короткий список, по которому удобно свериться, выстраивая тестирование магазина на 1С-Битрикс:

• Есть отдельный stage-контур — копия продакшена с тестовыми данными и тестовой 1С; на проде не тестируют.
• Критичные сценарии (каталог, фильтр, карточка, корзина, оформление, оплата, доставка, регистрация, обмен с 1С) описаны чек-листами; сложные — тест-кейсами.
• Перед каждым релизом прогоняется регрессионный набор; поломка блокирует релиз.
• После деплоя на прод выполняется короткий smoke-тест критичного пути.
• Функциональное тестирование покрывает негативные сценарии и границы, а не только «счастливый путь».
• Интеграции (обмен с 1С, оплата, доставка) проверяются на копии, включая сбои и повторные обмены (идемпотентность).
• Обмен с 1С тестируется только между изолированными копиями; боевой сайт и боевая 1С не задействованы.
• Проведено кроссбраузерное и мобильное тестирование на реальных устройствах и в актуальных браузерах.
• Для роста трафика и акций проведено нагрузочное тестирование тяжёлых сценариев с метриками p95/p99.
• Базовые проверки безопасности (права доступа, обработка ввода, чужие заказы) включены в регресс.
• Приёмка (UAT) идёт по заранее согласованным критериям приёмки; уровень допустимых дефектов оговорён.
• Дефекты ведутся в баг-трекере с шагами воспроизведения, приоритетом и перепроверкой после исправления.
• Стабильные и дорогие сценарии (оформление, оплата) автоматизированы e2e; unit-тесты покрывают бизнес-логику.

Вывод

Тестирование интернет-магазина — это не финальная «проверка на всякий случай», а встроенная в разработку дисциплина, которая экономит деньги. Баг, найденный до релиза, стоит правки в задаче; тот же баг в продакшене — потерянных заказов, откатов и работы ночью. Магазин особенно уязвим, потому что дефекты здесь тихие: сломанная оплата, слетевший расчёт доставки, задвоенный после обмена каталог не выдают себя, но режут выручку каждый день. QA — это способ находить их дёшево, а не дорого.

Практический стержень такой. Есть разные виды тестирования под разные риски — функциональное, регресс, интеграционное, нагрузочное, юзабилити, безопасность, кроссбраузерное и мобильное — и их собирают в разумный набор под конкретный магазин. Критичные сценарии (каталог, фильтр, карточка, корзина, оформление, оплата, доставка, регистрация, обмен с 1С) проверяют по чек-листам и тест-кейсам перед каждым релизом. Ручное и автоматизированное дополняют друг друга: руками — новое и юзабилити, автотестами — регресс стабильного. Обмен с 1С и нагрузку тестируют на изолированных копиях, приёмку ведут по согласованным критериям, а после деплоя обязательно прогоняют smoke на бою. Собранные в цикл релиза, эти шаги дают главное — магазин меняется постоянно и при этом не ломается на клиентах. Если нужно выстроить такой процесс под ваш проект — мы делаем это в рамках поддержки и развития магазина и аудита на 1С-Битрикс. Смежные материалы по теме — CI/CD и деплой, Core Web Vitals магазина, интеграция с 1С и вся рубрика «Разработка и архитектура».