Home

Автор: компания Simbirsoft

Меня зовут Владимир, я SDET-разработчик из компании SimbirSoft. Я расскажу о том, как мы с коллегами на одном проекте настроили автоматизацию 40% smoke-тестов — за полтора месяца и в два этапа. Опишу ход работы и основные возможности автоматизации на проекте. Клиент был крайне ограничен в сроках и планировал отдать часть наших задач команде собственных разработчиков, но в итоге все работы выполняли SDET-специалисты — я расскажу, почему это лучший вариант из возможных.

Статья будет полезна SDET-разработчикам, QA-специалистам, project-менеджерам и тимлидам на проектах, где планируется или внедряется автоматизация тестирования. 

Задача

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

Это приложение представляет собой программный пакет для разработки прикладного ПО автоматизированного рабочего места оператора. В приложение входят системы сбора, обработки, архивирования и отображения информации в реальном времени, а также есть опция предоставления архивных данных. Клиент распространяет приложение среди своих пользователей и предоставляет им возможность кастомизации под свои запросы.

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

На старте в команду от SimbirSoft вошли project-менеджер, SDET-специалист (это был мой коллега), DevOps, QA, backend и frontend-разработчики. 

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

… И то, что за задачей скрывалось 

Возникает вопрос — если у клиента есть своя команда, зачем подключать кого-то еще?

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

Согласно стандарту, принятому у нас в компании, обычно процесс настройки автоматизации происходит так: в качестве первоочередных кандидатов мы выбираем часто используемые сценарии работы пользователя с продуктом. Затем создаем фреймворк для автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках, выбираем подходы к подготовке тестовых данных. Подробнее этапы рассматривали в другой статье.

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

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

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

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

Но после более глубокого ознакомления и погружения в структуру проекта команда выявила факторы, кардинально меняющие подход к задаче: 

1. Приложение имело микросервисную архитектуру с довольно сложной системой создания бизнес-процессов и нотаций (BPMN, Business Process Model and Notation), поэтому было сложно определять, где «наследили» тесты.

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

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

2. Модели бизнес-процессов и нотации создавались через файлы шаблонов посредством экспорта в систему и дальнейшей их настройки. 

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

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

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

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

Реализация

Этап 1

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

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

Однако спустя две недели вновь клиенту понадобилась помощь. Вариант с подключением собственных специалистов ему осуществить не удалось. Мы не углублялись в причины, но можем предположить, что разработчики со знанием Java были заняты на своих задачах и не могли уделить достаточно времени поддержке автотестов, учитывая сжатые сроки разработки перед показом инвестору.

Этап 2

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

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

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

Результат

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

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

В сжатые сроки мы реализовали эффективный и простой фреймворк с возможностью использования как для регресс-тестирования, так и для тестирования установки и настройки приложения, автоматизировали end-to-end-проверки основных бизнес-сценариев и настроили запуск фреймворка на CI клиента.

Что дальше?

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

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

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

Обсудить в форуме