KnigaRead.com/
KnigaRead.com » Разная литература » Прочее » Уиттакер . - Как тестируют в Google

Уиттакер . - Как тестируют в Google

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн Уиттакер ., "Как тестируют в Google" бесплатно, без регистрации.
Перейти на страницу:

Как создать такую среду? Нужно четко определить зависимости, сделать их явными и создать систему непрерывной интеграции, которая делает свое дело. Главное, чтобы она быстро предоставляла информацию разработчикам. Если на получение обратной связи уходит больше пары минут, добавьте еще машин. Время процессора стоит гораздо дешевле рабочего времени инженера. Запустить, отладить или развернуть код должно быть так же просто, как ввести команду. Если вы работаете в веб-компании, упростите процедуру частичного развертывания.

— Какие инженеры нужны в твоей команде? Вряд ли любой разработчик сможет разрабатывать инструменты?

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

— Раз уж мы заговорили о пользователях, как ты убеждаешь людей применять твои инструменты?

Ашиш: Разработчики Google — это очень благодарные пользователи. Раз в неделю мы проводим встречи и демонстрируем наши инструменты. Инженеры приходят, задают вопросы, и если инструмент решает их задачи, они берут его на пробу. На инструменты, которые решают насущные проблемы, довольно большой спрос. Чем ближе к реальности, тем эффективнее. Надо быстро отказываться от проектов, которые нерезультативны или не востребованы.

— А тебе когда-нибудь попадались инструменты, которые только мешали работе или приносили больше вреда, чем пользы?

Ашиш: Да, но я даже не запоминаю их, так как все подобные проекты очень быстро забрасываются. Цель разработки инструментов — автоматизация процесса и его упрощение. Не нужно автоматизировать неправильные решения. Если разработчик совершает ошибку, зачем упрощать ему этот процесс? Отступите на шаг и оцените: может быть, нужно заняться чем-то более полезным.

— Над чем сейчас работаешь? Какие новые инструменты готовит твоя команда?

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

Интервью с Суджаем Сани, директором по тестированию в индийском 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.

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*