Джеймс Уиттакер - Как тестируют в Google

• Название: Как тестируют в Google
• Автор: Джеймс Уиттакер
• Издательство: Издательский дом "Питер"
• Жанр: Программирование
• Год: 2014
• ISBN: 978-5-496-00893-8

В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в 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 всегда могла работать в очень быстром темпе. В те дни нам везло, так как интернет был проще, приложения меньше, а группы умных людей, просто работающих в полную силу, было достаточно. Было много авралов, но нескольких героев хватало, чтобы их преодолеть. В продуктах образовывались зависимости системного уровня, а сквозное тестирование проводилось и вручную, и автоматически. Чем больше мы росли, тем больше проблем вырастало из этих зависимостей.

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

Мы пытались решить эту проблему, когда появился Пат.

— В бэкенд-системах, где труднее определить сквозной сценарий, ситуация была еще хуже?

Шелтон: Именно! Мы часто не могли выпускать бэкенд-системы так быстро, как хотели, потому что у нас возникали трудности с проверкой качества. От бэкенд­-систем зависит много вертикалей продуктов, поэтому они должны работать правильно. Например, из-за ошибки в BigTable пострадает множество приложений. Обновление такой системы создает «эффект домино» из-за проблем, которые невозможно обнаружить только сквозными тестами.

— То есть ты заменил затратные сквозные проверки усиленными проверками серверной инфраструктуры бэкендов? Расскажи о своих шагах.

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

— Какой фактор был ключевым для вашего успеха?

Шелтон: Для нас было важно получить поддержку разработчиков. Наши разработчики в тестировании очень тесно работали со своими партнерами из разработки (я специально использую слово «партнер», потому что это была совместная работа, а вовсе не заслуга только тестирования). Ребята вместе создавали новые методы тестирования на уровне разработки, и вся наша работа становилась лучше благодаря такому партнерству. Когда какие-то задачи не решались на уровне компонентов, мы решали их уровнем ниже. Динамика группы изменилась, и теперь вся команда проекта (и разработка, и тестирование) отвечала за качество на уровне компонентов, а инженеры по тестированию сосредоточились на процессе, фреймворках, инструментах и интеграции.

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

Шелтон: Вероятно, это стало самым важным нашим решением для Google. Мы осознали, какие вещи мы должны изменить в Google как можно раньше:

— преобразовать тестирование так, чтобы вся команда (и разработка, и тестирование) отвечала за качество продукта;

— тестирование должно стать неотъемлемой частью проектной команды. Значит, нам были нужны сильные инженеры, отлично ориентирующиеся в технологиях;

— тестирование должно использовать современные компьютерные технологии и методы.

Чтобы добиться этого, нам нужны были умные и сильные инженеры-программисты, которые понимают в тестировании (или хотя бы могут научиться). Как только мы взглянули на задачу с этой стороны, мы поняли, что можем привлечь в нашу команду лучших инженеров, чтобы расправиться с нашими головоломками тестирования. Тот факт, что мы собрали большую команду таких ребят, свидетельствует, что им действительно интересно.