Уиттакер . - Как тестируют в Google
Измерение покрытия поддерживается для тысяч проектов, всех основных языков программирования и миллионов файлов с исходным кодом. Инфраструктура покрытия интегрирована с облачной инфраструктурой Google для компилирования и сборки кода. Она масштабируется для постоянных изменений кода (происходящих ежеминутно!) и десятков тысяч сборок в день. Инфраструктура способна меняться вместе со стремительно растущей кодовой базой Google.
Еще в нашем арсенале есть вспомогательная система для назначения тестам приоритетов. С ее помощью определяются тесты, которые должны выполняться для конкретных изменений в коде. Это улучшает покрытие, прибавляет уверенности в качестве кода и ускоряет обратную связь. Тем самым мы экономим Google инженерные ресурсы.
— Похоже, это правильный подход к покрытию кода. А теперь расскажи о приложении Diagnostic Utility, которое ты упоминал.
Суджай: Diagnostic Utility задумали и реализовали разработчики в тестировании нашего центра в свое «двадцатипроцентное» время. Технических знаний обычного пользователя часто не хватает, чтобы дать нужную информацию для диагностики и отладки проблемы, а это приложение автоматически предоставляет эти данные.
Чтобы разобраться в проблеме пользователя, иногда нужны определенные технические данные. Это могут быть простые данные, которые клиент может предоставить (например, версия ОС), но бывает, что требуются подробности о версиях и конфигурациях приложений, поиск которых ставит пользователя в тупик.
Приложение Diagnostic Utility решает эту проблему. Теперь, когда службе поддержки нужна дополнительная информация о системе пользователя, они создают новую конфигурацию для этой утилиты, где перечисляют, какая информация требуется. Дальше пользователь получает по почте или скачивает с сайта поддержки небольшой (около 300 Кбайт) исполняемый файл, подписанный сертификатом Google. Этот файл диагностирует машину пользователя, собирает указанные в конфигурации данные и показывает их пользователю, чтобы он подтвердил их отправку в Google. Приложение хорошо воспитано — после отправки данных оно прибирает за собой и удаляется. Мы заботимся о конфиденциальности, поэтому все собранные данные отправляются только с согласия пользователя.
Служба поддержки пересылает данные разработчику для отладки. Приложение Diagnostic Utility делает работу команд клиентских приложений (например, Google Chrome и Google Toolbar) проще, а самому пользователю облегчает процесс получения технической поддержки.
— Ты пару раз упоминал тестирование нагрузки и производительности. Что здесь интересного расскажешь? Насколько мы понимаем, ваша команда активно участвует в тестировании производительности Gmail?
Суджай: Google выпускает очень много веб-приложений, и очень важно обеспечить быстрое взаимодействие пользователей с ними. А раз так, то тестирование производительности клиентской части — анализ скорости выполнения JavaScript и отображения страниц — обязательно должно проводиться перед каждым выпуском. Раньше на выявление причин задержек и последующую отладку могли уходить дни, а то и месяцы. Ребята из индийского отделения продуктивности разработки построили инфраструктуру для тестирования производительности фронтенда Gmail, чтобы покрывать самые важные действия пользователя. То, что пользователи делают чаще всего, должно проходить через тщательное тестирование производительности. Мы настраиваем специальные серверные конфигурации, тесты выполняются в контролируемой среде, которая минимизирует отклонения и помогает выявлять ухудшения в работе системы.
Наше решение состоит из трех частей:
— Предварительные тесты. Инженеры могут проводить тесты и измерять задержки перед отправкой изменений в коде в репозиторий. Это ускоряет обратную связь и снижает вероятность попадания багов в кодовую базу.
— Непрерывная сборка. Серверы тестирования синхронизируют последние изменения кода и тут же запускают соответствующие тесты, чтобы заметить и перехватить регрессию. Мы уменьшили время на обнаружение регрессии до нескольких часов или даже минут.
— Анализ задержек. Инфрастуктура выявляет изменения, из-за которых появилась задержка. Для этого весь комплект изменений делится на части, и тесты проводятся в контрольных точках.
Это решение уже помогло найти много критических багов до выпуска и сильно повысило качество продуктов. К тому же разработчики могут сами запускать тесты.
— Расскажи о каких-нибудь экспериментах. Чему вы научились на таких проектах?
Суджай: Мы экспериментировали с инструментами обратной связи, которые собирают нужные данные и предоставляют метрики командам, чтобы сделать их работу еще более эффективной. Сюда же входят инструменты визуализации кода, измерения сложности кода и другие подобные инструменты. Еще мы работали с расширенной средой разработки, которая совершенствовала привычные механизмы использования среды и метрик, чтобы повысить качество кода и пропускную способность команды. Еще был инструмент, который собирал информацию после выпуска продукта, чтобы разработчики могли принять правильные меры.
— Напоследок расскажи, что ты думаешь о глобальной организации тестирования. Ты ведь работаешь в компании, где разработка сильно распределена.
Суджай: Это непросто сделать, но мы показали, что это может работать. Я вынес несколько важных уроков.
Модель «следуй за солнцем»72 хорошо работает, если правильные команды занимаются правильными проектами. Наша раскиданная по всему миру команда смогла справиться с испытаниями, пусть и не без ошибок. Очень важно иметь хороший процесс передачи работы между часовыми поясами. Тщательно выбирайте людей и проекты. Вам нужны хорошие командные игроки, неравнодушные к продуктам, которые вы создаете.
Нас очень выручило краудсорс-тестирование. Мы пользуемся огромным резервом талантливых специалистов в Индии. Разница во времени нам здесь нестрашна, и это действительно работает.
Чтобы победить, нужны талантливые специалисты, которым можно доверить ключевые проекты. Повторю, Индия была выбрана не потому, что Google хотел сэкономить на рабочей силе, — есть места и подешевле. Просто мы всегда старались поддерживать качество найма и условия работы на высоком уровне. Мы вносим большой вклад в Google, а наши сотрудники получают достойную карьеру. Все в выигрыше.
Интервью с тест-менеджером Брэдом Грином
Брэд Грин, которого прозвали Босоногим, был тест-менеджером многих продуктов Google, включая Gmail, Google Docs и Google+. Сейчас он менеджер в разработке Google Feedback и еще экспериментирует с фреймворками веб-разработки в проекте Angular. Он известен тем, что у него много гениальных идей и нет обуви.
— Мы знаем, что раньше ты был разработчиком в компании Apple. Что заставило тебя перейти в Google и почему именно в направление продуктивности разработки?
Брэд: Линус Апсон помог мне решиться. Мы работали с ним в NeXT73, и он был воодушевлен компанией Google. Собеседования шли полгода, и в какой-то момент Патрик Коупленд заманил меня в направление продуктивности разработки. Фокус удался: я узнал в этом отделе так много, что теперь гораздо лучше подхожу на должность менеджера по разработке, на которую я вернулся. Пожалуй, каждого разработчика стоит отправлять на стажировку в команду тестирования.
— Что тебя больше всего удивило в культуре тестирования Google в начале твоей работы?
Брэд: Я пришел в Google в начале 2007 года, и изменения, о которых Патрик говорил в своем предисловии, еще не завершились. Меня поразило, как много ноу-хау тестирования здесь использовали. В любой новой команде я находил эксперта по тестированию, который меня удивлял. Проблема была в том, что весь этот богатый опыт был неуправляем. У эскимосов есть сотни слов для обозначения снега74, а в Google были десятки терминов для одного вида теста. Когда я присоединялся к команде, мне приходилось учить их язык тестирования и термины. В одних командах процессы были жестко формализованы, а в других нет. Нужно было что-то менять.
— Что больше всего изменилось в тестировании с момента твоего прихода в Google?
Брэд: Две вещи. Первая: средний разработчик сейчас больше участвует в процессе тестирования и автоматизации. Он знает, что такое тесты API, что такое модульные, интеграционные и системные тесты. Он инстинктивно создает больше тестов, если сталкивается с проблемами во время непрерывной сборки. Ему даже не нужно напоминать об этом. Конечно, это существенно улучшило исходное качество и увеличило скорость выпуска. Вторая: нам удалось привлечь сотни первоклассных разработчиков на роли, связанные с тестированием. Я думаю, эти две вещи связаны. В Google появилась культура, в которой тестирование имеет значение, и тестировать — это круто.
