Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.
Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.
Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?
Здесь всё на личном опыте, по делу и понятно.
Содержание:
Главный принцип: QA подключается на этапе идеи
Верификация требований: держим контекст, а не только текст
Разработка и тестирование: снимаем боттлнек
Почему мы сделали ставку на системные API-flow тесты
Где мы применяем ИИ
Итог
Что такое распродажа и почему с ней сложно
С точки зрения бизнеса распродажа — это возможность для продавца привлечь покупателя скидкой, а для покупателя — купить товар по наиболее выгодной и честной цене.
С точки зрения разработки распродажа — это набор высоконагруженных сценариев и интеграций, где нельзя ошибаться:
Запуски привязаны к заранее запланированным бюджетам и рекламным слотам, дедлайны несдвигаемые;
Пиковая нагрузка может вырастать кратно за очень короткий интервал;
Много зависимостей между системами и командами;
Есть антифрод и антибот-логика;
Много продуктовых механик и исключений;
Стоимость ошибки в проде очень высокая (нельзя чинить баг дольше, чем идёт распродажа).
Технически распродажу поддерживают несколько сервисов с разной ролью:
Core–сервисы, в том числе с высокой нагрузкой до миллионов RPM;
Клиентские сервисы, которые отдают информацию о скидках;
Сервисы управления распродажей для контент–менеджеров;
Сервисы механик (антибот/антифрод).
Главный принцип: QA подключается на этапе идеи
Самая важная часть процесса начинается не на этапе тестирования, а раньше — на этапе идеи. Когда продукт только придумал новую задачу, но её не описал. QA подключается сразу: валидирует идею, задаёт вопросы про риски, ограничения и тестопригодность. На этом этапе проще всего срезать лишнее и сфокусировать команду на критическом функционале.
Да, это дополнительная встреча с продуктом, но именно она зачастую срезает основные риски и закладывает в голову мысли, которые продукт будет в состоянии провалидировать выше и принести более детальные требования. Значит, когда команда начнет погружаться в продукт, у QA может быть возможность валидировать решение раньше, где разработчик сможет обстучать идею об QA инженера, а не о продукт, что зачастую также экономит время.
Если делать это после UX/UI–исследований или финализации требований, когда задача уже поставлена, то пространство для манёвра становится значительно меньше. Ранняя же валидация экономит итерации разработки, время продукту, а основные требования становятся прозрачнее и лучше проверяются. Забавно, что все об этом знают, но никто не использует. Мы решили подойти иначе и всё-таки использовать принцип «раннего тестирования».
Это кажется дополнительной нагрузкой на QA, но на длинной дистанции экономит время всей команды. QA-инженер — это про деньги, ведь это не только качественный код, но ещё и экономия ресурсов.
Качество заключается не только в правильных технических решениях или классных автотестах, но и в правильном подходе к разработке, тестированию и требованиям.
QA-инженер — это тот человек, который способен провалидировать не только идею, но и на чём держать фокус команде и подсветить риски, если таковы есть, экономя этим самым ресурсы и помогая тимлидам.
Верификация требований: держим контекст, а не только текст
Когда требования зафиналены, начинается верификация: нужно убедиться, что документ не расходится с предыдущими договорённостями. Здесь QA выполняет роль хранителя контекста: помнит, о чём договорились на ранних встречах, и помогает команде не терять фокус. Это снижает типичный риск: формально требования написаны, но в реализации всплывают противоречия, которые уже обсуждали, но забыли.
Никто не говорит о том, что QA не может забыть или просыпать. Но чем больше точек контроля, тем меньше вероятность. Помните, тестирование не может гарантировать отсутствие багов, зато оно может доказать и показать, что баги есть. Значит, наша задача состоит не в искоренении проблем, а в минимизации рисков и снижении критичности возможных багов.
Разработка и тестирование: снимаем боттлнек
В классической схеме QA часто становится бутылочным горлышком, потому что все задачи сходятся на них перед релизом. Мы же перестроили процесс так, чтобы часть ответственности за качество лежала на разработчике. Тут тимлиды скажут, что за качество ответственна команда, и здесь мы переносим желание в действительность.
Разработчик проходит базовые и критичные кейсы до передачи задачи в тестирование, а также проводит дизайн-ревью вместе с дизайнером до QA-этапа. Это позволяет QA фокусироваться на сложных сценариях, интеграционных рисках и дополнительных кейсах. Также заранее договариваемся о формате приёмки пакетов однотипных задач (например, приёмочные тесты вместо полного цикла).
В результате становится меньше лишних итераций, быстрее обратная связь и более предсказуемый time-to-market.
Но сразу возникает вопрос: как контролировать то, что разработчик действительно прошёл кейсы? В данном случае очень просто: на этапе приёмочного тестирования. Мы видим, что если «хэпипасс» не работает, это значит, что выше проверка не была произведена. Хоть в чек-листе и стоят все галочки.
Давайте быть честными друг к другу. QA инженер может сделать точно также и сказать, что всё работает. Проставить галочки в чек-листах и кейсах, но в итоге не пройти. В этом и заключается та самая золотая фраза «ответственна за качество вся команда». Значит, нужен процесс, который заставит команду разработки чувствовать эту ответственность. Это работа не только с конкретными людьми, это работа со всей командой, а также с тимлидами. QA-инженер не только про «клики по кнопкам», «написание автотестов», а ещё про процессы, идею и верификацию. И мы это используем в полной мере.
Почему мы сделали ставку на системные API-flow тесты
В одном из кластеров Авито родилась идея сделать инструмент для написания системных API–тестов. Мы активно подключились к его разработке, потому что нам необходим был уровень ниже e2e, но он не доходил до уровня интеграционных тестов. Если представить эту систему как Авито, то внутри неё тоже будут подсистемы, и интеграции между ними нужно тестировать.
В проекте распродаж много BDUI-экранов, внешних ручек и интеграций. Поэтому полный акцент на e2e нам не подходил: такие тесты часто проигрывают по скорости и стабильности.
Мы сделали основной упор на системный уровень, а именно на сквозные API-flow тесты, потому что они закрывают сквозные сценарии между сервисами, дают быстрый регресс и лучше соответствуют архитектуре данного продукта.
Это не отменяет пирамиду тестирования: unit, интеграционные и ручные проверки остаются. Но именно системный слой даёт нам лучшее соотношение скорость/покрытие для этого домена.
Где мы применяем ИИ
Искусственный интеллект для нас не волшебная кнопка, а инструмент для снятия рутины. Чтобы сосредоточиться на рискованных и финальных этапах, мы отдаём ИИ черновую и фоновую работу.
Что отдаём ИИ | Что не отдаём ИИ |
Генерация и черновая подготовка простых автотестов | Сложные продуктовые решения |
Ускорение рутинных операций в QA-процессе | Рискованные интеграционные сценарии |
Помощь саппорту через бота, который отвечает по документации, а QA валидирует результат | Финальные решения по критичным кейсам |
ИИ ускоряет работу тестировщика там, где цена ошибки низкая и результат легко верифицировать человеком.
Один процесс не подходит всем, поэтому мы логично разделили seller и buyer контуры. Распределение на seller и buyer части требует разных акцентов в процессе.
Seller-часть
В seller-контуре много пользовательских сценариев и ветвлений. Так, для крупных и рискованных задач мы готовим тест-планы, а для быстрых итераций главное не уйти в документацию ради документации. Объём артефактов определяется, учитывая риски и влияние на релиз.
В этой части мы дополнительно используем ИИ в рутинной автоматизации и в поддержке саппорта.
Buyer-часть
В buyer-контуре важны запусковые риски на витрине и операционные ошибки при настройке кампаний. В этой части мы добавили обязательный постмортем после каждого запуска. Важно отдавать высокий приоритет тестированию по критичности, если QA перегружен. Кроме того, необходимо проводить регулярные нагрузочные проверки, примерно раз в квартал, а при критичных изменениях — чаще.
Подсказки для бизнеса
Как отдельный слой процесса выделили прозрачность для бизнеса. Кроме стандартной работы с требованиями мы отдельно подсвечиваем, какие риски есть в текущей итерации, какие ограничения платформы или решения нужно принять, как будет вести себя продукт в случае реализации риска.
Всё это вместе сильно снижает сюрпризы на запуске и помогает принимать решения осознанно, а не в режиме пожаротушения.
Итог
В обеспечении качества нам помогла комбинация строгости и гибкости. Строгость важна в ранней валидации идеи и верификации требований. Гибкость оказалась необходима в глубине тестирования и на уровне документации.
Важно осознанно распределять ответственность между QA и разработчиками, чтобы первые не стали бутылочным горлышком и не затормозили весь процесс.
Практичное применение ИИ возможно на начальных черновых этапах и в рутине.
Для удобства тестирования и поддержки мы разделили и выстроили отдельные процессы для seller и buyer контуров.
Главный вывод в том, что QA приносит максимальную ценность не на этапе тестирования готового продукта, а когда решение ещё только формируется.
Чем раньше мы подключаемся к обсуждению, тем выше шанс выпустить нужный функционал в срок и без критичных инцидентов.
Если вы сейчас в похожей ситуации: высокая нагрузка, жёсткие дедлайны и ограниченные ресурсы QA, то начните с трёх шагов:
1. Подключайте QA к обсуждению идеи до формализации требований.
2. Перенесите часть базовой проверки на разработку и зафиксируйте правило «кто что проверяет».
3. Выберите один тестовый слой, который даст максимальный эффект именно в вашей архитектуре, и сделайте ставку на него.
Этого уже достаточно, чтобы команда перестала жить в режиме постоянного догона и начала управлять качеством системно.
Кстати, если вам интересно не только как в компании выстроены процессы разработки, но и каково в ней работать — сейчас есть возможность высказаться. Хабр совместно с ЭКОПСИ как раз сейчас проводит большое исследование IT-брендов работодателей. В прошлом году в нём поучаствовали 34 000 специалистов уровня middle и выше. Один голос — это уже данные :)