Автотесты Битрикс24 на реальных проектах: первые результаты

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

Для этой задачи мы подготовили набор автотестов на Playwright и JavaScript, покрывающий простые сценарии штатного функционала Битрикс24: авторизацию, CRM, Диск, сотрудников, группы, мессенджер, профиль, поиск, ленту и задачи. После внутренних запусков на разных средах и конфигурациях, набор начали применять на реальных проектах. Сейчас есть два показательных кейса: первый клиентский прогон после обновлений и smoke-проверка, встроенная в процесс Merge Request, кейсы производились на разных порталах разных клиентов.

Порталы, на которых проходили первые запуски, заметно отличались по назначению, но в обоих было много штатного функционала Битрикс24.

Первый — клиентский портал, связанный с продажами, заказами и работой с документами. Критический и наиболее востребованный функционал – разветвленная, кастомная система документооборота, реализованная на бизнес-процессах. Присутствовал небольшой кастом и в других разделах (в основном косметический). Из-за максимального сосредоточения на данном функционале, штатный функционал Битрикс24 не получал должного внимания и проверок при обновлениях или проведении регрессов.

Второй — корпоративный портал с минимумом кастома, где клиенту потребовалось дымовое тестирование как раз по простым сценариям штатного функционала.

Оба кейса как раз подходили для обкатки готового пакета сценариев, с которым мы рвались в бой!

Проект 1: первый клиентский прогон

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

Для сравнения: вручную полный объём проверки занял бы примерно 2–3 часа, а smoke-проверка — около 30–60 минут. Уже на первом клиентском применении это дало кратное ускорение: примерно в 5,5–7 раз для полного набора и в 4–6 раз для smoke.

Подготовку важно оценивать отдельно от обычного запуска. Около 7 часов ушло на первую настройку и актуализацию под фактическое состояние портала: изменённое левое меню, отключённые элементы штатного функционала, отдельные отличия сценариев, настройку репозитория и командные встречи. В итоге было обновлено около 60% тестов, но изменения в основном оставались точечными. Критичных дефектов прогон не выявил, небольшие несоответствия вызванные точечными кастомными изменениями и пара падений, связанных с инженерной реализацией. Сам штатный функционал не пострадал при обновлении и работал корректно. Ручной аудит после выполнения (не включён в расчёт, проводился в исследовательских целях) не выявил пробелов в отработке тестов.

Проект 2: smoke-тесты после Merge Request

На втором проекте акцент был другим: автотесты встроили в регулярный процесс работы с изменениями. После слияния Merge Request автоматически запускается smoke-набор, который проверяет основную штатную функциональность портала после развертывания в рабочей инфраструктуре.

В набор вошли 12 smoke-тестов по базовым пользовательским сценариям. Их автоматический запуск занимает около 5 минут, тогда как ручное прохождение тех же сценариев потребовало бы примерно 30 минут. Первичная настройка заняла более двух часов, но это разовая работа для текущего проекта, а на следующих проектах такой запуск должен настраиваться быстрее, потому что процесс уже отлажен.

В ходе тестирования удалось выявить конкретный дефект: в меню «Поделиться» использовалась некорректная ссылка на папку. Остальные проверяемые сценарии завершились успешно. Это как раз тот случай, ради которого smoke-набор имеет смысл держать в процессе: он быстро показывает, можно ли двигаться дальше, и подсвечивает проблемы до того, как на них наткнутся пользователи.

Сравнение результатов

Что это дает команде и бизнесу

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

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

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

• Управляемость: команда понимает, что именно проверено, сколько это заняло, где есть дефекты и какие тесты требуют актуализации.

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

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