Книга: Как тестируют в Google

Интервью с Анкитом Мехтой, тест-менеджером Gmail

Интервью с Анкитом Мехтой, тест-менеджером Gmail

Анкит Мехта вырос в менеджера из инженера по тестированию, который в основном выполнял работу разработчика в тестировании. Начало своей карьеры в Google он провел, закопавшись в коде и автоматизации. Свое первое серьезное повышение до менеджера он получил в проекте Gmail.

Gmail не для слабаков: в этом продукте очень много динамических частей, за которыми нужно следить. С одной стороны, Gmail интегрируется с другими технологиями Google, включая Docs, Calendar и т.д., с другой — Gmail должен взаимодействовать с форматами других почтовых сервисов. Здесь требуется огромная работа с базами данных, так как Gmail работает в облаке, а его пользовательский интерфейс доступен через любой браузер. Не верите, что это сложно? Тогда вспомните, что Gmail имеет сотни миллионов пользователей, которые ожидают, что почта будет работать быстро, надежно, безопасно, а заодно справится с потоком спама. Добавляя новые фичи, надо сохранять рабочее состояние старых, что здорово затрудняет тестирование. Если в Gmail появляется баг, то весь мир узнает об этом мгновенно. Помидоры летят во многих в Google, но в первую очередь в находящегося на передовой менеджера.

Мы встретились с Анкитом, чтобы узнать, как было организовано тестирование Gmail.

— Расскажи, как ты подходишь к новому проекту по тестированию. Что ты делаешь в первую очередь, какие вопросы задаешь?

Анкит: Первые несколько недель в проекте я только слушаю. Очень важно сориентироваться, узнать архитектуру продукта и динамику команды. Я бы не стал слушать врача, который в первые пять минут моего визита выписывает мне антибиотики. Так же и команда не станет работать со мной, если я с ходу начну «ставить диагноз». Чтобы получить право выписывать лекарства, нужно многому научиться.

— Мы работали с тобой, и у нас сложилось впечатление, что ты не из молчунов. Наверное, когда ты начнешь говорить, тебя уже не остановить!

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

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

— Какие же ответы на вопрос «почему» для тебя приемлемы?

Анкит: Всего два ответа. Во-первых, потому что это улучшает качество продукта. Во-вторых, потому что это повышает производительность инженеров, работающих на проекте. Все остальные ответы менее значимы для продукта.

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

Анкит: Очень важна динамика команды. Я считаю, что качество продукта связано с качеством команды тестирования. Сначала подберите нужных людей, с правильными навыками и настроем, а потом направьте их делать правильные вещи. Вы — руководитель команды, и именно ваше влияние создает здоровую рабочую культуру. Работая с Gmail, я формировал команду шесть месяцев, потому что мне хотелось создать сплоченную группу людей, где все понимают и уважают роли друг друга. Если вам удалось создать крепкую команду, она выдержит даже присутствие пары специалистов, которые не очень в нее вписываются.

Хорошие отношения между группами разработки и тестирования — важная часть положительной динамики всей команды. Когда я пришел в проект, ситуация была плачевной. Команды работали изолированно друг от друга, а полезные предложения тестировщиков терялись в команде разработки. Атмосфера была нездоровой.

— Судя по всему, тебе удалось исправить ситуацию, давай поговорим об этом. Расскажи, что ты сделал для того, чтобы рабочая среда стала комфортной?

Анкит: Когда я присоединился к проекту, команда тестирования была сосредоточена на тестах WebDriver, которые выполнялись для каждой сборки. Они проводили тесты, следили, как состояние меняется с зеленого (тесты проходят) на красный (тесты не проходят), и прикладывали титанические усилия к исправлению тестов, чтобы они не показывали ложные срабатывания. Команда разработки не сомневалась в том, что вся работа построена правильно, потому что тесты действительно обнаруживали важные проблемы, а значит, были оправданны. Однако иногда изменения затрагивали большие объемы кода, и оперативно исправить тесты не получалось. Чтобы достичь результатов, приходилось выполнять слишком большую работу. Весь процесс был ненадежным и недостаточно гибким для такого подвижного и сложного сервиса, как Gmail.

Так как я был новичком в проекте, мой взгляд не был замылен. Мне казалось, что самой серьезной проблемой Gmail были задержки. Серьезно, ведь для пользователя главный атрибут Gmail — скорость. Я решил, что если мы справимся с этой проблемой, мы сможем заслужить уважение разработчиков и они будут воспринимать нас как равных.

