и он был воодушевлен компанией Google. Собеседования шли полгода, и в какой-то момент Патрик Коупленд заманил меня в направление продуктивности разработки. Фокус удался: я узнал в этом отделе так много, что теперь гораздо лучше подхожу на должность менеджера по разработке, на которую я вернулся. Пожалуй, каждого разработчика стоит отправлять на стажировку в команду тестирования.

— Что тебя больше всего удивило в культуре тестирования Google в начале твоей работы?

Брэд: Я пришел в Google в начале 2007 года, и изменения, о которых Патрик говорил в своем предисловии, еще не завершились. Меня поразило, как много ноу-хау тестирования здесь использовали. В любой новой команде я находил эксперта по тестированию, который меня удивлял. Проблема была в том, что весь этот богатый опыт был неуправляем. У эскимосов есть сотни слов для обозначения снега,[74] а в Google были десятки терминов для одного вида теста. Когда я присоединялся к команде, мне приходилось учить их язык тестирования и термины. В одних командах процессы были жестко формализованы, а в других нет. Нужно было что-то менять.

— Что больше всего изменилось в тестировании с момента твоего прихода в Google?

Брэд: Две вещи. Первая: средний разработчик сейчас больше участвует в процессе тестирования и автоматизации. Он знает, что такое тесты API, что такое модульные, интеграционные и системные тесты. Он инстинктивно создает больше тестов, если сталкивается с проблемами во время непрерывной сборки. Ему даже не нужно напоминать об этом. Конечно, это существенно улучшило исходное качество и увеличило скорость выпуска. Вторая: нам удалось привлечь сотни первоклассных разработчиков на роли, связанные с тестированием. Я думаю, эти две вещи связаны. В Google появилась культура, в которой тестирование имеет значение, и тестировать — это круто.

— Расскажи, что значит быть менеджером в Google? Что самое трудное, самое простое и самое интересное в работе менеджера в Google?

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

— Твоя команда провела масштабную разработку метрик для разработчиков, которые тестируют. Какие метрики вы используете? Какие данные отслеживаете? Как это влияет на качество?

Брэд: Признаюсь, мы двигаемся два шага вперед, один назад. Я терплю неудачи в этой области уже четыре года — и многому научился! Я говорю «неудачи», потому что мы проделали колоссальный путь в поисках волшебных метрик для качества кода и тестов, которые могла бы использовать любая команда. Метрики трудно обобщить, потому что контекст очень важен. Да, чем больше тестов — тем лучше, если только они не медленные и не ненадежные. Да, малые тесты лучше больших, если только вам не нужно проверить строение всей системы. Измерения полезны, но реализация каждого теста уникальна и, наверное, так же близка к искусству, как и код самого приложения.