Как и зачем мы написали 5000 интеграционных тестов за пару часов31.07.2024 09:15

Привет! Меня зовут Ангелина Архипова, я техлид команды IMP Support в Авито. В этой статье я рассказываю о ежедневной рутине моей команды и о том, как разгрузить QA-инженера от этой рутины. А ещё из текста вы узнаете про наш главный эксперимент по написанию 5000 тестов: как мы к этому пришли, что это нам дало и какие у нас планы на будущее. 

Кто входит в команду IMP Support и какие задачи она выполняет

В Авито нам очень важно развивать категории объявлений, которые пользователь выбирает при публикации на сайте. К ним относятся, например, «Недвижимость», «Транспорт», «Работа», «Услуги» или «Товары». 

Главная цель развития категорий — позволить продавцу составить максимально точное объявление, а покупателю — быстро найти нужный товар или услугу. Для этого мы, например, вывели фильтр по цвету и габаритам в категорию «Диваны», добавили новые категории «Мебель для детей» и «Мебель для новорожденных». 

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

Помимо этого, в нашей команде есть QA-инженеры и их основные задачи в нашей команде:

• помощь контент-менеджеру в выполнении задач;

• тестирование задач за контент-менеджером;

• написание и поддержка автотестов;

• релиз и просмотр метрик после релиза.

Релизный процесс выглядит примерно так:

Контент-менеджер выполняет задачу по инструкции, обычно это занимает от одного до трёх дней, в зависимости от сложности. Затем идёт тестирование, оно также длится от одного до трёх дней. А затем уже — релиз. 

Посмотрим, как это выглядит на реальной задаче. Например, нам нужно добавить новые характеристики в категорию «Диваны»:  

• материал — 6 значений;

• форма — 5 значений;

• цвет — 19 значений;

• размеры (ширина, высота, глубина). 

Если использовать метод попарного тестирования (Pairwise), то получается 235 комбинаций для проверок. Теперь умножаем это всё на четыре платформы:  

• web;

• мобильный web;

• iOS;

• Android.

Учитываются также три основных сценария:  

• публикация объявления с новыми характеристиками;

• редактирование объявления;

• просмотр карточки товара.

235 комбинаций х 4 платформы х 3 сценария = 2820 тест-кейсов

Помимо Pairwise testing мы используем Impact analysis на основе наших знаний о админке и сокращаем количество тест-кейсов до 100. 

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

• 50+ контент менеджеров;

• 25+ типовых видов задач;

• 300+ задач в месяц;

• 3 QA-инженера;

• 400+ е2е-тестов.

Отсюда видно, что на QA-инженера приходится примерно 100 задач в месяц и автотесты на поддержку. В связи с этим мы выделили следующие проблемы:

• поток однотипных задач на тестирование;

• из-за недостатка ресурсов создаётся очередь задач;  

• задачи могут ждать тестирования от недели.

Как разгрузить QA-инженера

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

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

В предложении с генерацией е2е-тестов минусов больше, чем плюсов. У нас большая компания и сразу несколько команд могут отвечать за одно объявление. Если мы просто будем делать больше тестов — все запутаются.

Обучение контент-менеджеров выглядит как неплохое, но не идеальное предложение. Поскольку контент-менеджеры — не технические специалисты, они могут делать только простые задачи. Также нам пришлось адаптировать для них инструкции.

Генерация автотестов действительно выглядит той самой «волшебной кнопкой», но нам было не очень понятно, как она должна работать. Этот вариант мы решили исследовать глубже. 

Как мы поняли, что нужно проверять автотестами

Мы начали изучать, какие изменения мы вносим, на что они влияют и что происходит «под капотом». Когда мы производим настройки в админке, она отправляет их в валидатор, а полученный результат выводится на какую-то страницу в UI. Допустим, мы хотим добавить поле «Форма» с типом «Выпадающий список». Данные отправляется в валидатор, который проверяет корректность настроек и формирует json, если все хорошо. Затем json попадает к клиенту, который рисует то, что мы хотели. 

Кроме самого механизма мы исследовали еще и зону нашей ответственности. Мы не занимаемся разработкой новых типов виджетов, а используем уже существующие. Тестированием отрисовки конкретного компонента на основе ответа валидатора также занимаются другие команды.

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

Как работает генерация 

Например, у нас запускается генерация для категории «Для дома и дачи» для фичи «Публикация объявления». Мы получаем из админки список параметров с master, для которых нужно сгенерировать тест. Затем генерируем тестовые сценарии по шаблону, который выработали, сохраняем сценарий. 

Так у нас появился регрессионный набор интеграционных тестов, который стал впоследствии quality gate для задач контент-менеджеров. Когда у нас появляется задача, сгенерированный регресс мы запускаем на ветку контент-менеджера и анализируем отчёт. Если тесты упали ожидаемо — генерацию запускают заново. Благодаря этому мы не тратим время на поддержку.

Плюсы и минусы генератора

Главный плюс — генератор работает достаточно быстро и генерирует 7–8 тестов в секунду. Я думаю, что даже самому лучшему QA-инженеру не удалось бы так быстро писать автотесты. Прогон 5000 тестов за счет интеграционных проверок и небольшого взаимодействия сервисов занимает меньше 3 минут.

Ну и самое главное — не нужно поддерживать тесты. Есть «волшебная кнопка», которая поддержит всё за тебя.

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

Что у нас получилось в итоге

Релизный процесс стал выглядеть вот так:

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

Итоги в цифрах:

• почти в 16 раз сократились затраты на ручное тестирование;

• ≈7 минут вместо ≈40 минут длится авторегрессия. Это стало возможным благодаря сокращению е2е-проверок и переносу тестов на интеграционный уровень;

• 1–2 дня на ожидание релиза. Раньше очередь из задач растягивалась на 7 дней и больше.

Что мы планируем в будущем

Обучение генератора. Мы хотим, чтобы он генерировал то, что нужно, а не всё подряд. Возможно, получится встроить в него какие-то простые техники тест-дизайна: классы эквивалентности или граничные значения.

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

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

Какие выводы мы сделали

Не бойтесь безумных идей. Пробуйте детально описать их и всё получится. Ищите единомышленников, у которых больше экспертизы. Например, этот проект не делался в одиночку — мне помогали бэкэнд-разработчики из другой команды. Для первого рабочего прототипа понадобилось всего две недели разработки одного инженера, которые сэкономили нам кучу времени.

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

Автоматизируйте. Если у вас есть процесс, который повторяется 100 раз подряд, возможно вам не нужно делать все вручную. В проекте необязательно должна быть точно такая же админка как у нас, у вас может быть своя CMS или конфиги в сервисе. Генератор в этих случаях тоже может пригодиться.

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

На этом все! Спасибо за уделенное статье время. Задавайте в комментариях вопросы и до встречи!

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

© Habrahabr.ru