Привет, Хабр! Меня зовут Анастасия, я QA-специалист SimbirSoft и работаю на проектах с 1С-Битрикс. Не единожды я могла наблюдать, насколько эффективно бывает допустить QA-команду внутрь CMS, чтобы достичь бизнес-целей клиента. И на примере нескольких кейсов из разных проектов расскажу, как мы обеспечиваем качество на платформе 1С-Битрикс. Для тех, кто дочитает до конца, бонусом будет чек-лист для тестирования.
Вдохновил на этот рассказ один из проектов, где клиент доверился нашей команде и предоставил возможность настроить некоторые функции интернет-магазина для удобной работы пользователей с системой. QA-специалисты получили допуск в святая святых, в backend — под этим мы подразумеваем работу в административной части и с базами данных, тестирование API. Такой подход готов поддержать не каждый бизнес, а между тем QA может создать удобные пользовательские сценарии и сделать тестирование более системным. А зачастую и сэкономить ресурсы для устранения критичных багов впоследствии.
Я рассмотрю детали работы QA-специалиста на примере настройки CMS 1С-Битрикс: Управление сайтом, приведу вводные данные, предполагаемый результат, инструменты, методологии и опыт, которые в этом помогут. А еще расскажу, как не упустить важные моменты в работе с коробочным решением от Битрикс.
Статья будет полезна не только для QA-специалистов, но и других участников команды, работающих с CMS, а также руководителей команд и проектов, представителей бизнеса.
Вводные данные и анализ
Один из наших клиентов — крупный интернет-магазин. Его нужно было перевести на новую CMS и разработать сайт с приемом онлайн-заказов. Бизнес-цель — улучшить существующую функциональность и повысить конкурентоспособность интернет-магазина в отрасли.
После анализа возможных вариантов выбрали довольно популярное решение CMS — 1С-Битрикс: Управление сайтом. Оно покрывало бо́льшую часть потребностей и бизнес-целей клиента. Что было необходимо:
1. Иметь встроенную функциональность для эффективного ведения электронной коммерции: управление каталогом, товарами и ценами, поддержка торговых предложений, складской учет, управление акциями/скидками/промокодами.
2. Сохранить текущий уровень управления каталогом с расширением возможностей данной функциональности. В этом помогает интеграция с 1С – контроль и обработка заказов, доставки, а также работа со складским учетом и управление закупками.
3. Безболезненно перенести имеющиеся способы оплаты и доставки с перспективой расширения количества интеграций. Система дает возможность интеграции с распространенными эквайринг- и кредитными системами, а также службами доставки.
4. Сократить потенциальные издержки времени на обучение — это одно из основных желаний клиента. Выбранная система имеет большое количество документации в открытом доступе для обучения работы сотрудников, что решает данный запрос.
Решение подходит для крупных проектов, которым необходима синхронизация с системами 1С и возможность кастомизации под задачи бизнеса. Однако чтобы воспользоваться всеми преимуществами CMS, требуется разобраться в ее интерфейсе, поэтому для настройки требуется привлечь специалистов.
Подготовка к работам
После того как определили и согласовали основные задачи, стек технологий, мы собрали команду, выстроили воркфлоу взаимодействия.
В команду вошли:
project-менеджер — организация, планирование и корректировка работы команды, сроки, скрам-активности
аккаунт-менеджер — коммуникация и организационные вопросы с заказчиком
аналитик — сбор и анализ требований, работа с ТЗ
2 frontend-разработчика — верстка, разработка клиентской части
4 backend-разработчика — логика, интеграции
3 QA-специалиста — процесс тестирования, контроль качества
дизайнер — макеты, консультирование по дизайну
Мы с QA-командой, готовясь к тестированию, традиционно начали с тест-плана. В него, помимо стандартных аспектов, включили проверки технической составляющей (и рекомендуем делать это на других проектах). Мы проверяли:
работу в админке, пользователей, матрицу доступов
версию Битрикс
установленные компоненты
состав агентов
состав миграций
интеграции
e2e-тесты
Нужно было учесть, что пользователи системы — не только покупатели в публичной части, но и операторы, маркетинг- и контент-менеджеры, которые в основном работают с административной частью приложения. Поэтому необходимо заложить время на тест данной области. Что учитывали:
удобство и понятность работы в админке с инфоблоками, highload-блоками и прочими инструментами для каждой из групп пользователей
понятность выставления акций согласно политике бизнеса
разграничение доступов в разделы для отдельных групп
Работы
В CMS Битрикс входит ряд модулей, среди которых торговый каталог, акции, складской учет, конструктор отчетов. Мы рассмотрим, как проходила настройка и проверка тех элементов, с которыми работали на проекте:
Акции
Прототипирование и дизайн
Функциональность, валидация
Локализация проблем
Ядро Битрикса
Импорт, интеграция, каталоги
Акции
Большинство функций, которые используются в интернет-магазине, уже встроены в решение «Управление сайтом» и подходят под стандартные скидки и акции. Готовые решения можно приобрести в маркетплейсе от 1С-Битрикс.
Но бизнес-требования могут меняться, обрастая своими особенностями. Например, условия акции могут выглядеть не только так:
Скидка 15% на все ноутбуки с 01.08 по 01.09
Но и так:
Скидка 15%, но не более 10 000 рублей на ноутбуки бренда Х, не отображать скидку в каталоге неавторизованным; не применять скидку для товаров с признаком 1
Или
Скидка 30% на бренд Y, суммировать 30% с основной скидкой 5% (на всё), только для авторизованных пользователей
При этом мы имеем несколько видов цен, которые приходят из учетной системы.
Это значит, что нужно проверять приоритеты отображения цен и скидок. Для реализации такого рода акций необходимо выставить условия в системе в разделе маркетинга, использовав несколько элементов скидок и правил работы с корзиной. В частных случаях стандартный компонент придется кастомизировать разработчикам.
Кейс №1
Рассмотрим на примере последней скидки, как мы решили кейс, и как выглядело тестирование такой скидки.
Предусловия:
Вводные: скидка 30% на бренд X, НЕ суммировать 30% с основной скидкой 5% (на всё); только для авторизованных пользователей.
Скидка1 — 5% на всё
Скидка2 — 30% на бренд X
Скидка3, Скидка4,...N — другие акции
Скидка1 и Скидка2 не должны пересекаться
3 товара в корзине: 1 из них Товар1 бренда X
На первый взгляд, кейс решается выставлением приоритетов скидок и запретов на дальнейшее применение. Исходя из условия, что на сайте всегда действует скидка 5% на весь ассортимент, нам нужно, чтобы скидка 30% применялась только на товары бренда X без скидки в 5%. Первый вариант условия, согласно приоритетам, будет выглядеть так:
При проверке работы мы видим, что ожидаемый результат не достигнут. Основная скидка и скидка на бренд не должны суммироваться на Товаре1. Стандартная скидка в 5% должна применяться по умолчанию, если не применены другие акции, а значит приоритет у Скидок != Скидке1. Выставляем приоритеты в обратную сторону, чтобы сначала применились дополнительные акции:
Предварительный результат: основная скидка снова применяется и суммируется с дополнительной для Товара1.
Чтобы избежать суммирования, нам нужно исключить применение основной скидки, если на товар уже была применена другая скидка с помощью дополнительных условий:
Фактический результат: на Товар1 применяется только скидка 30%, на Товар2 и Товар3 применяется только основная скидка 5%.
Как выглядели бы проверки этого механизма? Учтем дополнительное условие: оплата только онлайн.
Начнем с публичной части, пройдемся по верхнеуровнему чек-листу:
На цену товара в листингах (основной, акции, распродажа и прочее) не действует скидка 7%
В корзине применяется промокод 7% только на ноутбуки бренда X для авторизованного пользователя
В корзине НЕ применяется промокод 7% на ноутбуки бренда X для НЕавторизованного пользователя
После авторизации у пользователя появляется возможность зайти в корзину и применить промокод
На чекауте (странице оформления заказа) отображаются те же цены, что и в корзине для всех пользователей
При добавлении в корзину нового товара с брендом != N промокод продолжает действовать как раньше
При добавлении в корзину нового товара с брендом = N промокод начинает действовать и на новый товар
При удалении из корзины последнего товара бренда N, промокод перестает действовать
При удалении из корзины товара Бренда != N, промокод остается активным
В оформленном заказе в ЛК (личном кабинете) стоимость совпадает со стоимостью на чекауте и чеке
В админской части в функциональности создания акций проверки будут выглядеть так:
Создание скидки доступно для юзера с правами группы «Маркетинг»
Установленные параметры скидки сохраняются согласно выставленным условиям
При изменении параметров скидки не меняются данные в уже оформленных заказах
При изменении параметров скидки данные меняются в корзине и чекауте при применении промокода
Состав заказа и сумма каждой единицы заказа с чекаута совпадает с данными в админке
Данные ушли в учетную систему и соответствуют данным оформленного заказа
При изменении данных заказа в админке происходит синхронизация данных с ЛК юзера
Получая доступ к работе в админке, QA имеет возможность в процессе тестирования комбинировать условия скидки в стандартных и кастомных механизмах Битрикса. Таким образом, специалист ближе знакомится с механизмами маркетинга системы еще на этапе тестирования и сможет проверить работу списка акций, который заранее зафиксировал отдел маркетинга клиента. Это поможет сэкономить клиенту время и бюджет. Несоответствия могут обнаружиться на ранних этапах, а не после приемки, на этапе подготовки контента перед продом.
Кейс №2
А как протестировать скидку, которую требуется обработать уже после того, как ее время действия истекло?
Например, скидка на определенные разделы каталога действует с 1 по 31 августа. Заказы, совершенные в последние дни августа, операторы будут обрабатывать в начале сентября. Обработка заказов включает в себя звонок клиенту, уточнение данных заказа и возможные корректировки в доставку, состав заказа. После внесения подобных изменений происходит пересчет заказа.
В работе нашей кастомизированной системы была особенность – после пересчета заказа могла слететь скидка, если ее период действия был завершен. И, как следствие – это приводило к рассинхрону данных с учетной системой и данными в ЛК пользователя. Вызвано это особенностями работы Битрикса из-за кастомизации стандартного компонента. В ходе работы QA-специалиста с настройками акций мы нашли решение. В момент завершения скидки, за несколько часов, нужно было совершить два шага:
Шаг 1: продлить дату окончания работы скидки на месяц – этого периода хватало для завершения работы со всеми заказами из периода акции.
Шаг 2: переключить группу пользователей с Зарегистрированных пользователей на группу Администраторов и Операторов.
Таким образом, скидка больше не отображалась в публичной части для пользователей интернет-магазина, но ее видели Администраторы и Операторы, которые работали с заказом. Формально акция продолжала действовать, и при пересчете заказа данные оставались актуальными. Но обычные пользователи, без роли Администратора или Оператора, не могли воспользоваться акционными условиями.
Важно и то, что мы помогли клиенту избежать больших затрат бюджета. Дело в том, что изменение работы стандартного компонента Битрикса требует много времени на разработку, тестирование и почти всегда — на исправление багов. В случае с акциями требуется проверка в каталоге, в карточке товара, в корзине, на чекауте, в заказе, а также при различных условиях. Эти проверки занимают много времени, и чем сложнее акция, тем больше времени на ее проверку требуется. Поэтому было важно, что наша команда избежала доработки и тестирования исправления данной особенности. Эти задачи заняли бы около трех недель.
Для тестирования нашего решения нам пригодится методика из техник тест-дизайна — таблица принятия решений:
Прототипирование и дизайн
Практически в каждом процессе разработки MVP присутствует этап прототипирования/дизайна. Битрикс является коробочным решением, в котором уже реализованы технические страницы в административной части. С большой вероятностью интерфейс этих страниц не будет меняться. Исходя из этого, отрисовывать эту часть админки не нужно: например, вывод логов в HL-блоке или работу с заказами в нестандартном решении. К тому же, при первом же обновлении системы вся красота может с легкостью слететь. Можно сохранить первоначальный вид данных страниц, и это будет удобно для работы. К тому же, это сократит время и бюджет на работу дизайнера, разработчика и QA.
Функциональность, валидация
Продолжая разговор о тестировании админской (backend) части — не рекомендуем пренебрегать валидацией. Ошибкой будет считать, что раз здесь все стандартно, из коробки, то проводить валидацию не нужно. Впоследствии это может привести к расхождению ожиданий клиента и реализации, или к затянутому онбордингу пользователей админки. В данном случае можно и нужно привлекать QA к работе в бэковой части. Важны следующие пункты:
Инфоблоки / Справочники
Отчеты
Каталог (структура, товары и прочее)
Интеграции с учетной системой
Например, без достаточно детальной и работающей в соответствии с запросом клиента системы отчетности время на получение, консолидацию и обработку информации будет уходить в разы больше. А инфоблоки не должны дублировать информацию и должны располагаться в соответствии с логической последовательностью использования. QA-специалисты проверят эти части с точки зрения удобства работы в админке, а также на соответствие ожиданий бизнеса и правильной технической составляющей.
Локализация проблем
Обозначу еще один плюс работы QA в админке — локализация проблем. Если в публичной части будет обнаружен баг, то это может быть проблема в настройках внутри компонентов админки. Понимание того, как эта «машина» работает изнутри, даст возможность локализовать и устранить проблему, не привлекая разработчиков к решению.
Пример: разработчик передал на тестирование задачу с отображением новых элементов на странице. Залив изменения на стенд и перейдя к веб-интерфейсу, мы видим частичное отображение новых элементов. Мы очистили кеш на браузере, но обещанных элементов так и не обнаружили на странице. Первым шагом в подобной ситуации стоит очистить битриксовый кеш. Это проводится в админке на вкладке Автокеширования. После этого шага, если дело не в коде, заявленные элементы отобразятся на странице.
Ядро Битрикса
Особенностью коробочного решения Битрикс является ядро – это основа программного продукта. Набор определенных правил и инструментов, которые, в свою очередь, может использовать команда разработки. При необходимости, его можно доработать, но важно реализовать это правильно, так как каждое обновление ядра – это риск потери реализованной функциональности.
В данной ситуации нужно понять, какая функциональность или около функциональность будет изменена, выстроить регрессионное тестирование на этой основе, и обязательно проверить основной бизнес-процесс.
Импорт, интеграция, каталоги
Работа CMS Битрикс — это, как правило, и работа с учетными системами, наш кейс с переездом не исключение. В таком случае мы должны понимать, что для корректной работы с каталогами необходим непрерывный импорт данных по разделам, товарам и складам из учетной системы. Это реализовывается посредством API или брокеров, например, Kafka.
Одним из основных аспектов работы в CMS Битрикс является заказ. Это тот раздел, где особенно важны правильность обработки и передачи информации между сайтом и интеграциями: информацию и покупателе, статус и состав заказа, примененные акции, остатки, данные по доставке и оплате, комментарии и другая дополнительная информация.
Для того чтобы подружить кастомизированную 1С-конфигурацию и новый сайт, нужно обозначить все необходимые сущности, свойства и особенности на этапе планирования. Также важно понимать не только то, что сайт отдает, и какие триггеры будут на это работать, но и то, что сайт принимает от учетной системы. Стоит закладывать тестирование с учетом рисков и коммуникаций со смежными командами интеграций.
Вывод
Мы рассмотрели элементы CMS Битрикс, с большинством из которых плотно работали, проверяя качество и надежность реализации. Это стало возможным не только благодаря опыту и экспертизе, но и решению клиента. Оптимальный объем времени и трудозатрат мы использовали максимально эффективно как для бизнеса, так и для команды.
На примере процесса тестирования становится понятно, что не стоит опускать этап погружения QA в особенности 1С-Битрикс, ведь это бесценная инвестиция в качество и сокращение времени.
Несмотря на то, что используется коробочное решение, в котором функциональность в основном ведет себя предсказуемо, изучение решения и валидация его под клиента поможет попасть в ожидания бизнеса и помочь ему реализовать продукт под его требования и цели.
Чтобы этот материал был для вас еще полезнее, мы подготовили чек-лист тестирования Битрикс, который вы можете использовать в своей работе.
Спасибо за внимание!
Больше авторских материалов для QA-специалистов от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.
