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

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 22 (всего у книги 26 страниц)

Интервью с Суджаем Сани, директором по тестированию в индийском Google

Мы привлекаем талантливых людей в разных странах через распределенную систему офисов, создавая региональные и глобальные центры разработки Google. В Индии было много способных инженеров, поэтому наш первый глобальный центр тестирования появился именно там, в Хайдарабаде. Сотрудники центра работают над ключевыми продуктами Google, и это помогает переходу от ручного тестирования (служба тестирования, вы помните?) к инженерному тестированию. Суджай Сани – директор по тестированию, который основал и возглавил направление продуктивности разработки в Индии.

– Индия находится далеко от главного офиса Google в Маунтин-Вью. Почему именно здесь появился столь важный технический отдел?

Суджай:Наш отдел формировался так же, как и любой другой в Google, команда собралась там, где была концентрация подходящих специалистов. Ключевой фактор появления отдела именно в Индии – не низкая стоимость рабочей силы, а наличие исключительных специалистов в этом регионе. Сейчас Индия – один из многих региональных центров, где работают и разработчики, и тестировщики, такой же, как в Лондоне, Нью-Йорке, Киркленде, Бангалоре и других городах.

Из регионального офиса мы выросли в глобальный центр. Сейчас Хайдарабад – это центр Азиатско-Тихоокеанского региона Google, офис в Цюрихе – европейского, а в Нью-Йорке – центр Восточного побережья США. Центры объединяют и организовывают работу более мелких офисов Google в своем регионе, они помогают экономить время и распределять ресурсы.

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

– Какую роль сыграл индийский офис в эволюции тестирования Google?

Суджай:Как я уже говорил, наш региональный центр стал первым. Хотя мы открыли офис в Бангалоре, хайдарабадский центр (или сокращенно HYD) быстро стал глобальным хабом инженерных подходов к тестированию. С самого начала в HYD работали и инженеры по тестированию, и разработчики в тестировании, и большое количество временных и внешних сотрудников. Они занимались самыми значительными продуктами Google: Search, Ads, Mobile, Gmail, Toolbar и другими. В первую очередь они разработали инфраструктуру тестирования и фреймворк для автоматизации тестирования, чем сильно ускорили выпуск продуктов. В 2006–2007 годах в команде HYD работала примерно половина всех разработчиков в тестировании в Google. Говорят, что роль разработчика в тестировании укрепилась в результате усилий первого тестировщика, нанятого в HYD. Не знаю, правда это или нет, но мы сделали возможной трансформацию службы тестирования в направление продуктивности разработки.

К концу 2007 года мы бросили все силы на развитие команды в новых областях, уменьшение фрагментации команд и создание зрелого сообщества сильных инженеров, чтобы справиться с растущим количеством новичков. В начале 2008 года мы сами стали открывать региональные центры тестирования, чтобы команды разработки могли работать бок о бок с локальными командами тестирования. Теперь мы могли начать работать с до сих пор нетронутыми областями. У нас дошли руки до продвинутых средств обнаружения задержек, инструментов контроля производительности и стабильности клиент-серверных и облачных систем, механизмов выявления деградации и средств клиентского тестирования.

Тогда же произошло еще одно изменение – мы начали вкладывать время и ресурсы в облачное тестирование и инфраструктуру инженерных инструментов. Мы работали над проектами Cloud Code Coverage, Cloud Scalable Test Infrastructure, Google Toolbox, разными IDE и другими экспериментами, большинство из которых в итоге стали боевыми инструментами. Наша команда не только разрабатывала нужные инструменты для инженеров Google, но и создавала основную инфраструктуру для внешних разработчиков, работающих с открытым кодом. Инженеры из HYD работали над App Engine, Selenium, плагинами Eclipse, IntelliJ и другими проектами опенсорс-сообщества.

– Все это хорошие, важные проекты. А ты можешь привести пример проекта, целиком выполненного в HYD?

Суджай:Да. Например, программа Google Diagnostic Utility была полностью разработана в Хайдарабаде. С ее помощью наша служба поддержки работает с пользователями по диагностике проблем, которые у них возникают с продуктами Google. Эта программа упрощает получение технических подробностей систем и железа пользователя.

