1. Главная
  2. Блог Эм Си Арт
  3. Автотесты Битрикс24: что это и для чего нужны

Автотесты Битрикс24: что это и для чего нужны

1 Разработка

  1. Немного о Битрикс24 и его особенностях.

  2. Что такое автотесты и зачем они нужны в проектах на Битрикс24.

  3. Автотесты в Битрикс24: сложности, проблемы и выгоды.

  4. Выбор инструмента для автотестов.

  5. Планирование внедрения: от идеи к рабочему инструменту.

  6. Что дальше: масштабирование и развитие автоматизации.


Для начала следует уделить пару слов продукту, лежащему в основе всей нашей работы — Битрикс24. Что же это и почему при работе с ним так хочется использовать автотесты?

Немного о Битрикс24 и его особенностях

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

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

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

Идея внедрить автоматизацию тестирования в наших проектах на Битрикс24 возникла из вполне практичной задачи. С каждым обновлением платформы и каждым релизом мы снова и снова возвращались к одним и тем же проверкам штатного функционала — дымовым тестам и регрессионным сценариям, без которых невозможно безопасно выпускать изменения.

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

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

Что такое автотесты и зачем они нужны в проектах на Битрикс24

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

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

Автотесты в Битрикс24: сложности, проблемы и выгоды

Автоматизация тестирования в Битрикс24 заметно отличается от того, как это выглядит в большинстве веб-проектов. Платформа живая, постоянно обновляется и активно использует динамический интерфейс. Даже сценарии, которые с точки зрения бизнеса выглядят простыми и понятными, на уровне пользовательского интерфейса оказываются не такими прямолинейными. Это одна из причин, почему автотесты в Битрикс24 до сих пор остаются скорее исключением, чем стандартной практикой.

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

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

И вот, решившись, мы встали перед самым важным вопросом: на чём, собственно, писать тесты?

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

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

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

  • наш стек разработки и опыт команды ближе к JavaScript, чем к Python, а значит помощи при написании и отладке тестов от разработчиков ждать проще при непринципиальной разнице в сложности самих языков для тестировщика;

  • Playwright хорошо интегрируется с нашей CI-инфраструктурой;

  • инструментарий показывает себя удобным для тех, кто впервые работает с автотестами

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

Планирование внедрения: от идеи к рабочему инструменту

Итак, инструмент выбран, с чего же начать? Первый этап автоматизации мы изначально рассматривали максимально прагматично. Наша цель была простой и измеримой: покрыть автотестами базовые сценарии штатного функционала Битрикс24, чтобы сократить трудозатраты на регрессы и проверки после обновлений. Параллельно — аккуратно проверить гипотезу о том, что автотесты в Б24 можно использовать не только «в теории», но и в живых проектах.

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

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

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

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

Что дальше: масштабирование и развитие автоматизации

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

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

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

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

Автоматизация тестирования в Битрикс24 для нас — не разовый эксперимент. Это осознанно выбранное направление, которое мы последовательно развиваем и интегрируем в реальные проекты. Для Эм Си Арт — это новый фронтир, на котором придётся столкнуться ещё с огромным количеством трудностей, но мы уверены, что итоговый результат того стоит!

Похожие записи в блоге

Все статьи