company_banner

Как устроено тестирование фронтенда в Яндекс.Маркете и почему мы отказываемся от еженедельных релизов



    Всем привет, меня зовут Сергей. Я занимаюсь тестированием фронтенда Яндекс.Маркета. Знаю, что среди читателей Хабра много 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 вида тестов для обеих платформ: функциональные тесты и скринтесты. Все тесты должны будут иметь моки. Если тесты для одной из платформ будут падать, задача не будет считаться проверенной. При падениях тестов нужно будет разбираться, почему так произошло. Только при отсутствии падающих тестов и успешном прохождении всех проверок задача будет отправляться в прод.

    Спасибо за внимание. Надеюсь, вам был полезен наш опыт, жду вас в комментариях.
    Яндекс
    271,65
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 22

      +7
      Контура

      Может, все-таки "Контуры"?

        –1
        Бесполезно. Хоть норма и договорЫ и контурЫ, но процесс изменения языка не остановить. Рано или поздно очередные Даль с Розенталем пометят форму с Ы как архаичную
          +3
          И не роспись, а подпись. Роспись — это хохлома.
          +1
          Проверку релиза мы начинаем с проверки автотестов и скринтестов.

          То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?

          Кстати, а какой процент стабильности тестов? Сколько упадут случайно на прогон?
          Сколько времени занимает полный ручной регресс? Как часто он используется?

          Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?

          Наша цель выкатить не менее 5 релизов

          Правильно ли я понял, что 5 в неделю?
            0
            Да не менее 5 релизов в неделю.
            Не все тесты замоканы, по возможности отлавливаем и мокаем, из за разных обстоятельств попадают в релиз(нестабильность бэков/учения итд). Падения тестов разбирает, да, тестировщик и далее уже отдаёт програмисту конкретные задачи на починку.
            Раз в неделю примерно гоняем полный регресс, занимает около 4 часов.
            Спасибо за ваш комментарий.
              0
              А какой процент стабильных тестов?

              И ещё. Если тестировщик дежурит и занимается релизами — на сколько он выпадает из тестирования текущих задач? Это не проблема?
              0
              вероятно раз в день если речь идет про 8 часов на релиз
                0
                > То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?
                Нельзя сделать продукт без багов. Если стало в среднем лучше — это хороший релиз.
                  0
                  То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?

                  Как уже верно сказали — все отловить и починить невозможно в разумные сроки. Вполне нормальный критерий для релиза — когда по сравнению с предыдущей неделей количество новых багов не растет и все новый не выше медиума по severity/priority.

                  Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?

                  Если автотесты сделаны хорошо — то это очень логично — ручной тестировщик отделяет зафэйленые тесты от упавших, зафэйленые уже разбирает подробно сам, а упавшие — разбирает и чинит автотестер или разработчик.
                    0
                    Постойте, я же не говорю про отсутствие багов. Я говорю про красные тесты. Разве перед выпуском фичи нельзя исправить ошибки, уже найденные тестами и поднять тесты? Или с таким темпом это проблематично?
                      0
                      С пятью релизами в неделю это выглядит даже не проблематично, а за гранью возможного, но вариант — исправить все дефекты/ошибки найденные тестами — может быть просто не доступен по ресурсам. У нас же ограниченное число разработчиков. Пока мы будем ждать пока разработчики пофиксят вообще все что найдено — может пройти достаточно много времени во время которого пользователям придется мириться с более критичными дефектами, чем те, которые осталось пофиксить.
                        0
                        Конечно, если падения вызваны багом их правят до релиза. Но иногда падения вызваны нестабильностью бэков/учениями итд. и в таком случае, просмотрев глазами падения, задерживать релиз нецелесообразно
                          0
                          Кажется, я понял, где у нас возникло недопонимание. Есть этапы: тест задачи и тест релиза. Мой вопрос был — почему красными тестами не занимаются на этапе теста задачи?

                          В том, что нестабильные тесты не должны держать релиз, я с вами соглашусь. Кстати, вы так и не сказали, сколько их.
                            0
                            Ими занимаются если они падают по причине изменений в задаче, обычно они зелёные, но бывают что падают по не зависящим от тестируемого функционала причинам и в таком случае мы их оставляем.
                              0
                              По не стабильным около 30% не замоканых
                      +1
                      Что такое «стрельба на разладку»? И расскажите, пожалуйста, какие ошибки трекаете во время релиза.
                        0
                        Они нужны чтобы определить пределы производительности, подробнее можно посмотреть в докладе Алексея Лавренюка о нагрузочном тестировании.
                        0
                        А бывает так, что какая либо задача, тесты на которую не стабильны, являлась связной с несколькими другими задачами и релиз приходилось откладывать? Или вы избегаете релизить такой пирог и в один релиз уходит базовая задача, которая подготавливает плацдарм (и не обязательно визуальный) для следующих N задач, а зависимые уходят в другой релиз?
                          +1
                          Откладывать нет, не приходилось, если падает несколько тестов мы их можем руками перепрогнать и понять связано с задачей или нет, а вот если массово тесты падают, то тут другое дело, и это может затянуть релиз. Обычно получается, как раз, что идет сначала базовая, а потом все остальные, но это скорее не умышленно происходит.
                            0
                            Спасибо за ответ )
                          0

                          Интересно, что нет практики TDD — это осознанное решение или просто ещё до этого этапа процесс разработки не дошёл? И если осознанное решение, то что по каким причинам?

                            0
                            Да, это осознанный шаг из за экспериментов.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое