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

Наша концепция «Тест-сертификации» делала успехи (вы прочитаете про нее дальше в книге). Мы общались с командами разработчиков и помогали улучшить чистоту кода и внедрить юнит-тестирование на ранней стадии. Мы разрабатывали инструменты и обучали команды основам непрерывной интеграции, чтобы наши продукты всегда были готовы к тестированию. Бесчисленные мелкие усовершенствования и приемы, многие из которых описаны в книге, развеяли скептицизм. Тем не менее чего-то не хватало. Разработка все еще была разработкой, а тестирование так и оставалось тестированием. Все ингредиенты для изменения культуры присутствовали, но нам был нужен катализатор, который смог бы запустить объединение дисциплин.

Глядя на организацию, которая выросла из моей идеи о привлечении разработчиков на позиции тестирования, я понял, что тестирование было лишь частью нашей работы. У нас были команды, которые создавали все инструменты – от репозиториев исходного кода до инфраструктуры для багтрекинговой системы. Среди нас были инженеры по тестированию, инженеры по выпуску продуктов, разработчики инструментов и консультанты. Меня поражало, как сильно тот аспект нашей работы, который не являлся непосредственно тестированием, влиял на производительность. Возможно, наша команда называлась «службой тестирования», но наши обязанности были намного шире.

Поэтому я решил оформить все официально и сменил название команды на «направление продуктивности разработки». Смена названия привела к культурному сдвигу. Люди начали говорить не о контроле качества и тестировании, а о производительности. Повышение производительности – наша работа, а тестирование и контроль качества – работа всех, кто пишет код. Это означает, что и тестирование, и контроль качества входят в обязанности разработчика. Команда продуктивности разработки должна заботиться о том, чтобы разработчик мог заниматься этими двумя вещами.

На первых порах идея была абстрактной, а наш девиз «Ускоряем Google» поначалу звучал наигранно. Со временем мы выполнили обещание. Наши инструменты ускорили темпы разработки, мы переходили от одного бутылочного горлышка к другому, расчищали пути и решали проблемы, с которыми сталкивались разработчики. Наши инструменты помогли разработчикам писать тесты и наблюдать их результаты при каждой сборке. Тестовые сценарии уже не выполнялись локально на компьютере тестировщика. Их результаты публиковались на информационных панелях и собирались от версии к версии, так что в итоге они становились частью общедоступных данных о готовности приложения к выпуску. Мы не просто требовали участия разработчиков, мы упрощали его. Разница между тестированием и обеспечением продуктивности наконец-то стала ощутимой: Google мог создавать новое с меньшими затратами и обходиться без накопления технического долга.

Результаты? Пожалуй, я не буду предвосхищать содержание книги, потому что ее написали для того, чтобы рассказать о них миру. Авторы приложили огромные усилия, чтобы на основании собственной работы и опыта своих коллег из Google свести наш секретный рецепт успеха к конкретному набору практических методов. Мы добились успеха во многих отношениях – от сокращения времени сборки до автоматизированного тестирования в формате «запустил и забыл» и публикации в опенсорс новаторских инструментов тестирования. Когда я писал это вступление, в направлении продуктивности разработки работало около 1200 специалистов, что немногим больше численности всего технического персонала в 2005 году, когда я пришел в Google. Бренд «продуктивности» укрепился, а наше стремление ускорить Google стало неотъемлемой частью нашей технической культуры. С того первого дня, когда я сидел озадаченный и неуверенный на пятничной встрече, наша команда проделала путь длиной во много световых лет. Единственное, что не изменилось с тех пор, – моя трехцветная кепка с пропеллером. Она лежит у меня на столе и напоминает о том, как далеко мы ушли.

Патрик Коупленд – старший директор направления продуктивности разработки, вершина пирамиды тестирования в Google. Все тестировщики в компании подчиняются Патрику, а его руководителем, кстати, является Ларри Пейдж, соучредитель и исполнительный директор Google. Карьере Патрика в Google предшествовала почти десятилетняя работа в Microsoft на должности директора по тестированию. Он часто выступает публично и известен как архитектор используемой в Google технологии быстрой разработки, тестирования и развертывания ПО.

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

В Google ежедневно тестируются и выпускаются сотни миллионов строк кода, распределенного по миллионам исходных файлов. Миллиарды операций по сборке запускают выполнение миллионов автоматизированных тестов в сотнях тысяч экземплярах браузеров ежедневно. Операционные системы строятся, тестируются и выпускаются в пределах одного календарного года. Браузеры собираются ежедневно. Веб-приложения выпускаются почти непрерывно. В 2011 году сто новых фич Google+ были выпущены за сто дней.

Таковы масштабы и скорость Google – они же масштабы развития веб. О том, как Google организовал тестирование в таких условиях, расскажет эта книга. Мы покажем, как проектировалась, внедрялась и сопровождалась эта инфраструктура. Мы познакомим вас с людьми, которые повлияли как на разработку основных концепций этой структуры, так и на ее реализацию.

Конечно, так было не всегда. Путь, который прошел Google к тому, где он сейчас, не менее интересен, чем технологии тестирования, которые мы используем. Давайте переведем стрелки часов на шесть лет назад – тогда ситуация в Google слабо отличалась от ситуации в других компаниях, с которыми мы работали: дисциплина тестирования была второстепенной.

Специалисты этой области получали меньше, хотя и работали больше. Тестирование в основном было ручным, а люди, которые могли автоматизировать процесс, быстро переходили в разработчики, где они могли «приносить больше пользы». Основателям команды, которая сейчас называется направлением продуктивности разработки, пришлось продираться сквозь заблуждения о тестировании и корпоративную культуру, ставившую героические авралы на работе выше повседневной инженерной рутины. Сегодня зарплата тестировщиков Google соразмерна зарплате разработчиков, их премии и темпы карьерного роста сравнялись. То, что культура тестирования пережила непростой рост компании (по всем параметрам – количеству, разнообразию продуктов и объемам продаж) и структурные реорганизации, должно придать уверенности компаниям, которые решат следовать примеру Google. Тестирование можно организовать правильно. Добиться вменяемого отношения к нему со стороны разработчиков и руководства – реально.

Сейчас все больше компаний делает ставку на веб, поэтому технологии тестирования и организационная структура, описанные в этой книге, могут получить широкое распространение. Если вы с нами – читайте, эта книга объяснит вам, как добраться до цели.