Комплексная автоматизация тестирования продукта со сложной архитектурой

Заказчик

Продуктовая ИТ-компания (Англия, Великобритания).

Продукт

Система управления запасами и заказами для дистрибьюторов и электронной коммерции, включающая ERP, CRM и систему складского учёта.

Бизнес-вызовы

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

Технологические особенности проекта

Система имеет большой codebase с нетривиальной, запутанной архитектурой и смешанными слоями кода (бизнес-слой, работа с базой данных, контроллер, UI), что делает её сложно поддерживаемой. Unit-тесты практически отсутствуют, в Definition of Done их нет, как и требований к уровню покрытия кода. Проверка качества продукта осуществляется не системно и только с помощью мануального тестирования. Компоненты системы не изолированы, из-за высокого уровня связанности при малейших изменениях кода возникают баги. Продукт очень сложно масштабировать, внедрять новые функции.

Не внедрены принципы непрерывной интеграции и поставки (CI/CD), сборка продукта и обновление серверов осуществляется вручную, что негативно сказывается на скорости поставки продукта.

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

Диаграмма: Комплексная автоматизация тестирования продукта со сложной архитектурой

Подходы и решения

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

Контроль качества должен был стать важнейшей частью жизненного цикла проекта. До включения команды JazzTeam тестирование на проекте осуществлялось ситуативно, роль тестировщика выполняли разработчики и один из владельцев продукта. Мы проанализировали текущие проблемы с качеством и нестабильностью продукта и предложили заказчикам расширить команду специалистами по ручному и автоматизированному тестированию. Наша компания взяла на себя задачу построения профессионального тест-менеджмента.

Для борьбы с постоянными задержками релизов было решено пересмотреть процесс эстимирования задач, чтобы все участники команды могли реалистично понимать текущий статус. Кроме более чёткой декомпозиции трудозатрат на виды работы (BA, проектирование, разработка, автоматизированное и ручное тестирование, баг-фиксинг и др.), была введена унифицированная таблица возможных рисков. По каждому риску для каждой задачи выставлялась вероятность наступления риска, что влияло на изначальную эстимацию. Также для каждого вида работ появился список критериев выполнения задачи (Definition of Done), позволяющий организовать системную приёмку. Все эти меры позволяют получать реалистичные эстимации, которые обеспечивают планирование поставок без задержек.

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

Внедрение CI/CD для осуществления автоматической сборки, регулярной проверки качества и автоматизации поставки продукта. Данный процесс был сложным, болезненным и требовал проведения целого ряда исследований для достижения полной автоматизации сборки, в том числе по обеспечению автоматической сборки выполняемых файлов продукта и внедрению Liquibase для версионного контроля на уровне базы данных. Было необходимо преодолеть недоверие со стороны команды, а также настоять на обязательном для всех применении CI/CD.
Огромный объём и отсутствие культуры управления техническим долгом критически усложнили постоянную работу с ним на протяжении каждого спринта. На первых порах было необходимо заработать доверие команды и небольшими итеративными изменениями продемонстрировать возможность, доказать смысл проработки долга даже в условиях постоянной занятости разработчиков коммерческими задачами. Мы сфокусировались на реализации автоматической сборки выполняемых файлов продукта, и смогли её реализовать малыми затратами, притом конечный эффект позволил нам начать внедрение CI/CD, что было оценено заказчиками. Также, несмотря на некоторое сопротивление, было начато несколько исследований, по которым инженеры продвигались по 1 часу в день. Такой подход позволил не потерять фокус на поставке коммерческих задач, но вместе с тем, мы последовательно продвигались по решению накопившихся технических долгов. Ниже мы приведём несколько показательных примеров проработки критических технических долгов.

Создание фреймворка для blackbox-тестирования приложения, с помощью которого мы смогли начать создание автоматизированных backend тестов. Без данного фреймворка разработчики не имели возможности создавать Unit-тесты ввиду большого codebase, с нетривиальной, запутанной архитектурой и смешанными слоями кода. Тесты запускаются как часть регулярных сборок проекта (по расписанию и по требованию), обеспечивают стабильную работу продукта при внесении изменений.

Полноценное и регулярное покрытие всего важного функционала системы GUI-автотестами. Для быстрого написания и поддержки с минимальными затратами большого количества GUI-автотестов был создан фреймворк, с помощью которого база UI-автотестов была увеличена с нуля до нескольких сотен за короткий промежуток времени (несколько месяцев). Фреймворк создан на основе паттерна PageObject и состоит из слоя доступа к хранимым данным приложения, слоя сервисов, интегрирующих слой данных и слоя утилитарных методов для упрощения управления и дальнейшего развития автотестов.

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

Результаты и достижения

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

В команде установлен ценностный подход к разработке. Владельцы продукта начали прислушиваться к предлагаемым командой инициативам, приносящим ценность в долгосрочной перспективе, сменили приоритет с достижения краткосрочных целей на стратегический подход к развитию продукта. Также владельцы продукта начали инвестировать во внедрение необходимых инженерных практик (CI/CD, Unit testing, автоматизацию тестирования). Устранению технических долгов уделяется время на протяжении каждого спринта, порождены долговременные технологические исследования.

Благодаря внедрению CI/CD процесс сборки и поставки продукта автоматизирован, стал быстрым, прозрачным и безопасным. Это позволило наладить регулярность релизов.

Сложный codebase приложения покрыт Unit-тестами, благодаря чему удалось стабилизировать качество системы при внесении изменений.

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

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