Есть и другие примеры. Наш отдел сосредоточен на разработке инженерной инфраструктуры, инструментов и тестов для всего Google. Для разработчиков мы создаем среду разработки, основную облачную инфраструктуру для компилирования, тестирования и измерения покрытия кода, делаем возможным любой статический анализ. Для тестировщиков мы разрабатываем систему для анализа нагрузки и производительности облачных сервисов Google, а еще создаем инструменты тестирования для таких важных продуктов, как Search, Enterprise, Gmail и Ads.

– Давай поговорим об этих инструментах. Даже названия звучат интересно. Ты упомянул инструмент, который измеряет покрытие кода, расскажи о нем подробнее. Эта тема очень популярна в блоге Google Testing.

Суджай:Покрытие кода – это метрика, которая показывает эффективность тестов для кода проекта. В традиционном подходе каждая команда должна выделить отдельные ресурсы (инженерные, аппаратные и программные) для измерения этого покрытия. А в Google есть специальная группа людей, находящаяся в Индии, которая следит за тем, чтобы все инженерные команды легко получали свои метрики покрытия кода. Для этого команда должна потратить всего пять минут, чтобы один раз настроить эту функциональность. После настройки у них будут все метрики проектов и сборок с централизованной системой просмотра и анализа отчетов.

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

Еще в нашем арсенале есть вспомогательная система для назначения тестам приоритетов. С ее помощью определяются тесты, которые должны выполняться для конкретных изменений в коде. Это улучшает покрытие, прибавляет уверенности в качестве кода и ускоряет обратную связь. Тем самым мы экономим Google инженерные ресурсы.

– Похоже, это правильный подход к покрытию кода. А теперь расскажи о приложении Diagnostic Utility, которое ты упоминал.

Суджай:Diagnostic Utility задумали и реализовали разработчики в тестировании нашего центра в свое «двадцатипроцентное» время. Технических знаний обычного пользователя часто не хватает, чтобы дать нужную информацию для диагностики и отладки проблемы, а это приложение автоматически предоставляет эти данные.

Чтобы разобраться в проблеме пользователя, иногда нужны определенные технические данные. Это могут быть простые данные, которые клиент может предоставить (например, версия ОС), но бывает, что требуются подробности о версиях и конфигурациях приложений, поиск которых ставит пользователя в тупик.

Приложение Diagnostic Utility решает эту проблему. Теперь, когда службе поддержки нужна дополнительная информация о системе пользователя, они создают новую конфигурацию для этой утилиты, где перечисляют, какая информация требуется. Дальше пользователь получает по почте или скачивает с сайта поддержки небольшой (около 300 Кбайт) исполняемый файл, подписанный сертификатом Google. Этот файл диагностирует машину пользователя, собирает указанные в конфигурации данные и показывает их пользователю, чтобы он подтвердил их отправку в Google. Приложение хорошо воспитано – после отправки данных оно прибирает за собой и удаляется. Мы заботимся о конфиденциальности, поэтому все собранные данные отправляются только с согласия пользователя.

Служба поддержки пересылает данные разработчику для отладки. Приложение Diagnostic Utility делает работу команд клиентских приложений (например, Google Chrome и Google Toolbar) проще, а самому пользователю облегчает процесс получения технической поддержки.

– Ты пару раз упоминал тестирование нагрузки и производительности. Что здесь интересного расскажешь? Насколько мы понимаем, ваша команда активно участвует в тестировании производительности Gmail?

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

Наше решение состоит из трех частей:

– Предварительные тесты.Инженеры могут проводить тесты и измерять задержки перед отправкой изменений в коде в репозиторий. Это ускоряет обратную связь и снижает вероятность попадания багов в кодовую базу.

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

– Анализ задержек.Инфрастуктура выявляет изменения, из-за которых появилась задержка. Для этого весь комплект изменений делится на части, и тесты проводятся в контрольных точках.

Это решение уже помогло найти много критических багов до выпуска и сильно повысило качество продуктов. К тому же разработчики могут сами запускать тесты.