Задача была тяжелой. В каждой сборке мы сравнивали ее скорость со скоростью предыдущей версии, чтобы поймать случай, когда новая сборка работает медленнее. После мы перебирали все изменения кода в новой версии, чтобы найти и уничтожить причину задержки. Это был долгий и сложный путь с большим количеством проб и ошибок.

Я вместе с одним разработчиком в тестировании искал способ специально замедлить работу Gmail. Мы хотели лучше контролировать взаимодействие между клиентской частью и дата-центром, чтобы найти регрессии, влияющие на производительность. Собрав несколько старых компьютеров и лишив их всех ускоряющих компонентов, мы получили целую комнату системных блоков с 512 мегабайтами памяти, 40-гигабайтными дисками и медленными процессорами. Работа Gmail стала медленной, и мы смогли отличить сигнал от шума. Мы запустили долгосрочные тесты, которые создавали дополнительную нагрузку системе.

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

Нам удалось заработать уважение для команды тестирования, и когда мы взялись за следующие высокоприоритетные задачи (исправление сквозных тестов и налаживание инфраструктуры тестирования фактической нагрузки), разработчики сами вызывались помочь нам. Вся команда убедилась в пользе эффективных тестов, выпуски Gmail из ежеквартальных стали еженедельными, а потом и ежедневными.

— Отличный урок: возьмите трудную задачу, решите ее, заслужите уважение. А что ты делал после этого?

Анкит: Трудную задачку можно найти всегда! Хотя общая идея остается в том, чтобы сосредоточиться на самом важном. Мы обозначили самую серьезную проблему Gmail, собрались вместе и решили ее. Затем мы пошли дальше по списку, и все решалось легко, так как у нас была сплоченная команда. Все-таки я больше верю в пользу сфокусированной работы. Когда я вижу, как команда пытается прыгнуть выше своей головы (скажем, работает над пятью задачами одновременно, хотя каждую выполняет только процентов на восемьдесят), я заставляю их сделать шаг назад и расставить приоритеты. Пусть количество задач будет меньше, но зато они будут решены на все сто. Плюс для команды: появляется чувство удовлетворения от выполненной работы, незавершенные задачи перестают нависать у них над головой. Плюсы для меня: качество продукта улучшается и я счастлив.

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

Анкит: Обилие подчиненных и время, которое тратится на координацию работы команд, сильно отвлекает. Чтобы сохранить техническую квалификацию и остаться инженером, я сделал две вещи.

Во-первых, я свел команды разработчиков и разработчиков в тестировании вместе. Работы там достаточно для всех, и я смог стащить кусочек для себя. Я занимался проектом с фазы проектирования и работал в нем достаточно, чтобы самостоятельно писать тесты.

Во-вторых, и это ключевая штука, если вы собираетесь заниматься технической работой, нужно абстрагироваться от всех отвлекающих факторов руководства. Сначала я просто выделял пару дней в неделю для самостоятельной работы. Взглянуть на тестирование глазами разработчика мне помогла работа по интеграции Google Feedback в Gmail. Каждый раз, когда я сталкивался с ненадежным тестом или неудобной частью тестовой инфраструктуры, я понимал, как наша работа выглядит для разработчиков. И все же, находясь в центральном офисе Google, полностью абстрагироваться от управленческой работы я не мог, поэтому я перебрался к коман­де Gmail в Цюрихе. Находясь в девяти часовых поясах от постоянного места работы, там, где я не являюсь начальником, я сумел влиться в инженерную команду и сделать очень много полезного!

— Можешь порекомендовать, как правильно комплектовать команду? Сколько должно быть разработчиков и тестировщиков? Как насчет соотношения разработчиков в тестировании и инженеров по тестированию?

Анкит: Главное правило найма — никаких компромиссов. Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата. Нанимайте только лучших, и точка. Google не освещает соотношения инженеров в команде, но скажу, что раньше на нашем проекте тестировщиков было больше нормы. Решив первоочередные проблемы, мы увеличили долю участия разработчиков и вернулись к средним по Google показателям. Для Gmail хорошо сработал следующий вариант: 20% тестировщиков занимались исследовательским тестированием. Любой продукт, в котором взаимодействие с пользователем на первом месте, должен проходить исследовательское тестирование. Еще 30% составляли инженеры по тестированию, которые были сильнее сконцентрированы на продукте, они работали рука об руку с разработчиками в тестировании и обеспечивали максимальный результат их работы. Оставшиеся 50% составляли разработчики в тестировании, работающие над автоматизацией, добавлением инструментов для поддержания кодовой базы в рабочем состоянии и улучшением производительности разработчиков. Не знаю, буду ли применять такую разбивку ролей в следующем проекте Google, но для Gmail она сработала хорошо.

