Перфоманс Лаб

Как мы помогли заказчику выстроить полный цикл автоматизации тестов всего за 3 месяца

Как автоматизировать сотни тест-кейсов в сжатые сроки — и сделать производство эффективнее? Именно с этим мы помогли российскому разработчику.

Рассказываем, как выстроили полный цикл автоматизации, заодно исправив ошибки в 200 тестах и обновив технологический стек компании.

О проекте

Клиент

Разработчик low-code платформ для бизнеса

Индустрия

Автоматизация бизнес-процессов

Продукт

Cистема для автоматизации внутренних бизнес-процессов и CRM

Результаты

  • Выстроен цикл автоматизации тестов.
  • Переписаны 200 тестов, которые нуждались в серьезной доработке.
  • Автоматизированы еще 600 тест-кейсов.
  • Обновлен технологический стек заказчика.

Исходные данные

К «Перфоманс Лаб» обратился российский разработчик, чтобы автоматизировать 600 тест-кейсов для проверки требований к своему продукту. Речь идет о low-code платформе, автоматизирующей внутренние бизнес-процессы, продажи и клиентский сервис. У нее два ядра: BPM отвечает за движение договоров, CRM помогает автоматически сегментировать клиентов, подбирать воронки продаж и анализировать сделки.

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

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

Нашими задачами были:

  • анализ тест-кейсов;
  • декомпозиция задач;
  • создание плана разработки;
  • рефакторинг текущего тестового фреймворка;
  • автоматизация генерации тестовых данных;
  • разработка автотестов;
  • презентация автотестов.

Главные вызовы

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

01
Кроме работы с 600 тест-кейсами нужно уделить внимание еще 200 тестам, которые уже были созданы заказчиком — их следовало переписать для корректной работы.
02
Кейсы оказались зависимыми: один мог повлиять на результаты другого.
03
Среда, на которой проводилось тестирование, была нестабильна, что осложняло поиск дефектов. Приходилось проводить перезапуски и выяснять, идет ли речь о баге или о случайном падении.

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

Знакомить каждого человека с системой целиком не было времени: за одним инженером закреплялась одна функциональность и 10–30 связанных кейсов. В процессе написания первых кейсов он погружался в процесс и далее легко дописывал остальные. Вся отчетность велась в таблице, в которой отражалось количество тест-кейсов, планируемые работы и отставание от графика.

Решение

Выяснив, что требуется улучшить, мы приступили к усовершенствованию стека заказчика: подняли Java до версии 17 и использовали фреймворк Micronaut для запуска тест-кейсов и выполнения API-запросов.

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

Еще одной важной проблемой оказались зависимые кейсы. Например, если мы меняли директора на его заместителя в системе, остальные кейсы «ломались».

«Мы провели поиск зависимых кейсов с переносом в отдельную группу, а также создали конфигурации прогона тест-кейсов в CI, где сначала выполняются независимые кейсы параллельно, а затем зависимые кейсы — одним потоком. Прохождение зависимых кейсов было упорядочено по нарастанию влияния на систему»

foto profilya
Илья К.
инженер по обеспечению качества

Из-за загруженности серверов с тестовыми средами имели место и ошибки, связанные с загрузкой страниц и временем ответа API. Чтобы собрать более достоверные результаты, непройденные тесты мы перезапускали до двух раз.

Еще одна проблема — атомарность тест-кейсов при наличии большого количества предусловий. Так, целью UI-теста зачастую являлась проверка компонента платформы, связанного с компонентами более высокого уровня. Например, если нужно проверить экспорт договора в PDF, для экспорта договора, в свою очередь, требуется наличие бизнес-процесса, а в бизнес-процессе должно быть не менее двух участников — и так далее. Готовить тестовые данные мы решили с помощью API-запросов. Это не только обеспечило атомарность UI-тест-кейсов, но и ускорило их прохождение за счет более быстрой загрузки веб-страниц, а также снизило нагрузку на тестовые стенды.

Необходимо было и оптимизировать работу с большими объектами передачи данных. Для построения сущностей REST API использовались как классические билдеры, реализующие создание объектов через POJO, так и билдеры, использующие загрузку шаблона и изменение отдельных его полей с использованием JSONPath. Такой подход позволил многократно упростить обработку «шаблонных» бизнес-процессов, где при наличии сотен полей изменялись единицы.

Итоги

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

По итогам работы мы усовершенствовали 200 тестов, автоматизировали 600 тест-кейсов, настроили CI и помогли заказчику перейти на более свежий стек. Тесты запускаются согласно графику, и компания получает подробные отчеты, которые генерируются автоматически.

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

foto profilya
Константин Тихоненков
руководитель отдела автоматизации тестирования

Почему важно автоматизировать тестирование

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


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


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


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

Автоматизируйте тестирование
с «Перфоманс Лаб»

Ускорьте релиз без лишних трат