Всем привет, меня зовут Сергей. Я занимаюсь тестированием фронтенда Яндекс.Маркета. Знаю, что среди читателей Хабра много IT-специалистов, которые как-то связаны с релизным процессом и тестированием. У меня к вам вопрос. Бывало ли в вашей практике так, что фичи долго не катятся в продакшн? Знакомы ли вам раздутые релизы и их объёмные проверки?
Думаю, такое было у каждого. Я пришёл в Яндекс 3 года назад, наша команда была совсем молодой, процессы были налажены не полностью. И я столкнулся с этими проблемами лицом к лицу.
Как было
В то время наши продуктовые команды не имели конкретной зоны ответственности и занимались только тем проектом, для которого были созданы. Потом они распадались. Тестирование также не было привязано к командам разработки. Оно существовало как сервис и подключалось к проекту по мере надобности.
Задачи проверялись только руками, интеграционные тесты были нестабильны, процент покрытия автотестами был мал. Проверка длилась очень долго. Пул задач, готовых к выкладке, постоянно рос и мог достигать огромных размеров.
Что касается релизов, сборкой и выкладкой занимался один из менеджеров. Мы проводили встречи со всеми менеджерами и решали, что попадёт в ближайший релиз, а что можно отложить.
Проверкой релизов занимались бессистемно: у кого было время их проверить, тот и проверял. Упор делался на ручное регрессионное тестирование, которое могло длиться несколько дней. И это несмотря на то, что в релизе прогонялся пак автотестов и был отдел, который их писал и поддерживал.
Итак, решённая задача попадала в тестирование и могла проходить проверку до 2 дней. Затем она попадала в релиз, он проверялся ещё 4 дня. В проде задача оказывалась в лучшем случае через неделю. Это мало кому нравилось, нужно было что-то менять. И менять самое главное — процессы.
Контура
Первое, что мы сделали, это внедрили деление на контура — команды специалистов из различных областей. В отличие от прежних команд, контура не распадаются после окончания проекта. Они продолжают генерировать новые проекты и идеи в рамках своей зоны ответственности.
За тестирование в каждом контуре отвечают от 1 до 3 тестировщиков. Каждый ответственный тестировщик контура присутствует на всех этапах разработки продукта от идеи до подведения итогов.
Дежурства
Чтобы структурировать работу по релизам, мы ввели в нашей команде тестирования две роли: релиз-мастер и релиз-тестировщик. В качестве релиз-мастера у нас по очереди дежурят 4 тестировщика, в дежурстве по релизу участвуют все. По каждой из этих ролей мы организовали график дежурств.
Задачи, возникающие во время дежурства, имеют приоритет над тестированием продуктовых фич внутри контуров. Чтобы тестировщикам не приходилось долго дежурить без перерыва, дежурство по релизам устроено так: одна смена дежурит с понедельника до среды, вторая — со среды до конца пятницы. В каждой смене — 4 человека, по 2 человека на платформу.
Документация
А что по документации? У нас её не так уж и много, но она есть. К примеру, при выкатке фич мы вместе с разработчиками и менеджером определяем оптимальное количество автотестов. Если мы не можем что-то заавтоматизировать или если фича требует немедленной выкладки без автотестов, мы пишем кейс в тест-комплект всех кейсов проверки Маркета и при необходимости включаем его в релизный тест-комплект регрессионного тестирования.
Если мы проверяем багфиксы и видим, что на баг не было написано автотеста, мы также ставим задачу на его разработку, и правка катится сразу с написанным на неё тестом.
При выкладке каждого эксперимента у нас есть чек-лист, так как мы не знаем заранее, окажется ли эксперимент успешным.
Чек-лист представляет собой набор позитивных проверок фичи эксперимента. Релизный тестировщик пользуется им при каждом релизе, пока эксперимент работает. Этот чек-лист также может быть заготовкой для будущих задач на автоматизацию, если эксперимент будет успешным и мы выкатим его на 100% пользователей.
При проверке релизов мы используем различные тест-комплекты в зависимости от сложности и наполненности релиза. У нас есть и небольшие наборы проверок, и наборы с максимальным количеством тест-кейсов. Какой тестовый набор использовать, решает релизный тестировщик.
В некоторых контурах мы также используем чек-лист позитивных проверок для разработчиков. С его помощью разработчик может сам проверить задачу и предусмотреть узкие места при разработке фичи. Если же на проекте сменился тестировщик, это поможет новому специалисту быстро влиться в проект. Чек-листы пишутся ещё до начала разработки, сразу после планирования задачи.
Вот и всё, что касается доков.
Как мы проверяем задачи
Мы используем различные техники тест-дизайна: классы эквивалентности, граничные значения, pairwise testing, сценарии пользователя. Очень важна и экспертиза тестировщика. Маркет — большая машина, и нужно знать, как работают все её части, чтобы что-то чинить или улучшать. К примеру, у нас есть 4 вида товарных карточек и 6 видов товарных выдач. Не зная об этом, просто невозможно качественно протестировать задачу по изменению этих страниц.
Важную роль в проверке задач играют автотесты. Мы прогоняем функциональные автотесты на каждую реализуемую задачу, анализируем падения и репортим баги.
В особых случаях, когда задача затрагивает много компонентов Маркета, мы также запускаем скринтесты — они помогают нам отловить баги.
Когда проверка задачи закончена, мы расписываемся за её качество: оставляем комментарий, что всё хорошо и что задачу можно брать в релиз. В комментарии мы указываем, сколько было написано тестов, или же говорим, что тесты не нужны, и переводим задачу в статус «ожидает релиза».
Далее задачу подхватывает релиз-мастер, и она отправляется в релиз вместе с другими проверенными задачами. Мы стараемся набивать релизы задачами, чтобы успеть их проверить за 8 часов руками 4 тестировщиков: 2 — на тач-версию Маркета и 2 — на десктоп-версию. Наша цель — выкатить не меньше 5 релизов. То есть скорость доставки задачи в прод по сравнению с тем, что было, возросла в 5 раз.
Как мы проверяем релизы
Проверку релиза мы начинаем с проверки автотестов и скринтестов. Посмотрев отчёты, мы можем сразу отловить до 90% проблем. Мы анализируем падения тестов: если они связаны с багом или сломаны тикетом в релизе, мы ищем задачу, в которой это падение воспроизводится, и просим починить. Если это не делается, задача не попадает в релиз.
Тесты также могут умирать сами собой. В этом случае мы выключаем тест из прогона автотестов и заводим задачу на его починку и создание мока при необходимости.
В зависимости от задач в релизе мы можем использовать полный релизный тест-комплект, а можем и вовсе отказаться от ручного регресса. Решение принимают релизные тестировщики.
Если релиз имеет несколько небольших правок, проверка задач проходит локально, а ручной регресс заменяется проверкой отчётов по автотестам.
Независимо от полноты релиза и задач, команда релизных тестировщиков проверяет эксперименты, которые в данный момент показываются разному проценту пользователей в продакшне. Используется чеклист, написанный тестировщиком эксперимента.
Когда все проверки завершены, релизный тестировщик расписывается за это. Он оставляет комментарий, где перечисляет все активности по релизу и, если нужно, пишет задачи на починку сломанных тестов.
Релиз-мастер анализирует отчёты стрельб (нагрузочного тестирования) и, если видит рост ошибок, перезапускает их. Если это не помогает, он ищет виновника или обращается за помощью к дежурному разработчику.
Если с результатами стрельб всё хорошо, релиз-мастер открывает графики Маркета и начинает выкатывать релиз в продакшн. За графиками нужно следить, чтобы не пропустить рост ошибок.
Если в росте ошибок виноват релиз, релиз-мастер откатывает его и разбирается в причинах. Если графики в норме, он завершает релиз и начинает собирать новый из готовых задач.
Стремимся к лучшему
Несмотря на то, что всё работает хорошо, всегда нужно стремиться к лучшему. Мы стоим на пороге светлого будущего continuous delivery, где задачи будут проверяться и выкатываться в продакшн параллельно друг другу, без промежуточного этапа в виде релиза. Это позволит не отвлекаться на дежурства по релизам и значительно ускорит доставку функционала пользователям.
Мы решили переходить к CD поэтапно. Первым шагом стало внедрение монорепозитория, который объединяет выкатку функционала на обе платформы — тач и десктоп — в один релиз. В таком подходе есть плюсы и для разработки, и для тестирования. Мы тратим гораздо меньше времени на тестирование компонента. Задачи теперь находятся в одном месте, что облегчает навигацию. Менеджеру проще ориентироваться, так как он знает точные сроки выкатки релизной задачи в прод, а между выкаткой платформ нет люфта.
Следующим шагом к CD будет внедрение «зелёного рана». На каждый тикет, проверяемый тестировщиком, будет запускаться 2 вида тестов для обеих платформ: функциональные тесты и скринтесты. Все тесты должны будут иметь моки. Если тесты для одной из платформ будут падать, задача не будет считаться проверенной. При падениях тестов нужно будет разбираться, почему так произошло. Только при отсутствии падающих тестов и успешном прохождении всех проверок задача будет отправляться в прод.
Спасибо за внимание. Надеюсь, вам был полезен наш опыт, жду вас в комментариях.
Автор: Сергей Лебедев
