Как Эм Си Арт используют автотесты в порталах, повышают качество разработки и сокращают время тестирования
Корпоративный портал Битрикс24 в среднестатистической компании постоянно меняется: разработчики дорабатывают внутренние сервисы и интеграции, появляются новые функции. После каждого заметного изменения команде нужно убедиться, что рабочие сценарии сотрудников продолжают работать.
В Эм Си Арт часть таких проверок успешно переложили на автотесты — программы, которые сами проходят по порталу как обычный пользователь и проверяют заданные тестировщиками рабочие сценарии. Как поделился руководитель направления тестирования Эм Си Арт Валерий Сидорук, первые запуски на двух реальных проектах показали, что проверки, на которые вручную уходили десятки минут или несколько часов, можно выполнить за несколько минут.
О компании Эм Си Арт
Эм Си Арт внедряет, дорабатывает и сопровождает корпоративные решения, в том числе на базе Битрикс24. Компания работает с крупными порталами, CRM, документооборотом и другими внутренними системами бизнеса.
Команда одновременно сталкивается с большим количеством разных Битрикс24. Где-то клиент использует преимущественно стандартные возможности платформы, а где-то поверх неё созданы кастомизированные крупные доработки. Все эти порталы нужно обновлять и развивать, а после изменений — проверять.
Когда в работе нужно тестирование
Проверки нужны после обновлений самого Битрикс24 и после изменений, которые вносит команда проекта. Разработчик может исправить ошибку или добавить что-то новое. При этом всегда есть вероятность, что изменение затрагивает и другие части системы. Поэтому перед выпуском и после него команде нужно убедиться, что основные рабочие сценарии сохранились.
Здесь лучше прояснить несколько терминов, которыми мы будем пользоваться дальше:
- Стейдж — тестовая площадка, максимально похожая на рабочую. На ней можно безопасно проверять обновления и изменения до запуска на рабочем портале.
- Прод — рабочая площадка, которой уже пользуются реальные сотрудники компании.
- Merge Request, или MR, — запрос на добавление подготовленных разработчиком изменений в основную версию проекта. В одном из проектов Эм Си Арт после добавления таких изменений на рабочий портал автоматически запускаются автотесты.
Что именно нужно проверять в Битрикс24
У Битрикс24 есть облачная и коробочная версии.
Облачная работает на инфраструктуре Битрикс24, а коробочная устанавливается на железо компании и даёт больше возможностей для изменения системы и её исходного кода.
При этом внутри любого портала можно условно разделить штатную функциональность и кастом. Штатная — это стандартные возможности Битрикс24: CRM, задачи, Диск, мессенджер, поиск. Кастом — функции, которые отдельно создали или серьёзно изменили для конкретного клиента.
Эм Си Арт применяли свой набор автотестов на коробочных порталах, и начали именно со штатных функций Битрикс24: они повторяются на многих проектах, и один базовый набор тестов можно адаптировать и использовать снова.
Какие проблемы с тестированием были раньше
До появления автотестов проверки в основном выполняли вручную. Для этого после изменения тестировщик открывал портал и последовательно проходил нужные сценарии: например, заходил в раздел, создавал объект, нажимал кнопки и проверял результат.
Регрессионное тестирование — повторная проверка уже работающих функций после изменений. Оно помогает обнаружить ситуации, когда новая доработка случайно сломала то, что раньше работало.
Широкий ручной регресс требует времени, поэтому на него не всегда можно получить согласование. Из-за этого команда могла ограничиться проверкой новой функции и ближайшего к ней окружения. При этом внутренняя аналитика Эм Си Арт показывала, что ошибки иногда возникали и в соседних разделах, до которых такая проверка уже не доходила. В итоге появился внутренний запрос: переложить на автоматизацию хотя бы повторяющиеся проверки штатного Битрикс24.
Как работают автотесты Эм Си Арт
Команда создала набор тестов на JavaScript и Playwright — инструменте для автоматического управления браузером. Playwright открывает Битрикс24 и выполняет действия примерно так же, как их выполнял бы человек: авторизуется, переходит между страницами, нажимает элементы интерфейса, проверяет результат. Что охватывает базовый набор: CRM, Диск, сотрудников, группы, мессенджер, профиль, поиск, ленту и задачи.
При создании тестов команда ориентировалась на элементы самого интерфейса, и такой подход помог заметить характерные проблемы после обновлений: например, если исчезла нужная кнопка или перестала нормально работать страница. Есть и обратная сторона — при изменении интерфейса сами тесты тоже приходится актуализировать. Кроме того, перед запуском на новом проекте нужно обследовать портал: проверить, какие штатные функции отключены или изменены и какой кастом влияет на стандартные сценарии.
Автотесты на первом портале
Первым стал клиентский портал для работы с продажами, заказами и документами.
Его важнейшая часть — большая кастомная система документооборота на бизнес-процессах. При тестировании ей уделяли больше всего внимания, поэтому стандартные функции Битрикс24 при обновлениях проверялись менее подробно. Перед первым запуском набор автотестов пришлось адаптировать из-за кастомизации портала: например, отличалось левое меню, а часть возможностей была отключена. На первоначальную настройку ушло около семи часов. Пришлось обновить около 60% тестов, хотя большинство изменений были точечными.
Затем тесты запустили на двух площадках, результаты получились такие.
- На стейдже широкий прогон основных разделов занял около 20 минут вместо ориентировочных 2–3 часов ручной работы.
- На рабочем портале короткий smoke-набор — быстрая проверка по одному основному сценарию в ключевых разделах — занял около 10 минут вместо 30–60 минут вручную. Критических дефектов этот прогон не нашел, а дополнительная ручная проверка не выявила сценариев, которые автотесты пропустили.
Дополнительная проверка проводилась для контроля и фиксации результатов при первом боевом применении автотестов. В нормальном режиме уже пройденные сценарии руками не перепроверяют.
Автотесты на втором портале
Второй портал отличался небольшим количеством кастома, здесь нужно было встроить проверку штатных функций прямо в регулярный процесс разработки.
После того как изменения из Merge Request добавляют в основную версию проекта и запускают на рабочем портале, автоматически стартует набор из 12 smoke-тестов. Таким образом команда получает быструю проверку портала после очередного изменения. Но — конкретно такое решение было принято с клиентом. Поэтому регламент запуска может быть каким угодно: периодическим, привязанным к MR, инициируемым вручную.
Что в результате:
- Автоматический прогон занимает около пяти минут, тогда как вручную те же сценарии проверялись бы примерно полчаса.
- Первичная настройка потребовала чуть больше двух часов.
- Во время одного из запусков тесты обнаружили уже реальную ошибку: в меню «Поделиться» использовалась неправильная ссылка на папку. Для клиента этот сценарий был связан с одним из основных рабочих процессов, поэтому такой дефект мог быстро стать проблемой для пользователей.
Что это дает командам клиентов и бизнесу
Главный эффект для команды — сокращение повторяющейся рутинной работы.
После обновления тестировщику не приходится каждый раз заново проходить один и тот же базовый набор сценариев: его можно запустить автоматически и за несколько минут получить результат. Поэтому теперь стандартную часть портала можно быстро проверить и освободить тестировщикам время для более сложных задач. Но сложный кастом конкретного клиента по-прежнему требует отдельного ручного тестирования или специализированных автотестов.
В планах — продолжать расширять покрытие стандартных разделов и разработку автоматизации кастомных сценариев. Среди других направлений облачные Битрикс24 и возможность передавать тесты клиентам, чтобы они могли запускать проверки самостоятельно.