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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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