Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.
Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов; далее для простоты я буду часто объединять их в одно понятие Афиша), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.
Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).
Прежде всего, можно было добавить тестирование асессорами-тестировщиками — в Яндексе на разных проектах используются удаленные тестировщики. У этого подхода есть свои плюсы, но есть и минусы, которые в тот момент для нас были блокирующими:
асессоры не в контексте проекта;
нужно время на расписывание более подробных тест-кейсов для асессоров;
нужно время на актуализацию всех тест-кейсов;
нужно время на постановку заданий и обработку результатов асессоров;
их необходимо бронировать заранее, нет возможности отдавать задания в моменте.
Подключаем саппорт
Поэтому мы решили попробовать организовать тестирование саппортами: это ребята из нашей поддержки, которые хотят развиваться в тестировании, и уже в какой-то степени знакомы с проектом.
Сказано — сделано, и в марте запустили тестирование ребятами из саппорта в соседнем проекте, Билетной системе. Идея взлетела, саппорты с удовольствием подключились к тестированию, успешно находили баги, и команда была довольна этим проектом.
Следующим этапом была организация тестирования саппортами в Афише (и с этого момента проектом начала заниматься я).
К середине апреля я подготовила примеры задач, которые можно было отдавать на тестирование саппортам (на первое время — фронтенд: тестирование новых фичей, тестирование багфиксов, прохождение тест-кейсов и тест-ранов).
15 апреля официально стартанули с первым человеком.
И вот что мы сделали — чтобы не тормозить тестирование задач, которые ждали в релизах, начали с обучения на уже выпущенных в прод задачах:
Выдали по паре задач каждого типа (при необходимости я дописывала, на что надо обратить внимание при проверке задачи).
Тестировщику из саппорта требовалось в каждой задаче предоставить отчет: указать окружения и браузеры, на которых проводились проверки (для закрытых задач в качестве окружений брался тестинг), описать сценарии выполненных проверок с результатом прохождения, задать вопросы, если появятся по ходу тестирования.
После чего по всем задачам я проверяла отчеты о тестировании, где были замечания — указывала и просила дотестировать и дополнить отчет.
Тут же обнаружили главное отличие задач Афиши от Билетной системы: в Билетной системе тестируется тот же интерфейс, с которым работают клиенты и который уже знаком саппортам; в Афише — саппорты знают совершенно другую часть системы. Они знают всё про заказы, возвраты, отмены и переносы событий; а мы тестируем виджет (в котором пользователи видят схемы залов, выбирают места, расписание фильмов, etc), с которым в саппорте сталкиваются очень мало, и непосредственно саму Афишу, с которой они слабо знакомы с этой стороны.
Пришлось стремительно придумывать и проводить вводную лекцию про сервис: что такое Афиша как витрина событий, что такое виджет с точки зрения разработки, как они взаимодействуют, где какие части находятся, что мы тестируем.
После обучения запустили тестирование реальных задач, для начала — в полностью ручном режиме. Схема была такой:
Я просматривала все задачи, приходящие на тестирование. У тех, которые можно было отдать тестировщику из саппорта (по уровню и сложности) — ставила специальный тег для отметки, что тестирует саппорт, проставляла QA-инженера и дописывала свои комментарии к блоку «Как тестировать», если что-то надо было пояснить подробнее.
Тестировщик саппорта забирал задачу в тестирование, проверял и писал отчет о тестировании. Затем переводил в статус «Требуется ревью тестирования».
Задача возвращалась ко мне, на ручную проверку его отчета.
Это, конечно, занимало много времени и сил, но мы понимали, что это временный этап только на период обучения.
Постепенно ручной работы по проверке становилось меньше. Мы пару раз поправили шаблон отчета; количество стало переходить в качество, у меня было меньше замечаний; разработчики старались сами указывать в описании «Как тестировать» необходимые подробности. Но, конечно, полностью от ручной работы избавиться ещё не получалось.
Немного масштабируемся
Мы решили добавить еще ребят из саппорта, потому что задачи для них у нас были. Заодно забрали нашего «первопроходца», Андрея, на загрузку 40 часов в неделю.
Попутно вместе с Андреем настраивали процессы:
писали доку с онбордингом новичка;
памятку по выдаче всех нужных доступов (ввиду безопасности процесс их выдачи аут-стафф сотрудникам до всех тестовых окружений и сервисов — это тот еще квест!);
разбивали наши задачи на типы — чтобы лучше строить и обучение, и процесс передачи (для понимания, кто какие типы задач уже умеет тестировать и кому их можно отдавать);
собирали базу «учебных» задач с готовыми «ответами» — чтобы проверять у следующих ребят учебные отчеты было легче.
В конце мая добавили еще одного человека из саппортов, а в июне — еще трёх (всех на парт-тайм, количество часов работы на тестировании мы периодически калибровали в зависимости от наших запросов).
Обучение постарались выстроить так, чтобы по возможности разгрузить меня: я проводила обучающие вебинары, контролировала процесс и отвечала на сложные вопросы (особенно когда отдавали ребятам новые типы задач в работу), но большая часть обучения была в самой группе тестировщиков из саппорта: онбординг новичка, учебные задачи, правки по ним, после прохождения первого обучения — распределение задач на тестирование между ребятами.
В июне мы стали подключать ребят из саппорта к тестированию релизов фронтенда виджета. При релизе мы вручную проходили немаленький регресс, и 2 раза в неделю он на полдня-день «выключал» штатных тестировщиков из остальной работы. Мы, конечно, занимались автоматизацией регресса, но тогда он все еще занимал очень много времени ручной работы.
В июле регресс на 99% был отдан саппортам (1% оставался у меня из-за проблем с доступами).
По процессам: после того, как мы масштабировались с одного человека в группе до пяти, пришлось еще немного поработать с процессами.
Так у саппорт-тестировщиков появилась своя доска в трекере задач (нашем аналоге Jira): поскольку в тестирование им отдавали задачи из двух команд, бегать по 2 доскам в трекере было не очень удобно. Доска собиралась по тегу Support_test, с помощью которого задачи отдавали на тестирование саппорт-тестировщикам.
Вдобавок мы стали пользоваться отдельной очередью для «своих» задач вроде написания и обновления тест-кейсов (если это делалось не в рамках тестирования задач разработки), написания какой-то еще документации и т.д, и видеть их на своей доске было удобно. А ещё своя доска позволяла гораздо удобнее работать с фильтрами на ней: сделать фильтры по всем ребятам из группы, проверять, у каких задач назначен тестировщик, а какие надо кому-то отдать; и со столбцами — например, выделить «требуется ревью тестирования» в отдельный столбец, чтобы задачи в этом статусе не терялись.
И свой стендап: 2 раза в неделю по 15 минут. Чтобы я (и тестировщик из второй команды) были в курсе, что происходит, как идет процесс тестирования задач (без бегания по каждому человеку отдельно); чтобы проверять не назначенные ни на кого задачи; и чтобы была возможность рассказывать какие-то новости, касающиеся всей группы, не собирая людей отдельно.
Про использование статуса «требуется ревью тестирования» расскажу дополнительно. Сначала мы использовали его, чтобы отдавать задачи после тестирования на проверку мне. Но, конечно, проверять за 5 тестировщиками (пусть даже работающими у нас только часть времени) все задачи — погребло бы меня просто под этими проверками.
Поэтому статус использовался следующим образом:
Первое время у новичка мы перепроверяем все задачи (либо самыми опытными из тестировщиков саппорта, либо мной).
После того как человек освоится — убираем проверку всех-всех задач, оставляем статус только для сложных/новых по типу. При этом на ревью не обязательно отдавать лично мне — по большей части я просила отдавать на ревью друг другу, система наподобие код-ревью у разработчиков, и чаще всего этого было достаточно: даже если один человек что-то пропустил при тестировании, второй посмотрит свежим взглядом и обратит на это внимание.
Некоторые задачи — самые сложные, или самый новый тип задач, который пока вызывает вопросы и опасения «все ли я правильно понял и проверил» — отдаются на ревью мне.
К августу у нас были хорошо выстроены процессы, ребята уверенно регрессили виджет, тестировали большую часть задач по фронтенду. Но процесс передачи задач был еще «ручным»: чтобы отдать задачу на тестирование саппортам, надо было проставить тег, и даже то, что я настроила для этого автоматизацию и это можно было сделать в 2 клика — не отменяло того, что процесс был ручным. И, хотя это было сделано, чтобы задачи в тестирование саппортам мог отдавать кто угодно — тестировщик, разработчик, менеджер, — занималась этим по-прежнему только я.
А в августе я собиралась в отпуск на 2 недели, и надо было сделать так, чтобы за это время процесс не встал и не посыпался :)
Волевым решением я настроила автоматическую передачу всех задач фронтенда Афиши и виджета на тестирование саппортам. То есть как только задача, относящаяся к нашим командам, переходила в статус «Можно тестировать» — ей ставился тег, она улетала на доску к саппортам, а в комментарии призывался разработчик с просьбой проверить, достаточно ли описано, как тестировать задачу, и не хочет ли он чего-нибудь добавить (поскольку раньше это делала и дописывала я).
После отпуска я оставила этот флоу, только призывы разработчиков убрала.
И регресс релизов виджета был передан в зону ответственности саппорту: там, где раньше я переводила релизную таску в статус «Тестируется», заводила раны и присылала их ребятам (и так далее, вплоть до перевода релиза в «Протестировано» и отчета о тестировании) — вся эта работа была передана саппортам, чтобы во время моего отпуска все могло работать без меня.
После отпуска регресс также остался у саппортов. Потом мы ввели еще и дежурства по релизам у саппортов, чтобы это не было вечной задачей одного и того же человека.
Помимо этого, в августе мы потихоньку начали отдавать на тестирование саппорт-тестировщикам задачи по бэкенду.
В том числе — огромный проект про изменениям в логировании и аналитике больших массивов данных, связанных с ключевыми показателями сервиса. Этот проект, для понимания и тестирования которого нужно было полностью разобраться во всех видах наших транзакций, продуктов, как они выглядят «под капотом», множестве нюансов взаимодействия с партнерами — прямо скажем, не самая простая задача, — полностью был в тестировании (написание тест-кейсов и тестировании задач) у девушки из нашей группы саппорт-тестировщиков.
В сентябре добавили еще 1 человека в группу (и обучение происходило уже полностью в группе саппорт-тестировщиков, без отвлечения штатных сотрудников).
Что получилось за полгода
Итого в группе саппорт-тестировщиков Афиши и виджета на середину октября было 6 человек (в Билетной системе — 3).
С апреля по октябрь саппорт-тестировщики (и Афиши с виджетом, и Билетной системы) выполнили задач по тестированию на 2600 часов (в среднем 1 штатный сотрудник — это 170 часов в месяц, за полгода — 1020, т.е. в часах это 2,6 штатных сотрудников).
По проектам:
Афиша и виджет: 1 800 часов.
Билетная система: 800 часов.
Благодаря тестировщикам из саппорта мы смогли уменьшить нагрузку на штатных сотрудников, и они смогли переключиться на сложные задачи и цели, пережить уход и смену четырех сотрудников (это в обоих проектах) без влияния на скорость и качество проектов.
Также благодаря им мы несколько раз смогли выпустить горящие релизы с важными проектами (например, концерты Little big, Maneskin) в очень сжатые сроки.
Наши саппорт-тестировщики научились тестировать все типы задач на фронтенде (осенью штатные тестировщики в командах Афиши и виджета забирали себе в тестирование либо очень срочные задачи к релизу, либо какие-то большие проекты, которые вели полностью сами — и то многие проекты мы уже могли передавать саппорт-тестировщикам). Научились писать тест-кейсы, проводить регрессионное и приемочное тестирование. Тестировали часть задач бэкенда и постепенно погружались в них все больше. Сильно выросли по уровню, в тестирование мы отдавали не только легкие, но средние по сложности задачи.
Также мы поквартально отслеживали и оценивали рост ребят. Осенью 2021 года я решила ротироваться в другой проект, на мое место в Афише была нужна замена – и мы уже рассматривали сильных ребят из этой группы (и сделали оффер одному из них). Команда саппорт-тестирования продолжила работу в Афише, и в дальнейшем лучшие саппорт-тестировщики также получали возможность перейти в штат на открытые вакансии.
А теперь — слайды
Краткое содержание серий:
The end! (Еще нет)
Какие выводы хочется сделать?
Если у вас на проекте не хватает «рабочих рук», тестировщики загружены рутиной и им не хватает времени на более глобальные задачи, развитие себя и проекта, и при этом есть пользовательская поддержка — вы можете пойти этим путем и создать команду саппортов тестирования.
Для них это будет пространство для роста внутри вашей компании (а я считаю, что это всегда хорошо — когда вы можете поощрять мотивированных сотрудников и давать им пространство для роста и развития, особенно горизонтального), для вас — мотивированные, готовые учиться и расти джуны (уже знакомые с вашим продуктом).
Для тестировщиков в команде — возможность разгрузить с себя простые задачи и заниматься более сложными, расти из QC в QA (что также полезно для продукта с точки зрения обеспечения качества), а для сотрудников с потенциалом роста в лиды — возможность попробовать себя в роли лида.