— Мы знаем, что тебе поручено тестирование Google+. Какие ценные уроки тестирования Gmail помогут тебе в работе с новым продуктом?

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

— Пишите тесты на том же языке, на котором написано приложение.

— Человек, написавший функцию, должен быть ответственным за выполнение тестов для нее. Проигнорированные тесты выйдут вам боком.

— Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.

— Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.

— Мы все-таки в Google, а здесь важна скорость, ее ждут от нас пользователи. Убедитесь, что продукт работает быстро. Выделите это, если вам нужно доказать это остальным.

— Сотрудничество с разработчиками совершенно необходимо. Если его не будет, тестирование станет простым сглаживанием дефектов, а это не самая лучшая работа.

Инновации — часть ДНК Google. Команда тестирования должна иметь ген инноваций в крови, каждый участник должен изобретать новейшие решения проблем.

— Есть ловушки, в которые попадают инженерные команды?

Анкит: Да. Они думают, будто знают, чего хотят пользователи, и могут серьезно изменять продукт или новые фичи, не проводя экспериментов. Зачем вам хорошая тестовая инфраструктура для фичи, которую выкинут за ненадобностью? Дайте нескольким пользователям новую версию, получите обратную связь, а уж потом вкладывайтесь в грандиозную автоматизацию тестов.

Пока вы будете долго строить идеальное решение, рынок оставит вас позади. Работайте короткими итерациями, двигайтесь небольшими шагами, но двигайтесь!

Наконец, нужно найти идеальный момент для тестирования. Напишете тесты слишком рано — архитектура изменится, и вся работа коту под хвост. Затянете — вам придется переносить выпуск из-за нехватки качественного тестирования. TDD вам в помощь!

— А что же про конкретных людей? Ты заметил какие-нибудь типичные ошибки молодых инженеров по тестированию и разработчиков в тестировании?

Анкит: Ошибка новичков — отчаянно бросаться в работу. Они неистово пишут тесты, не обдумывая их назначение и место в общем процессе тестирования. Они не всегда понимают, что нужно брать ответственность за тесты, которые они приручили. То есть написали. Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код — задача разработчика, а их задача — ввести тестирование в рабочий процесс разработчика. Мы создаем условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации.

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

— Какие еще успехи в области тестирования принесли пользу Gmail?

Анкит: Автоматизация JavaScript. Мы встроили сервлет автоматизации прямо в Gmail, и разработчики смогли писать сквозные тесты на том же языке, на котором была написана клиентская часть. Разработчики легко освоились с написанием тестов, потому что в них использовались те же методы и библиотеки — не пришлось тратить время на изучение. Стало просто писать тесты и определять, не нарушает ли новая возможность работу Gmail, и тем самым защищать старые фичи. Каждая функция Gmail теперь выпускается по меньшей мере с одним тестом, написанным с помощью этого сервлета. Кстати, сейчас я использую такую технологию в своей новой работе над Social. У нас уже более 20 тысяч автоматизированных тестов!

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

Наконец, наша ориентация на предотвращение багов (вместо их выявления) принесла плоды. Мы на ранней стадии включили автоматизированные тесты в процесс, предшествующий выпуску, и предотвратили попадание в сборку некачественного кода. Благодаря этому команда тестирования продолжает опережать ожидания и работает над сборками такого высокого качества, что нашим исследовательским тестировщикам есть над чем потрудиться.

— Итак, ты набил руку и теперь переходишь в социальные сервисы. На что ты будешь обращать внимание при найме участников в эту команду тестирования?

Анкит: Я хочу найти людей, которые не боятся сложностей. Тех, кто, сталкиваясь с большой проблемой, сможет разбить ее на конкретные шаги и, конечно, справится со всеми! Мне нужны люди, которые от жестких сроков не впадают в панику, а начинают действовать более эффективно. В моей команде должны быть люди, которые держат баланс между инновациями и качеством, чьи идеи выходят за рамки поиска багов. Кроме всего, я хочу видеть энтузиазм. Мне нужны люди, которые искренне хотят быть тестировщиками.

— Мы подходим к последнему вопросу. Почему ты выбрал тестирование?

Анкит: Мне нравится жонглировать быстрыми итерациями и высоким качеством — двумя на первый взгляд конфликтующими, но одинаково важными целями. Это классическое противостояние, которое заставляет меня оптимизировать оба направления — без ущерба для любого из них. Сделать новый продукт легко. А вот сделать его быстро и качественно — это целое испытание, которое стимулирует мою профессиональную жизнь и делает ее такой интересной.

Оглавление книги