Как тестировать обновление Битрикс24: что ломается чаще всего

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

Эта статья — о том, как узнавать первым. Мы разбираем, где обновление ломает портал, в каком порядке это проверять и сколько времени на это закладывать. Чек-лист в конце статьи совпадает с пакетом «Битрикс24: смоук после обновления» — 36 тест-кейсов, которые читаются на сайте целиком и одной кнопкой добавляются в проект QA Деск.

Почему обновление вообще что-то ломает

Портал «из коробки» после обновления работает — это проверил вендор. Ломается то, что вендор проверить не мог: ваша конфигурация.

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

Бизнес-процессы и роботы. Роботы CRM привязаны к стадиям воронки по идентификаторам, бизнес-процессы — к полям и типам документов. После обновления, которое переименовало стадию или добавило новый статус, робот может продолжать существовать, но не срабатывать.

Доработки коробки. Собственные шаблоны сайта, компоненты, обработчики событий в init.php, модифицированные файлы ядра — всё это живёт до первого обновления, которое заменит файл, на который опиралась доработка.

Интеграции снаружи. Входящие и исходящие вебхуки, обмен с 1С, телефония, почтовые ящики. Они ходят через тот же REST и те же права, что и приложения, и ломаются по тем же причинам.

Права и настройки. Обновление может добавить новый раздел с правами по умолчанию, и обычный сотрудник вдруг видит то, что не должен, — или, наоборот, теряет доступ к отчёту, которым пользовался годами.

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

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

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

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

Что проверять: по модулям

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

Вход и навигация

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

Задачи

Модуль, которым пользуются все сотрудники без исключения. Критичные проверки: задача создаётся с ответственным и сроком; статус переключается «начать → завершить»; чек-лист в задаче добавляется и отмечается; комментарий с упоминанием сотрудника доходит адресату. Дальше — по объёму использования: канбан и перенос карточки между стадиями, вложение файла, соисполнители и наблюдатели.

Отдельно — шаблоны и повторяющиеся задачи, если они настроены. Сломанное повторение не видно в момент проверки: оно не создаст задачу в нужный день. Проверить можно, открыв шаблон и убедившись, что расписание на месте и следующий запуск запланирован.

CRM

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

Дальше — счёт из сделки и открытие клиентской ссылки, привязка контакта и компании, открытие списков лидов, сделок, контактов и компаний. Списки — важный пункт: обновление может изменить фильтры и представления, и менеджер утром увидит не свои сделки, а всё подряд.

Диск, чат, календарь

Загрузка файла на Диск и скачивание обратно, публичная ссылка на файл. Личное сообщение сотруднику доставляется, групповой чат создаётся, файл в чат прикрепляется. Событие календаря с приглашённым участником создаётся, участник может принять или отклонить приглашение. Каждая проверка — минута, и каждая закрывает модуль, где сбой заметят в течение часа.

Живая лента, поиск

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

Маркетплейс и настройки

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

Мобильное приложение

Вход, список задач, чат. Мобильное приложение обновляется отдельно от портала, и рассинхрон версий — частая причина, по которой «на компьютере работает, а в телефоне нет».

Порядок прогона и сколько это занимает

Смоук по пакету — 36 кейсов. С приоритетами внутри пакета получается два режима:

• Короткий смоук — только кейсы с критичным и высоким приоритетом: вход, задачи, CRM, Диск, чат, календарь, поиск, приложения Маркетплейса, права. Около 20 кейсов и 40 минут работы одного человека. Это режим для облака: обновление уже случилось, нужно быстро понять, есть ли пожар.
• Полный смоук — все 36 кейсов, около полутора часов. Режим для коробки на тестовой копии и для облака, если есть время до начала рабочего дня.

Порядок внутри прогона — от общего к частному: сначала вход и навигация, потом модули, потом приложения. Если сломан вход — остальное проверять бессмысленно; если не открывается раздел — не имеет смысла проверять его сценарии.

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

Как оформить прогон, чтобы он был полезен через месяц

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

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

Дефект заводится из упавшего шага. Не «после обновления не работает CRM», а конкретный шаг конкретного кейса с тем, что ожидалось и что получилось. В QA Деск дефект заводится прямо из строки прогона и автоматически связывается с кейсом; в карточке обязательно указывается, где воспроизведено — окружение и платформа, — и это спасает от путаницы «на копии сломано, на рабочем нет».

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

Если портал — Битрикс24 и команда работает в нём же, дефекты удобно вести там: приложение QA Деск для Битрикс24 добавляет вкладку «Баги» в задачу, и разработчик, который чинит доработку, видит дефекты прямо в своей задаче.

Чек-лист: обновление Битрикс24

Короткая версия для распечатки — полная, с предусловиями и шагами, в пакете.

• Версия портала изменилась — зафиксирована в прогоне
• Вход, выход, восстановление пароля, неверный пароль
• Все разделы левого меню открываются
• Задача: создание с ответственным и сроком, начать → завершить, чек-лист, комментарий с упоминанием
• Шаблоны и повторяющиеся задачи — расписание на месте
• CRM: лид вручную, конвертация в сделку и контакт, сделка до выигрыша, роботы отработали
• CRM: счёт из сделки, списки лидов и сделок открываются с правильными фильтрами
• Диск: загрузка, скачивание, публичная ссылка
• Чат: личное сообщение, групповой чат, файл
• Календарь: событие с участником, принятие приглашения
• Лента: сообщение «Всем», комментарий
• Поиск: находит задачу и сотрудника, переход работает
• Каждое приложение Маркетплейса открывается там, где им пользуются
• Вебхуки и обмен с 1С — последний обмен прошёл после обновления
• Права: обычный сотрудник не видит админ-раздел
• Мобильное приложение: вход, задачи, чат
• Регресс CRM и задач — если модули доработаны

Что дальше

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

Как устроены тест-планы и прогоны в QA Деск — в функциональной документации; как принимать отчёты автотестов из CI — на странице автотестов.