Уиттакер . - Как тестируют в 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. Приложение хорошо воспитано — после отправки данных оно прибирает за собой и удаляется. Мы заботимся о конфиденциальности, поэтому все собранные данные отправляются только с согласия пользователя.