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

Я не хочу управлять командой тестировщиков, которые слепо следуют тестовым сценариям. Это скучно. Я хочу управлять командой, которая занимается революционными разработками, создает новые инструменты, подходит творчески к решению рутинных задач. Добавляя участников в команду, я хочу сохранить ее высокий технический уровень. В этом состоит основная проблема с наймом. Нужно найти профессионалов, подходящих Google по техническим навыкам, и помочь им загореться тестированием. Конечно, Джеймс знает много таких людей, но когда-нибудь его сети опустеют. Поэтому я подхожу более основательно и стараюсь объяснить, что же делает тестирование такой интересной и творческой работой. Вы удивитесь, как много ребят, мечтавших стать разработчиками, захотели попробовать себя в тестировании. Когда они понимают, какая сложная и интересная эта работа, у меня появляется хороший тестировщик.

— И последний вопрос: зачем выбирать карьеру в области тестирования?

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

Директор по тестированию

Директор по тестированию в Google — личность самодостаточная. Трудно написать о нем целую главу и точно определить, кто же такой директор по тестированию, потому что каждый обладает полной независимостью и использует ее на всю катушку. У них есть лишь несколько общих черт. Например, они все подчиняются Патрику Коупленду. Все они работают в инфраструктуре Google, и раз в неделю директора по тестированию встречаются для обсуждения своих направлений. Однако в отличие от тест-менеджеров из предыдущего раздела (которыми они руководят), у директоров есть карт-бланш на руководство своими продуктовыми командами.

Еще одна общая черта — все директора утверждают решения о найме и переводе сотрудников и контролируют все вопросы комплектации тестовых команд. Им выделяется бюджет на проведение тимбилдингов, выездов и покупку сувенирки с символикой Google: рюкзаков, футболок, курток и т.д. Тестировщики даже соревнуются, кто закажет самое крутое снаряжение для своего войска. Уже вошло в обычай заказывать больше, чем нужно, чтобы потом делиться с другими. У тестирования в Google и так серьезная репутация, а уникальная одежда помогает ее поддерживать. Иногда они даже вводят моду на какую-то вещь. Команда Уиттакера сделала футболки с надписью «The Web Works (you’re welcome)»71; эти футболки стали настолько популярными, что их носили даже разработчики.

Это не попытка принудить команды к тотальной синхронизации и свести к минимуму работу, которая повторяется в разных командах. Мы ждем инноваций от всех команд, а соревновательность при разработке инструментов только делает команды сильнее. Тем не менее существуют регулярные и единовременные премии, которые стимулируют сотрудничество, поэтому свое «двадцатипроцентное» время инженеры часто тратят на другой проект, работая под началом другого директора. Часто директора используют «двадцатипроцентное время» для аккуратного перевода тестировщика в другую команду: сначала он проводит в новой команде 20% времени, а потом столько же тратит на работу в старой.

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

Задача директора — быть лидером. Он должен собирать сильные команды и мотивировать их на выпуск качественных и полезных продуктов, способных изменить что-то в отрасли. Директор должен быть технически грамотным, чтобы пользоваться уважением инженеров, динамичным, чтобы не отставать от стремительного стиля работы Google, и должен быть хорошим управленцем, чтобы поддерживать продуктивность команд. Директор должен быть ниндзя от инструментария и инфраструктуры Google, чтобы молниеносно принимать решения, необходимые для ежедневных выпусков.

Что помогает решать все эти задачи и быть успешным директором по тестированию в Google? Мы решили, что лучше всего нам ответят те люди, которые уже этим занимаются!

Интервью с Шелтоном Маром, директором по тестированию проектов Search и Geo

Шелтон Мар — директор по тестированию; эта должность является аналогом вице-президента в других компаниях. Он один из самых давних тестировщиков Google, человек, который пришел раньше Патрика Коупленда, в те времена, когда направление продуктивности разработки еще называлось просто службой тестирования. Шелтон вырос из тест-менеджера маленьких групп в директора, отвечающего за весь поиск, карты и инфраструктуру. Сейчас он руководит тестированием направления продуктов, которое Google называет Local and Commerce: все продукты, относящиеся к геолокации, включая Google Earth и Maps.

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

— Шелтон, ты долго работаешь в Google и, наверное, помнишь службу тестирования, о которой Патрик упоминает в предисловии. Расскажи, как выглядело тестирование в далекий докоуплендский период?

Шелтон:Тогда, конечно, все было иначе, но одна вещь так и не изменилась — компания Google всегда могла работать в очень быстром темпе. В те дни нам везло, так как интернет был проще, приложения меньше, а группы умных людей, просто работающих в полную силу, было достаточно. Было много авралов, но нескольких героев хватало, чтобы их преодолеть. В продуктах образовывались зависимости системного уровня, а сквозное тестирование проводилось и вручную, и автоматически. Чем больше мы росли, тем больше проблем вырастало из этих зависимостей.

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