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

— Опиши баг, который ускользнул от вас и заставил краснеть после выпуска.

Шелтон:Об этом обязательно нужно спрашивать? Скажите мне, хоть кто-нибудь выпускал идеальный продукт? К сожалению, не я! Самые болезненные для меня баги всплыли после недостаточно тщательного тестирования изменений в конфигурации дата-центра. Однажды новая версия была выпущена вообще без проверки, и качество результатов поиска ухудшилось. Зато мы узнали, насколько эти изменения важны для качества. С тех пор мы включили их в обязательную проверку. У нас есть набор автоматизированных тестов, которые должны быть выполнены до того, как изменения в конфигурации или данных пойдут в эксплуатацию.

— Как вы определили, какие тесты конфигураций нужно автоматизировать?

Шелтон :Проявили наблюдательность! Каждый раз, когда мы находили конфигурацию, отрицательно влиявшую на результаты поиска, мы писали тесты для нее и всех ее вариаций, которые могли бы показать такие же плохие результаты. Вскоре в нашем тестовом пакете сформировался целый набор проблемных конфигураций. Потом мы сгенерировали набор данных, на которых мы могли тестировать проблемные конфигурации. Этот тип багов стал встречаться реже благодаря нашим действиям. Вот хороший пример того, как автоматизация придает нам уверенности при выпуске изменений.

Интервью с директором разработки инженерных инструментов Ашишем Кумаром

Инструменты — вопрос жизни и смерти для Google. Ашиш Кумар — это человек, который отвечает за разработку инструментов. В его зоне ответственности находится весь чемодан внутренних инструментов Google: от IDE, в которых пишут разработчики, до систем код-ревью, от инструментов сборки, контроля исходного кода и статического анализа до общей тестовой инфраструктуры — за все отвечает он. Даже команды Selenium и WebDriver отчитываются перед Ашишем.

Мы встретились с Ашишем, чтобы узнать об этой части Google поподробнее.

— Область автоматизации в Google кажется чем-то магическим, во многом благодаря GTAC , а ты — человек, который за всем этим стоит. Приоткрой нам завесу тайны, какие возможности предоставляет твой инструментарий инженерам Google ?

Ашиш:Команда разработки инженерных инструментов, а именно так мы называемся, отвечает за создание 90% инструментов, ежедневно используемых разработчиками Google, когда они пишут, собирают и выпускают качественные приложения. Последние 10% мы охватим, когда сможем поддерживать все команды, работающие с открытым кодом.

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

— Можно конкретнее?

Ашиш :Ладно, сами напросились! Набор инструментов включает:

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

— Инструменты разработки. Это плагины для IDE, которые приспосабливают инструменты к коду Google и связывают их с нашими облачными сервисами. Эти инструменты помогают быстро и качественно рецензировать код благодаря возможности встроенных сигналов во время код-ревью.

— Инфраструктура сборки. Эта система позволяет нам распределить сборку мультиязычного кода по десяткам тысяч процессоров, используя такие объемы памяти и дискового пространства, что мне даже представить страшно! Система сборки работает как для интерактивного, так и для автоматизированного использования. Она формирует результаты за секунды, хотя та же работа в другом случае занимала бы часы.

— Инфраструктура тестирования. Это масштабная непрерывная интеграция. Это означает ежедневное выполнение миллионов тестовых пакетов по каждой заливке кода разработчиками. Наша цель — предоставить мгновенную (или почти мгновенную) обратную связь для каждого разработчика. У этого есть и другая сторона: нужно масштабировать веб-тестирование. Для тестирования продуктов Google каждый день запускаются сотни тысяч браузерных сессий с разными сочетаниями браузеров и платформ.