Разработка приложения для автоматизации бизнес-процессов на промышленном производстве

Задача

Перед командой SimbirSoft стояла задача создать фреймворк для автоматизации тестирования и запустить автоматизацию ключевых сквозных End-to-End (End-to-End (E2E) тестирование (сквозное тестирование) — метод проверки работы системы от начала до конца, который покрывает все её компоненты и взаимодействия) сценариев работы приложения в сжатые сроки: всего за месяц. Такая срочность обусловлена подготовкой продукта к показу инвесторам: автотесты подтверждали стабильность работы системы, четко и без сбоев. 

В проектную команду от SimbirSoft вошли проджект-менеджер, SDET-специалист (SDET-разработчик — специалист, который совмещает навыки разработчика и тестировщика, занимается автоматизацией тестирования и обеспечивает качество ПО), DevOps (DevOps — методология автоматизации технологических процессов сборки, настройки и развёртывания программного обеспечения, QA (QA-специалист — создает сценарии тестирования, прогнозирует сбои в продукте и находит в них ошибки, бэкэнд и фронтенд-разработчики. 

После окончания работ клиент планировал самостоятельно поддерживать созданный фреймворк и расширять набор автотестов силами собственной команды. 

Возникает вопрос: зачем привлекать внешние ресурсы при наличии собственной команды? 

Этому было четкое обоснование: в команде заказчика не было SDET-специалиста, а автоматизацию нужно было внедрять с нуля. Нам предстояло предложить рабочую стратегию. Оптимальное решение — долгосрочная стратегия автоматизации. 

Процесс работы

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

Архитектура приложения — микросервисная, со сложной BPMN‑системой (Business Process Model and Notation: визуальный язык, позволяющий организациям создавать подробные схемы своих рабочих процессов). При описании этих бизнес‑процессов сложно понять, в какой именно части системы тесты внесли изменения.

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

Например, при команде «Загрузить картинку» мы можем определить, в какой базе данных окажется картинка. Но чтобы найти и удалить все следы ее загрузки (записи о времени загрузки, ссылки на файл, служебные данные), команде приходилось проводить целое расследование. Это необходимость, так как автотесты должны работать стабильно и у клиента, и у пользователя.

Особенности проекта:

• модели бизнес-процессов и нотации создавались путем импорта файлов в распределенную систему и с их дальнейшей настройкой.

• объекты сохранялись сразу в нескольких базах данных — на разных уровнях системы. Объекты связаны и между собой и с основной логикой приложения, а каждое действие с ними логировалось.

• клиент был ограничен объем доступной памяти для автотестов — это требовало быстрого развертывания и удаления тестовых данных. Автотесты планировало запускать автотесты на продуктах пользователей после кастомизации, без развернутых тестовых записей на продакшене.

Мы создали методы очистки данных (с учетом сложных связей объектов и логов для их полного и безболезненного удаления), без риска удаления объектов с ядра

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

Решение

Этап 1

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

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

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

Этап 2

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

В задачи разработчика входило:

• настройка CI на двух новых стендах (CI — автоматизация процесса непрерывной интеграции в разработке ПО)

• рефакторинг и дебаг тестов, которые стали падать в связи с изменением бизнес-логики проекта

• написание новых автотестов. 

Сроки ограничены — две недели.

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

Результат

В итоге мы создали комплекс из 43 интеграционных end-to-end-тестов с большим количеством последовательных шагов, загружаемых / удаляемых тестовых данных. 

Тесты покрывали 40% от общего количества smoke-набора всего за 40 минут, запускаясь каждый день на трех стендах. Ежедневный автоматический запуск тестов в Gitlab CI/CD позволял выявлять баги на ранних этапах, что сокращало время на их исправление, не давая обрасти сломанной функциональности новыми зависимостями.

Тесты покрыли 40% smoke‑набора всего за 40 минут при ежедневном автоматическом запуске на 3 стендах через «GitLab CI/CD». Такой подход позволял оперативно выявлять дефекты на ранних стадиях разработки, и это сокращало время их устранения, не позволяя неисправной функциональности копить зависимости. 

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

В сжатые сроки мы создали эффективный фреймворк автоматизации, который:

• поддерживает регресс‑тестирование;

• позволяет тестировать установку и настройку приложения;

• автоматизирует end‑to‑end‑проверки ключевых бизнес‑сценариев;

• интегрирован с CI‑системой клиента.

Что дальше?

На данном этапе для актуальности автотестов заказчику необходимо:

• обеспечивать валидность значений в property‑файлах (текстовый формат и одноименное расширение имени файла).

• вносить минорные изменения в фреймворк при модификации логики работы сервиса

• собирать Docker‑контейнер (Docker-контейнер — изолированная среда, в которой запускается приложение и все его зависимости).

•  с актуальной версией фреймворка для тестирования установки и настройки приложения на серверах пользователей (задача для DevOps‑ или SDET‑специалистов).

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

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

Оставьте заявку на проект и получите консультацию эксперта

Оставить заявку