– Расскажи о каких-нибудь экспериментах. Чему вы научились на таких проектах?

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

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

Суджай:Это непросто сделать, но мы показали, что это может работать. Я вынес несколько важных уроков.

Модель «следуй за солнцем» [72]72
  «Следуй за солнцем» (от англ. – follow the sun) – модель рабочего графика межнациональных компаний, при котором руководитель, находящийся на одном континенте, в конце своего рабочего дня связывается с руководителем на другом континенте (где день только начинается) и передает ему дела, а тот в конце своего рабочего дня передает ему их обратно. Таким образом работа не прерывается, а просто двигается «вслед за солнцем».


[Закрыть]хорошо работает, если правильные команды занимаются правильными проектами. Наша раскиданная по всему миру команда смогла справиться с испытаниями, пусть и не без ошибок. Очень важно иметь хороший процесс передачи работы между часовыми поясами. Тщательно выбирайте людей и проекты. Вам нужны хорошие командные игроки, неравнодушные к продуктам, которые вы создаете.

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

Чтобы победить, нужны талантливые специалисты, которым можно доверить ключевые проекты. Повторю, Индия была выбрана не потому, что Google хотел сэкономить на рабочей силе, – есть места и подешевле. Просто мы всегда старались поддерживать качество найма и условия работы на высоком уровне. Мы вносим большой вклад в Google, а наши сотрудники получают достойную карьеру. Все в выигрыше.

Интервью с тест-менеджером Брэдом Грином

Брэд Грин, которого прозвали Босоногим, был тест-менеджером многих продуктов Google, включая Gmail, Google Docs и Google+. Сейчас он менеджер в разработке Google Feedback и еще экспериментирует с фреймворками веб-разработки в проекте Angular. Он известен тем, что у него много гениальных идей и нет обуви.

– Мы знаем, что раньше ты был разработчиком в компании Apple. Что заставило тебя перейти в Google и почему именно в направление продуктивности разработки?

Брэд:Линус Апсон помог мне решиться. Мы работали с ним в NeXT, [73]73
  NeXT – американская компания, основанная в 1985 году Стивом Джобсом. Занималась разработкой платформ для вузов и бизнеса. В 1996 году была куплена Apple.


[Закрыть]и он был воодушевлен компанией Google. Собеседования шли полгода, и в какой-то момент Патрик Коупленд заманил меня в направление продуктивности разработки. Фокус удался: я узнал в этом отделе так много, что теперь гораздо лучше подхожу на должность менеджера по разработке, на которую я вернулся. Пожалуй, каждого разработчика стоит отправлять на стажировку в команду тестирования.

– Что тебя больше всего удивило в культуре тестирования Google в начале твоей работы?

Брэд:Я пришел в Google в начале 2007 года, и изменения, о которых Патрик говорил в своем предисловии, еще не завершились. Меня поразило, как много ноу-хау тестирования здесь использовали. В любой новой команде я находил эксперта по тестированию, который меня удивлял. Проблема была в том, что весь этот богатый опыт был неуправляем. У эскимосов есть сотни слов для обозначения снега, [74]74
  Как оказалось, это неправда: http://ru.wikipedia.org/wiki/Эскимосские_названия_снега.


[Закрыть]а в Google были десятки терминов для одного вида теста. Когда я присоединялся к команде, мне приходилось учить их язык тестирования и термины. В одних командах процессы были жестко формализованы, а в других нет. Нужно было что-то менять.

– Что больше всего изменилось в тестировании с момента твоего прихода в Google?

Брэд:Две вещи. Первая: средний разработчик сейчас больше участвует в процессе тестирования и автоматизации. Он знает, что такое тесты API, что такое модульные, интеграционные и системные тесты. Он инстинктивно создает больше тестов, если сталкивается с проблемами во время непрерывной сборки. Ему даже не нужно напоминать об этом. Конечно, это существенно улучшило исходное качество и увеличило скорость выпуска. Вторая: нам удалось привлечь сотни первоклассных разработчиков на роли, связанные с тестированием. Я думаю, эти две вещи связаны. В Google появилась культура, в которой тестирование имеет значение, и тестировать – это круто.

