Кейс по e-commerce. Как мы превратили регресс из болота в турбопоезд за 4 часа

7 августа7 авг

5 мин

Оглавление

Регресс в e-commerce с 7 дней до 4 часов. Как стабильность платформы подняла конверсию fashion-маркетплейса на 8%
Что было у клиента
Итак, что мы сделали?

Регресс в e-commerce с 7 дней до 4 часов. Как стабильность платформы подняла конверсию fashion-маркетплейса на 8%

Иногда проект выглядит как витрина магазина на Арбате: всё блестит, всё работает, а на самом деле зайдешь, другой стороны, посмотришь на изнанку, а там куча ручной работы, багов и костылей… Мы как раз пришли в такую ситуацию к одному из крупнейших fashion-маркетплейсов Европы, с более чем 2 млн пользователей каждый месяц. Fashion-ритейл – сфера быстрая. Здесь промедление или баги бьют не только по продажам, но и по репутации. Притом моментально. Платформа большая и сложная: веб, iOS и Android-приложения, личные кабинеты поставщиков, внутренняя CRM (система управления отношениями с клиентами, в ней где хранятся все данные о покупателях и заказах), API (интерфейсы, которые позволяют разным частям системы «общаться» друг с другом), база на PostgreSQL (основное хранилище данных, как большая цифровая картотека), всё это в AWS (Amazon Web Services – облачная платформа, где физически работают все эти сервисы).

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

Что было у клиента

Новые фичи и коллекции выходили медленно — Time-to-Market (TTM) занимал 4–6 недель.
В ручном регрессе участвовали 5 тестировщиков, цикл длился 7 рабочих дней.
Количество критических багов в продакшене — от 10 до 14 на каждый релиз.
Рейтинг в сторах падал: с 4.7 до 4.1, пользователи жаловались на ошибки при оплате и оформлении заказов.
Отказы на этапе оплаты составляли 4% от всех пользователей — это реальные деньги, которые просто утекали. Органика и конверсия в покупку тоже начали падать. Ситуация уже напрямую влияла на бизнес.

Кроме всего прочего, не было никакой автоматизации, тестовой документации и, к сожалению, стратегии. Покрытие – только юнитами от разработчиков, и то меньше 20%. Команда QA больше решала вновь и вновь появляющиеся срочные задачи, чем работала на развитие. Разработчиков постоянно дёргали на «пожарную» отладку. Time-to-Market тянулся неделями, превращаясь в узкое горлышко. Классика.

Итак, что мы сделали?

Сначала – аудит. Мы разобрали текущие процессы, код и команду, выделили узкие места. Определили приоритеты: регистрация, поиск, корзина, оформление заказа, оплата — то, что должно работать всегда и везде. Сформулировали QA-стратегию, определили, какие бизнес-сценарии критичны, и какой стек подойдёт именно этому проекту. Спойлер: взяли Playwright + TypeScript для E2E и Java + RestAssured для API.

Следующим шагом было разделение ролей. Ручное тестирование забрала команда из трёх QA: у них был фокус на исследовательское тестирование, UX и новые фичи.

В параллель они всё тщательно документировали и завели данные в TestRail. Автоматизацию (два SDET) взяли на себя: построили фреймворк, написали E2E тесты на Playwright + TypeScript, API закрыли на Java + RestAssured. Всё это сразу же интегрировали в CI/CD на GitLab. Теперь каждый коммит в develop запускал регрессию сам, без участия людей, давая почти мгновенную обратную связь по изменениям.

И ещё один важный этап – нагрузка. Для e-commerce критически важный момент. Смоделировали “Чёрную пятницу” с помощью k6: 12 тысяч одновременных пользователей. Нашли узкие места – база PostgreSQL и API-шлюз – и устранили их до того, как начались реальные пиковые нагрузки. Это дало уверенность, что платформа выдержит и пиковые нагрузки.

Итог

Через пару месяцев работы с заказчиком результат почувствовали и команда, и бизнес.

Время регресса сократилось с 7 дней до 4 часов. Это полностью автоматизированный запуск, встроенный в пайплайн.
Качество релизов явно пошло вверх. Количество критичных багов в продакшене упало на 95%. Сейчас в среднем один баг, и тот не всегда.
Покрытие тестами выросло до 85% по API и 75% по ключевым E2E-сценариям.
Скорость выхода (TTM) сократилась 2–3 раза – от идеи до продакшена теперь неделя-две, а не 4–6 недель.
Эффективность команд стала заметна. QA-команда разгрузилась, разработчиков освободили от постоянной “вечно срочной” отладки – по сути, мы освободили 1,5 фуллтайма.
Экономика в плюсе. Затраты на обеспечение качества снизились на 30% за первый год (по словам клиента), что сам клиент отметил как экономию на качестве.
Бизнес-метрики показали, что рейтинг приложений в сторах вырос до 4.6 за 7 месяцев, а конверсия в покупку прибавила 8%.

Почему наша работа принесла быстрый результат?

Потому что мы начали не с автотестов, а с целей и стратегии. Вместо того чтобы «прикручивать Playwright «ради галочки», мы построили систему, где автоматизация отвечает на конкретные бизнес-вопросы: как быстрее выкатывать релизы, как не пропускать критичные баги, как освободить ресурсы внутри команды. Когда тестирование воспринимается не “чеклист ради отчёта”, а понятная стратегия, результаты не заставляют себя ждать.

Автотесты стали частью CI/CD, а не отдельной вселенной, в которую никто не заглядывает. Регресс больше не тормозит релиз, а наоборот даёт зелёный свет. Это экономия, управляемость и предсказуемость. Мы не просто ускорили процессы, а буквально вернули продукту лицо: стабильность, скорость и доверие пользователей.

Из этого проекта мы вынесли главную мысль, которую стараемся донести до всех владельцев бизнеса: автоматизация работает, когда ей дают правильную основу. Без стратегии, нормальной документации и связи с бизнесом никакой Playwright не спасёт, хоть ты тресни. А вот если заложить QA-фундамент, можно сэкономить деньги, ускорить релизы и выдохнуть спокойно, даже перед Чёрной пятницей или рождественскими праздниками.

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

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