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

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

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

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

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

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

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

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

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

Чтобы победить, нужны талантливые специалисты, которым можно доверить ключевые проекты. Повторю, Индия была выбрана не потому, что Google хотел сэкономить на рабочей силе, — есть места и подешевле. Просто мы всегда старались поддерживать качество найма и условия работы на высоком уровне. Мы вносим большой вклад в Google, а наши сотрудники получают достойную карьеру. Все в выигрыше.

Интервью с тест-менеджером Брэдом Грином

Брэд Грин, которого прозвали Босоногим, был тест-менеджером многих продуктов Google, включая Gmail, Google Docs и Google+. Сейчас он менеджер в разработке Google Feedback и еще экспериментирует с фреймворками веб-разработки в проекте Angular. Он известен тем, что у него много гениальных идей и нет обуви.

— Мы знаем, что раньше ты был разработчиком в компании Apple. Что заставило тебя перейти в Google и почему именно в направление продуктивности разработки?

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

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

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

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