– Расскажи, что значит быть менеджером в Google? Что самое трудное, самое простое и самое интересное в работе менеджера в Google?

Брэд:Самое сложное – научиться управлять людьми, которые могут руководить своей работой сами. Вариант «делай так, как я сказал» сработает разок, а потом вы потеряете контакт с этими талантливыми ребятами, и они будут делать только то, что, по их мнению, лучше для проекта. Моя работа приносила максимальную пользу, когда я помогал, а не руководил, когда я делился информацией и создавал комфортные условия для моих сотрудников, чтобы они занимались любимым делом. Если мне приходилось приказывать, я чувствовал, что не развиваю ребят, не помогаю им учиться принимать решения. Надо стать не названным, а признанным лидером среди чрезвычайно умных и увлеченных инженеров. Менеджеры, будьте осторожны!

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

Брэд:Признаюсь, мы двигаемся два шага вперед, один назад. Я терплю неудачи в этой области уже четыре года – и многому научился! Я говорю «неудачи», потому что мы проделали колоссальный путь в поисках волшебных метрик для качества кода и тестов, которые могла бы использовать любая команда. Метрики трудно обобщить, потому что контекст очень важен. Да, чем больше тестов – тем лучше, если только они не медленные и не ненадежные. Да, малые тесты лучше больших, если только вам не нужно проверить строение всей системы. Измерения полезны, но реализация каждого теста уникальна и, наверное, так же близка к искусству, как и код самого приложения.

Оказывается, есть социальные факторы тестирования, которые гораздо сложнее, чем любые технические. Все понимают, что нужны хорошие тесты, но многим менеджерам трудно заставить команды их писать. Лучшее средство для мотивации – соревнования. Хотите получить больше малых тестов? Сравните свою команду с другой. Эй, у той команды тестовое покрытие – 84%, а полный набор тестов выполняется за пять минут! И мы позволим им обыграть нас?!

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

– Это объясняет твое участие в Google Feedback. Можешь немного рассказать о нем? Какие проблемы должен решать этот продукт?

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

– Можешь рассказать, как работает Google Feedback?

Брэд:Feedback собирает всю возможную информацию, соблюдая конфиденциальность пользователя. Браузер, операционная система, плагины – все эти данные очень важны для отладки и легко собираются программой. Особенная хитрость со скриншотами. В целях безопасности браузеры не копируют изображение своего содержимого. Нам пришлось заново реализовать механизм визуализации на JavaScript безопасным путем. Теперь мы делаем скриншот и просим пользователя выделить на нем проблемную область. Потом мы просим его описать проблему текстом. Невозможно научить пользователей создавать идеальные баг-репорты, но со скриншотами расплывчатые описания становятся яснее.

– Разве с таким количеством пользователей вы не будете получать сообщения об одном и том же баге?

Брэд:Чтобы избежать дублирования багов, мы автоматически группируем похожие сообщения. Если тысяча пользователей сообщает об одной проблеме, мы объединяем эти сообщения в один слот. Вручную обработать такое количество сообщений было бы невозможно. Затем группы ранжируются, и мы определяем, какие проблемы затрагивают большее количество пользователей. Их мы и будем решать в первую очередь.

– Сколько человек в команде Google Feedback?

Брэд:В команде 12 разработчиков и три менеджера. Последних, конечно, больше, чем обычно, но здесь это оправданно, так как нужно координировать много проектов, связанных с Google Feedback.

– Какие самые серьезные проблемы возникали при запуске Google Feedback?

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

– Какое будущее ждет Google Feedback? Возможно ли, что когда-нибудь система станет доступной не только для сайтов Google?

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

– Каким ты видишь следующий шаг в развитии тестирования программных продуктов?

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

– У тебя есть какой-нибудь компромат на доктора Джеймса Уиттакера, о котором ты бы хотел поведать миру?

Брэд:Кроме того инцидента с костюмом бедняжки Мэри? Пожалуй, нет. Мы, менеджеры, своих не сдаем!