Построение автоматизации с нуля: как мы помогли крупнейшему фарм-ритейлеру создать собственную команду автоматизации
QA-команда клиента работала полностью вручную:
-
регресс занимал 11 часов;
-
подготовка тестовых данных и конфигурация сред выполнялись вручную;
-
каждый релиз сопровождался риском пропуска дефектов.
Мы не просто написали автотесты — выстроили процесс автоматизации с нуля и параллельно вырастили инхаус-манду, способную самостоятельно поддерживать и развивать направление. Формат «играющего тренера» позволил клиенту получить одновременно и работающий фреймворк с CI, и носителей компетенций внутри.
Клиент
B2C-платформа в сфере онлайн-ритейла с высокой нагрузкой на каталог и поиск.
Задача
Бизнес-задачи
-
Разблокировать релизный конвейер, упиравшийся в 11-часовой ручной регресс, и сократить Time-to-Market.
-
Снизить операционные риски: исключить влияние человеческого фактора при рутинных операциях (подготовка данных, конфигурация сред, ручная проверка результатов).
-
Повысить рентабельность QA-функции: не масштабировать ручной труд линейно, а создать собственную экспертизу внутри команды.
Задача в контексте разработки
-
Перевести регрессионное тестирование с полностью ручного режима (11 часов) на автоматический, встроив его в двухнедельный спринтовый цикл.
-
Обеспечить бесшовную передачу компетенций команде, не имевшей опыта автоматизации, чтобы исключить долгосрочную зависимость от внешних подрядчиков.
Решение
Что планировали сделать
Разработать гибридную модель «инфраструктура + обучение». Отказаться от сценария «усилить команду аутстаффом»: он не решал корневую проблему — отсутствие собственных компетенций.
Цель — сделать клиента самодостаточным.
Гипотезы
-
Если совместить разработку фреймворка с наставничеством на боевых задачах, скорость освоения инструментов командой вырастет кратно по сравнению с классическим теоретическим обучением.
-
Формат «играющего тренера» даст одновременный эффект: работающие тесты плюс рост инженеров.
Почему решали именно таким образом
Только такой подход позволял заказчику сразу получать осязаемый результат (покрытие автотестами) и параллельно выращивать внутреннего лида автоматизации.
Этапы и числовые показатели
1. Аудит и дизайн (1–2 недели):
-
анализ архитектуры приложения;
-
выбор стека;
-
проектирование архитектуры тестового фреймворка.
2. Построение фундамента (3–4 недели):
-
разработка базовой обвязки API- и UI-тестов;
-
настройка CI в инструменте Jenkins;
-
запуск первых «дымовых» автотестов;
-
параллельно: скрининг команды и запуск ИПР.
3. Масштабирование покрытия и обучение (4–6 месяцев):
-
еженедельные циклы постановки реальных задач;
-
код-ревью и разбор ошибок;
-
проведение 4+ срезов знаний;
-
покрытие ключевых бизнес-сценариев доведено до целевого уровня.
4. Стабилизация и экзамен (2 недели):
-
финальный замер знаний;
-
документирование процессов и передача ответственности команде.
Результат
- Время регрессионного прогона сокращено с 11 до 2 часов (экономия 82% времени, или 9 человеко-часов на каждом прогоне).
- Клиент вышел на 3 полноценных релиза за двухнедельный спринт — ранее это было невозможно из-за растянутого тестового цикла.
- Полностью автоматизирована подготовка тестовых данных и конфигурация сред — исключены ручные операции и связанные с ними ошибки.
- Более 80% QA-инженеров, прошедших обучение, успешно сдали финальный экзамен и перешли к самостоятельной разработке и поддержке автотестов.
- Обеспечена прозрачность тестирования: интеграция автотестов с Jira и CI-отчётами (Allure).
Бизнес-эффект
- Релизный цикл разблокирован: команда перешла от одного «тяжёлого» релиза к трём за спринт. Это напрямую повлияло на скорость доставки бизнес-гипотез до конечного пользователя.
- Клиент получил гибкую модель: внутренняя команда самостоятельно поддерживает и развивает автоматизацию — вендор-лок и зависимость от внешних экспертов исключены.
- Прямая экономия: 9 человеко-часов на каждом регрессионном прогоне. При регулярных прогонах это высвободило десятки часов в месяц, которые команда направила на тестирование новых возможностей, а не на повторение рутинных операций.
Трудности
1. Переключение мышления команды
Стопор: ручные тестировщики без опыта программирования сталкивались со страхом «белого листа» и сопротивлением новому.
Решение: система менторства и декомпозиция задач на минимальные, быстро достижимые шаги.
2. Баланс «производство — обучение»
Стопор: необходимо было синхронизировать темп наставничества с боевыми сроками проекта, не замедляя релизы.
Решение: жёсткая приоритизация тикетов совместно с лидом разработки клиента.
Технологии
Python, Pytest, Requests, Selenium, Selenoid, Allure, PostgreSQL, Postman, Swagger, Jenkins, Docker, Locust, DevTools, TestIT, Jira, Kibana.
