В первой части гайда RuStore по доставке фичей мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей, Александр Котельников, разобрали подготовительные этапы, которые закладывают прочный фундамент для всей разработки: от Kick-off и архитектурного планирования до Technical Design и тестовой стратегии.

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

Напомним, зачем мы вообще взялись за этот гайд и кому он будет полезен:

• тем, кто хочет навести порядок в процессе доставки фичей;

• тимлидам и менеджерам, которым нужна предсказуемость;

• инженерам, которые хотят меньше хаоса и больше системности.

Всё, что описано, мы опробовали на собственных фичах в RuStore. Мы не один раз ошибались, дорабатывали, улучшали и теперь делимся рабочим подходом, который помогает нам запускать фичи спокойно, стабильно и уверенно.

Разработка и интеграция: превращаем идеи в код

Зачем нужен этот этап?

У нас есть утверждённый подробный Technical Design и понятные входные данные. Пора кодить, тестировать и интегрировать фичу в систему. 

Цель этапа — реализовать фичу в соответствии с Technical Design, интегрировать с другими компонентами системы, обеспечить отказоустойчивость, мониторинг и подготовить код к тестированию и последующему релизу.

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

Как проходит работа

1. Подготавливаем окружение

• Готовы ли нужные стенды (Dev, Stage, Test)?

• Есть ли доступы ко всем сервисам?

• Настроены ли переменные окружения?

2. Пишем код

• Разработка ведётся по задачам из Technical Design.

• Внедряем feature toggle для безопасной активации.

• Пишем основную бизнес-логику.

• Интегрируемся с другими компонентами — работа с API, базами данных, очередями сообщений.

• Настраиваем логирование, сбор метрик, алерты.

• Работаем с доработками и исправлениями — перед выкладкой фиксируем все найденные недочёты.

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

• Планируем дополнительный этап работы при необходимости (для тилида) — управляем ожиданиями заинтересованных лиц.

3. Проверяем и тестируем код

• Прогоняем локальные тесты.

• Проверяем, не сломали ли другие части системы.

Результаты этапа

• Готова реализация фичи.

• Feature toggle работают корректно.

• Задачи готовы к тестированию.

• Настроены механизмы логирования, мониторинга и алертов.

• Подготовлен код, учитывающий отказоустойчивость и обработку ошибок.

• Возможность гибкого включения и отката фичи через feature toggle.

Проверочный вопрос этапа: если фича упадёт в проде — мы поймём, почему? Сможем откатить? Если нет, надо улучшить мониторинг и логи!

Наш опыт

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

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

Разработка автотестов и реализация бизнес-метрик

Зачем нужен этот этап?

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

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

Без автотестов разработка замедляется, так как каждое изменение требует ручной проверки. А без метрик невозможно оценить влияние фичи на пользователей и бизнес-показатели.

Как проходит работа

1. Реализуем автотесты и метрики

• Покрываем ключевые сценарии юнит- и интеграционными тестами.

• Для критических сценариев разрабатываем API-тесты и проверки с UI (web/mobile).

• Настраиваем CI/CD для автоматического запуска тестов.

• Настраиваем сбор ключевых бизнес-метрик и интегрируем их в систему аналитики.

• Настраиваем дашборды и алерты в Grafana, Kibana или другом инструменте мониторинга.

2. Проверяем корректность работы тестов и мониторинга

• Автотесты успешно проходят в CI/CD без ложных срабатываний.

• Бизнес-метрики корректно собираются и анализируются.

• Алерты на критические ошибки и аномалии работают без избыточного шума.

Результаты этапа

• Готовый набор автотестов, покрывающий ключевые сценарии.

• Запуск тестов автоматизирован в CI/CD, снижая время на регресс.

• Настроены бизнес-метрики и дашборды, позволяя анализировать поведение пользователей.

• Рабочие алерты, сигнализирующие о сбоях и критических изменениях в системе.

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

Тест-дизайн и тестирование

Зачем нужен этот этап?

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

Цель этапа — проверить работоспособность фичи, выявить дефекты, убедиться в соответствии бизнес- и техническим требованиям и подготовить её к выпуску.

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

Как проходит работа

1. Определяем ключевые сценарии

• Анализируем технические требования, дизайн и верхнеуровневый тест-план.

• Определяем критические пользовательские сценарии.

• Выявляем граничные случаи и возможные ошибки.

2. Готовим тест-кейсы и тестируем фичу

• Создаём тест-кейсы и тестовые данные.

• Определяем тест-планы для CI/CD.

• Проводим тестирование:

  • проверяем базовые и критические сценарии;

  • анализируем влияние изменений на другие части системы;

  • фиксируем баги, передаём их в разработку.

• Составляем итоговую тестовую документацию.

Результаты этапа

• Готовы тест-кейсы и тест-планы.

• Проверены все необходимые сценарии.

• Зафиксированы результаты тестирования.

• Исправлены критические баги.

• Фича готова к финальной проверке перед релизом.

Быстрый тест: если QA из другой команды может взять кейс и протестировать — всё хорошо.

Наш опыт

С переходом на верхнеуровневые тест-планы мы начали гораздо точнее оценивать сроки тестирования и добиваться совпадения планов с фактом при разработке фичей. Это также помогло заранее понимать объём предстоящей автоматизации и эффективнее планировать работу над автотестами.

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

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

Что дальше?

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

Когда каждый этап работает как часы — прод уже не пугает, а становится ожидаемым итогом системной работы.

В третьей части гайда мы расскажем:

• как подготовить фичу к релизу: от финального тестирования до disaster- и нагрузочного тестирования;

• как мы настраиваем мониторинг и алерты для выхода в прод;

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

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