Итак, мы выяснили, что в Google есть инженеры по тестированию и разработчики в тестировании, которые играют на стороне пользователей и разработчиков соответственно. А сейчас мы поговорим о третьей роли, которая связывает и координирует их работу. Речь идет о тест-менеджере. Это в первую очередь инженер, которые вносит технический вклад в проект. В то же время именно через него взаимодействуют все команды, от разработчиков и выпускающих менеджеров до менеджеров продукта и технических писателей. Плюс ко всему тест-менеджер обладает управленческими навыками и помогает своим подчиненным в профессиональном росте. Пожалуй, это самая сложная должность в Google.

 

Кто такой тест-менеджер

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

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

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

Итак, наш первый совет — знайте свой продукт. Тест-менеджер должен быть готов ответить на любые вопросы по использованию своего продукта. Допустим, вы — тест-менеджер Chrome. Если вас спросят, как установить расширение, сменить оформление браузера, настроить синхронизацию, изменить настройки прокси-сервера, просмотреть DOM, найти хранилище cookie, поставить новую версию, то ваши ответы должны отскакивать от зубов. Хороший руководитель знает о своем продукте все — от пользовательского интерфейса до внутренних подробностей работы дата-центров.

Однажды я спросил тест-менеджера Gmail, почему моя почта медленно загружается, и я тут же узнал, как работают отдельные части сервера Gmail, и о том, что на этой неделе была проблема с удаленным дата-центром. Объяснение было даже слишком подробным, но я понял, что этот человек точно знает, как функционирует Gmail, и владеет самыми свежими данными о его производительности. Это именно то, чего мы ожидаем от всех тест-менеджеров: знать о своем продукте больше всех участников проекта.

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

У нас в Google работают очень умные ребята, но их количество не бесконечно. Каждый тест-менеджер, приходящий извне, жалуется, что в его проекте недостаточно людей. Мы лишь дружно улыбаемся в ответ. Мы знаем это и не собираемся ничего менять. Хорошо зная своих людей и их навыки, руководитель может маленькой командой добиться тех же результатов, что и большим количеством людей. В этом сила тест-менеджера.

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

В тестировании программных продуктов в Google работает такая же схема. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности.

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

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

 

Жонглирование людьми и дирижирование проектами

Фирменная особенность инженерной работы в Google — возможность поменять проект. Как правило, у сотрудника появляется такая возможность примерно раз в 18 месяцев. Конечно, мы не заставляем людей это делать. Если инженеру нравятся мобильные операционные системы, никто не будет кидать его бороздить просторы YouTube. Такая мобильность позволяет попробовать разные проекты. Многие хотят оставаться на одном проекте годами или в течение всей своей карьеры, другие предпочитают узнать обо всем, что делает Google. Мы просто хотим, чтобы у сотрудников был выбор.

Такая особенность работы на руку тест-менеджеру. Фактически получается, что можно в любое время нанять к себе сотрудника с опытом в разных областях. Представьте, что ваш проект — Google Maps, и вы привлекаете к работе ребят, которые работали с Chrome и Google Docs! То есть вы всегда можете пополнить свою команду инженерами с необходимым опытом и свежим взглядом на ситуацию.

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

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

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

Основные приоритеты распределения:

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

— Пожелания нового сотрудника. Обретение работы мечты может сделать его счастливым, а значит, и производительным инженером.

— Потребности проекта. Стратегически или экономически важные проекты иногда получают более высокий приоритет.

— Прошлые распределения. Если проект давно не получал новых сотрудников, возможно, ему стоит отдать предпочтение.

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

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

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

Когда тест-менеджер сам выбирает проекты, ему стоит избегать команд «с душком». Если команда не желает вносить равноправный вклад в качество, пусть они решают свои проблемы с тестированием как хотят. Если кто-то не желает писать малые тесты и обеспечивать покрытие на модульном уровне, не стоит присоединяться к ним и мешать людям копать себе могилу.

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

 

Влияние

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

Целью любого отдельного инженера и всей команды должно быть реальное влияние. Именно тест-менеджер отвечает за то, чтобы команда тестирования оказывала реальное влияние в компании.

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

Управлять влиянием команд тестировщиков и разработчиков в тестировании — работа тест-менеджера.

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

Итак, что является важным фактором в ходе ежегодного рецензирования работы и принятия решений о повышении? Правильно — старое доброе влияние. Оно оценивается для каждого сотрудника соответственно его должности и зоне ответственности. Для рядового инженера — в рамках его части проекта, для менеджера — в масштабе его команды и продукта. Чем выше взбирается человек, тем большего влияния от него требуют, вплоть до влияния на весь Google (но об этом позднее).

Это работа тест-менеджера ­— построить команду, способную влиять на ситуацию так, чтобы каждый ее участник вносил свой вклад в зависимости от своей роли и навыков. Причем менеджеры Google не обязаны следить за каждой мелочью в процессе тестирования, не должны стоять за плечом у разработчика в момент создания тест-плана или просматривать каждую строчку кода. Их дело — чтобы все задачи решались правильными инженерами, серьезно нацеленными на результат, которые знают, как подойти к проблеме и что нужно использовать для ее решения. Тест-менеджер как будто расставляет всех важных игроков по полю, а дальше отходит в тренерскую зону — игра началась.

Давайте помечтаем о команде тестирования, в которой каждый инженер способен выполнять работу, приносящую ценность, и работает с максимальной пользой. О тщательно оптимизированном процессе тестирования, в котором каждая выполняемая единица работы направлена на достижение цели. О команде разработки, которая осознает объем работы по тестированию и участвует в ней. Задача тест-менеджера превратить все эти мечты в реальность.

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

Наши команды тестирования подтверждают репутацию Google как инновационной компании. Множество тестовых приемов и инструментов, которые мы создали и которые используются за пределами Google, тому доказательство. Это стало возможным, потому что наши тестовые команды связаны общим духом инноваций. Тест-менеджеры обмениваются опытом не потому, что им так приказано свыше, и не потому, что ежемесячная встреча добавлена в календарь. Они собираются и общаются потому, что не хотят упустить свой шанс попробовать новые полезные изобретения другой команды. Кто-то хочет остаться последним тестировщиком, не пользующимся новейшим инструментом? Кто-то не хочет работать быстрее? У нас таких нет!

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

 

Интервью с Анкитом Мехтой, тест-менеджером Gmail

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

Gmail не для слабаков: в этом продукте очень много динамических частей, за которыми нужно следить. С одной стороны, Gmail интегрируется с другими технологиями Google, включая Docs, Calendar и т.д., с другой — Gmail должен взаимодействовать с форматами других почтовых сервисов. Здесь требуется огромная работа с базами данных, так как Gmail работает в облаке, а его пользовательский интерфейс доступен через любой браузер. Не верите, что это сложно? Тогда вспомните, что Gmail имеет сотни миллионов пользователей, которые ожидают, что почта будет работать быстро, надежно, безопасно, а заодно справится с потоком спама. Добавляя новые фичи, надо сохранять рабочее состояние старых, что здорово затрудняет тестирование. Если в Gmail появляется баг, то весь мир узнает об этом мгновенно. Помидоры летят во многих в Google, но в первую очередь в находящегося на передовой менеджера.

Мы встретились с Анкитом, чтобы узнать, как было организовано тестирование Gmail.

— Расскажи, как ты подходишь к новому проекту по тестированию. Что ты делаешь в первую очередь, какие вопросы задаешь?

Анкит: Первые несколько недель в проекте я только слушаю. Очень важно сориентироваться, узнать архитектуру продукта и динамику команды. Я бы не стал слушать врача, который в первые пять минут моего визита выписывает мне антибиотики. Так же и команда не станет работать со мной, если я с ходу начну «ставить диагноз». Чтобы получить право выписывать лекарства, нужно многому научиться.

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

Анкит: Все так! Но у меня есть своя схема. Я понял, что самый сильный вопрос, который можно задать, «почему?». Когда я выхожу из роли молчуна, я обычно начинаю с него. Почему вы выполняете эти тесты? Почему вы написали этот тест? Почему вы автоматизируете эту задачу, а не другую? Почему мы тратим ресурсы на разработку этого инструмента?

Я думаю, что люди склонны что-то делать только потому, что видели, как это делают другие, или тестировать какую-то фичу потому, что точно знают — они с ней справятся. Если не спрашивать их «почему», они так и будут действовать по инерции, не объясняя себе свои действия.

— Какие же ответы на вопрос «почему» для тебя приемлемы?

Анкит: Всего два ответа. Во-первых, потому что это улучшает качество продукта. Во-вторых, потому что это повышает производительность инженеров, работающих на проекте. Все остальные ответы менее значимы для продукта.

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

Анкит: Очень важна динамика команды. Я считаю, что качество продукта связано с качеством команды тестирования. Сначала подберите нужных людей, с правильными навыками и настроем, а потом направьте их делать правильные вещи. Вы — руководитель команды, и именно ваше влияние создает здоровую рабочую культуру. Работая с Gmail, я формировал команду шесть месяцев, потому что мне хотелось создать сплоченную группу людей, где все понимают и уважают роли друг друга. Если вам удалось создать крепкую команду, она выдержит даже присутствие пары специалистов, которые не очень в нее вписываются.

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

— Судя по всему, тебе удалось исправить ситуацию, давай поговорим об этом. Расскажи, что ты сделал для того, чтобы рабочая среда стала комфортной?

Анкит: Когда я присоединился к проекту, команда тестирования была сосредоточена на тестах WebDriver, которые выполнялись для каждой сборки. Они проводили тесты, следили, как состояние меняется с зеленого (тесты проходят) на красный (тесты не проходят), и прикладывали титанические усилия к исправлению тестов, чтобы они не показывали ложные срабатывания. Команда разработки не сомневалась в том, что вся работа построена правильно, потому что тесты действительно обнаруживали важные проблемы, а значит, были оправданны. Однако иногда изменения затрагивали большие объемы кода, и оперативно исправить тесты не получалось. Чтобы достичь результатов, приходилось выполнять слишком большую работу. Весь процесс был ненадежным и недостаточно гибким для такого подвижного и сложного сервиса, как Gmail.

Так как я был новичком в проекте, мой взгляд не был замылен. Мне казалось, что самой серьезной проблемой Gmail были задержки. Серьезно, ведь для пользователя главный атрибут Gmail — скорость. Я решил, что если мы справимся с этой проблемой, мы сможем заслужить уважение разработчиков и они будут воспринимать нас как равных.

Задача была тяжелой. В каждой сборке мы сравнивали ее скорость со скоростью предыдущей версии, чтобы поймать случай, когда новая сборка работает медленнее. После мы перебирали все изменения кода в новой версии, чтобы найти и уничтожить причину задержки. Это был долгий и сложный путь с большим количеством проб и ошибок.

Я вместе с одним разработчиком в тестировании искал способ специально замедлить работу Gmail. Мы хотели лучше контролировать взаимодействие между клиентской частью и дата-центром, чтобы найти регрессии, влияющие на производительность. Собрав несколько старых компьютеров и лишив их всех ускоряющих компонентов, мы получили целую комнату системных блоков с 512 мегабайтами памяти, 40-гигабайтными дисками и медленными процессорами. Работа Gmail стала медленной, и мы смогли отличить сигнал от шума. Мы запустили долгосрочные тесты, которые создавали дополнительную нагрузку системе.

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

Нам удалось заработать уважение для команды тестирования, и когда мы взялись за следующие высокоприоритетные задачи (исправление сквозных тестов и налаживание инфраструктуры тестирования фактической нагрузки), разработчики сами вызывались помочь нам. Вся команда убедилась в пользе эффективных тестов, выпуски Gmail из ежеквартальных стали еженедельными, а потом и ежедневными.

— Отличный урок: возьмите трудную задачу, решите ее, заслужите уважение. А что ты делал после этого?

Анкит: Трудную задачку можно найти всегда! Хотя общая идея остается в том, чтобы сосредоточиться на самом важном. Мы обозначили самую серьезную проблему Gmail, собрались вместе и решили ее. Затем мы пошли дальше по списку, и все решалось легко, так как у нас была сплоченная команда. Все-таки я больше верю в пользу сфокусированной работы. Когда я вижу, как команда пытается прыгнуть выше своей головы (скажем, работает над пятью задачами одновременно, хотя каждую выполняет только процентов на восемьдесят), я заставляю их сделать шаг назад и расставить приоритеты. Пусть количество задач будет меньше, но зато они будут решены на все сто. Плюс для команды: появляется чувство удовлетворения от выполненной работы, незавершенные задачи перестают нависать у них над головой. Плюсы для меня: качество продукта улучшается и я счастлив.

— Менеджеры в Google имеют много подчиненных, но и сами обязаны вносить технический вклад в проект. Как ты совмещаешь эти занятия? Можешь ли рассказать нам о своей инженерной работе?

Анкит: Обилие подчиненных и время, которое тратится на координацию работы команд, сильно отвлекает. Чтобы сохранить техническую квалификацию и остаться инженером, я сделал две вещи.

Во-первых, я свел команды разработчиков и разработчиков в тестировании вместе. Работы там достаточно для всех, и я смог стащить кусочек для себя. Я занимался проектом с фазы проектирования и работал в нем достаточно, чтобы самостоятельно писать тесты.

Во-вторых, и это ключевая штука, если вы собираетесь заниматься технической работой, нужно абстрагироваться от всех отвлекающих факторов руководства. Сначала я просто выделял пару дней в неделю для самостоятельной работы. Взглянуть на тестирование глазами разработчика мне помогла работа по интеграции Google Feedback в Gmail. Каждый раз, когда я сталкивался с ненадежным тестом или неудобной частью тестовой инфраструктуры, я понимал, как наша работа выглядит для разработчиков. И все же, находясь в центральном офисе Google, полностью абстрагироваться от управленческой работы я не мог, поэтому я перебрался к коман­де Gmail в Цюрихе. Находясь в девяти часовых поясах от постоянного места работы, там, где я не являюсь начальником, я сумел влиться в инженерную команду и сделать очень много полезного!

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

Анкит: Главное правило найма — никаких компромиссов. Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата. Нанимайте только лучших, и точка. Google не освещает соотношения инженеров в команде, но скажу, что раньше на нашем проекте тестировщиков было больше нормы. Решив первоочередные проблемы, мы увеличили долю участия разработчиков и вернулись к средним по Google показателям. Для Gmail хорошо сработал следующий вариант: 20% тестировщиков занимались исследовательским тестированием. Любой продукт, в котором взаимодействие с пользователем на первом месте, должен проходить исследовательское тестирование. Еще 30% составляли инженеры по тестированию, которые были сильнее сконцентрированы на продукте, они работали рука об руку с разработчиками в тестировании и обеспечивали максимальный результат их работы. Оставшиеся 50% составляли разработчики в тестировании, работающие над автоматизацией, добавлением инструментов для поддержания кодовой базы в рабочем состоянии и улучшением производительности разработчиков. Не знаю, буду ли применять такую разбивку ролей в следующем проекте Google, но для Gmail она сработала хорошо.

— Мы знаем, что тебе поручено тестирование Google+. Какие ценные уроки тестирования Gmail помогут тебе в работе с новым продуктом?

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

— Пишите тесты на том же языке, на котором написано приложение.

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

— Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.

— Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.

— Мы все-таки в Google, а здесь важна скорость, ее ждут от нас пользователи. Убедитесь, что продукт работает быстро. Выделите это, если вам нужно доказать это остальным.

— Сотрудничество с разработчиками совершенно необходимо. Если его не будет, тестирование станет простым сглаживанием дефектов, а это не самая лучшая работа.

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

— Есть ловушки, в которые попадают инженерные команды?

Анкит: Да. Они думают, будто знают, чего хотят пользователи, и могут серьезно изменять продукт или новые фичи, не проводя экспериментов. Зачем вам хорошая тестовая инфраструктура для фичи, которую выкинут за ненадобностью? Дайте нескольким пользователям новую версию, получите обратную связь, а уж потом вкладывайтесь в грандиозную автоматизацию тестов.

Пока вы будете долго строить идеальное решение, рынок оставит вас позади. Работайте короткими итерациями, двигайтесь небольшими шагами, но двигайтесь!

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

— А что же про конкретных людей? Ты заметил какие-нибудь типичные ошибки молодых инженеров по тестированию и разработчиков в тестировании?

Анкит: Ошибка новичков — отчаянно бросаться в работу. Они неистово пишут тесты, не обдумывая их назначение и место в общем процессе тестирования. Они не всегда понимают, что нужно брать ответственность за тесты, которые они приручили. То есть написали. Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код — задача разработчика, а их задача — ввести тестирование в рабочий процесс разработчика. Мы создаем условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации.

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

— Какие еще успехи в области тестирования принесли пользу Gmail?

Анкит: Автоматизация JavaScript. Мы встроили сервлет автоматизации прямо в Gmail, и разработчики смогли писать сквозные тесты на том же языке, на котором была написана клиентская часть. Разработчики легко освоились с написанием тестов, потому что в них использовались те же методы и библиотеки — не пришлось тратить время на изучение. Стало просто писать тесты и определять, не нарушает ли новая возможность работу Gmail, и тем самым защищать старые фичи. Каждая функция Gmail теперь выпускается по меньшей мере с одним тестом, написанным с помощью этого сервлета. Кстати, сейчас я использую такую технологию в своей новой работе над Social. У нас уже более 20 тысяч автоматизированных тестов!

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

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

— Итак, ты набил руку и теперь переходишь в социальные сервисы. На что ты будешь обращать внимание при найме участников в эту команду тестирования?

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

— Мы подходим к последнему вопросу. Почему ты выбрал тестирование?

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

 

Интервью с Хуном Даном, тест-менеджером Android

До того как Хун Дан был приглашен возглавить команду тестирования Android, он успел успешно поработать инженером в Apple и TiVo.

Cтратегическую важность Android для Google трудно отрицать. Этот проект стал таким же хитом, как Search или Ads. Android получил особое внимание руководства и привлек первоклассных специалистов. Его кодовая база растет на глазах, и одна сборка может насчитывать сотни изменений в день. На базе этой операционной системы запускаются тысячи приложений, вокруг нее формируется сообщество разработчиков. Количество устройств, работающих на платформе Android, постоянно растет; она стоит на новых телефонах и планшетах множества производителей. В зоне ответственности Хуна и его команды все: от тестирования совместимости устройств и управления питанием до проверки работы приложений.

Мы встретились с Хуном, чтобы узнать, как организовано тестирование Android.

— Расскажи нам о том, как начиналось тестирование. Наверное, на первых порах, до появления смартфонов и многочисленных приложений, было проще?

Хун: К сожалению, нет. Когда я взял на себя руководство тестированием Android, команда только сформировалась и многие инженеры никогда не тестировали до этого операционные системы, не говоря уже о мобильных устройствах. Моей первой задачей было скоординировать работу команды и построить инфраструктуру тестирования. Я думаю, что начальная фаза проекта тестирования — самая трудная часть работы. Когда у тебя есть крепко сбитая команда и налаженная инфраструктура, то можно справиться с продуктом любой сложности. Тяжелее всего в планировании, зато потом легко в тестировании!

— Давай остановимся здесь, ведь множество менеджеров по тестированию бьются на ранних стадиях своих проектов прямо сейчас. Расскажи, что вы делали на ранней стадии проекта Android?

Хун: Серьезных задач было много. Самая первая — вникнуть в продукт. Я требую от тестировщиков досконального знания продукта. Первым делом нужно тщательно освоить то, с чем работаешь. Каждый участник моей команды должен знать структуру продукта, и точка. Когда ваши знания достигнут нужного уровня, самые сложные проблемы тестирования окажутся на поверхности и вам, отталкиваясь от них, будет легко формировать команду. Нанимайте или привлекайте людей, которые справятся с самыми сложными задачами проекта. Структура Android очень разветвленная: от аппаратного уровня до ОС, фреймворка, модели приложений и магазина. В этом проекте много динамических частей, требующих особой квалификации тестирования. Поэтому первое, что я сделал, — это выявил их и собрал такую команду, которая бы с ними справилась.

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

— Звучит впечатляюще. И как команда справлялась?

Хун: На самом деле я потерял около 80% старой команды. Зато оставшиеся стали техническими лидами. Они подавали пример и работали с новичками, которых мы привлекали в команду. Нет универсальных людей, которые вписываются во все проекты. В Google достаточно работы, и если кому-то не подошел Android, то, возможно, подойдет другой проект. В Google такое разнообразие и создает здоровую среду тестирования.

— Какие были приятные моменты тестирования?

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

— Это непросто, хотя по твоим словам этого и не скажешь! Расскажи нам более подробно об организации тестирования, о которой ты обмолвился. Ты коснулся процесса сообщения о багах, но, конечно, это не все. Как ты организуешь саму работу?

Хун: Я воспринимаю структуру Android как своеобразную «колоннаду». Я знаю, что при тестировании Chrome OS вы используете другую терминологию, но мне нравится идея тестовых колонн. Каждая группа тестировщиков отождествляется с одной из таких колонн, на которых держится весь продукт. Для Android мы организовали четыре колонны: системную (ядро, носители информации и т.д.), колонну фреймворков, колонну приложений и колонну магазина приложений. Спросите любого из моих тестировщиков, что они тестируют, и вам укажут одну из этих колонн.

— Логично, что колонны соответствуют разным навыкам тестировщиков. Одни хорошо работают с низкоуровневыми аспектами, другие лучше справляются с высокоуровневыми, а вместе они поддерживают всю систему. Хорошая схема. А как насчет автоматизации? Как она вписывается в вашу задачу?

Хун: Я научился скептически относиться к автоматизации. Тестировщики могут загореться идеей автоматизации продукта и потратить месяцы на ее создание, а потом продукт или платформа меняется, и все, что они сделали, идет прахом. Нет более бессмысленной траты ресурсов. На мой взгляд, автотесты должны быстро создаваться, быстро выполняться и решать узкую задачу. Если цель автоматизированного теста непонятна сразу, значит он слишком сложен. Сделайте автоматизацию простой, ограничьте ее масштаб, а самое главное — следите за тем, чтобы она приносила пользу. Например, у нас есть пакет автоматизированных тестов, который проверяет сборку на возможность перехода из канареечного канала в Droid-канал.

— Минуточку! Что за Droid-канал?

Хун: О, извини. Как я уже упоминал в начале разговора, в проекте Android некоторые вещи делаются иначе. И называются тоже по-другому — мы используем не те каналы, к которым вы привыкли в Chrome. У нас есть канареечный канал, Droid-канал (аналог канала внутренних пользователей, но для команды Android), экспериментальный канал, Google-канал и уличный канал (сборка, которую мы передаем для внешнего использования). Идея та же, просто другое название.

— Итак, у вас есть пакет автоматизированных тестов для выявления багов, препятствующих переходу канареечной сборки в канал для разработчиков. Этими тестами занимаются выделенные разработчики в тестировании?

Хун: Ни в коем случае. У меня нет ни одного специализированного тестировщика. Все занимаются ручным тестированием, буквально все. Исследовательское тестирование — лучший способ хорошо изучить продукт. Я не хочу, чтобы мои разработчики в тестировании только и делали, что писали фреймворки. Я хочу, чтобы они были вовлечены в продукт и знали, как его использовать. Каждый тестировщик должен смотреть на продукт глазами пользователя, должен быть экспертом, разбирающимся во всех тонкостях продукта. Автоматизации мы оставляем тестирование стабильности, управления питанием, производительности, нагрузки, ну и еще быстрые проверки. Не нужен человек, чтобы обнаружить утечку памяти из-за использования камеры или чтобы проверить одну и ту же фичу на всех платформах. Действия, которые требуют многократного повторения или машинной точности, недоступной для людей, — вот где нужна автоматизация.

— Так значит, у вас больше тестировщиков, чем разработчиков в тестировании?

Хун: Нет, наоборот, разработчиков в тестировании почти вдвое больше. В моей команде каждый разработчик в тестировании может играть роль инженера по тестированию, когда это нужно, и наоборот. Я не обращаю особого внимания на должность человека, главное, чтобы он приносил пользу.

— Что ж, поговорим о ручном тестировании, потому что ты явно относишься к нему серьезно (и это восхищает!).

Хун: Я верю в пользу целенаправленного ручного тестирования. Действовать наугад неэффективно. Мы внимательно присматриваемся к ежедневной сборке, которую тестируем, и анализируем ее содержимое. Что изменилось? Сколько изменений добавилось или трансформировалось? Какая функциональность добавилась, а какая изменилась? Кто из разработчиков отправлял изменения? Насколько обширны изменения по сравнению со вчерашней сборкой? Это помогает сфокусироваться, и вместо рысканья по всему продукту мы сосредоточены на проверке изменений изо дня в день, что и делает нашу работу намного более производительной.

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

— Вы создаете документацию для ручного тестирования или занимаетесь исследовательским тестированием?

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

— Расскажи нам о своих требованиях к разработчикам. Ты требуешь от них спецификаций? Заставляешь применять TDD? Как насчет юнит-тестов?

Хун: Наверное, где-то есть сказочный мир, в котором каждой строке кода предшествует тест, а ему — спецификация. Не знаю, может, такой мир и существует. Но в стремительном современном мире, в котором я живу, приходится работать с тем, что имеешь. Есть спецификация? Отлично! Большое спасибо, пригодится! Давайте будем реалистами: нам нужно искать пути, как работать в существующей системе.

Если вы требуете спецификацию, это не значит, что вы ее получите. Если вы настаиваете на юнит-тестах, это еще не значит, что они принесут пользу. Ни написание спецификации, ни создание юнит-теста не поможет вам найти проблему, с которой столкнется реальный пользователь (кроме обнаружения очевидного регрессионного бага). Это законы моего мира — мира тестировщиков. Вы работаете с тем, что дано, и выжимаете из этого максимальную пользу для продукта и команды.

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

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

— Хун, мы рады, что ты на нашей стороне! А теперь блиц-опрос. Если бы тебе дали лишний день для тестирования выпуска Android, что бы ты сделал?

Хун: Если бы у меня был лишний день, я бы сделал еще одну сборку! Нет такого понятия — лишний день!

— Туше! Тебе есть о чем жалеть? Есть баг, который пробрался через канал выпуска к пользователю?

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

— Нет, ты так легко не отвертишься! Назови хотя бы один!

Хун: Ладно, был у нас баг с активными обоями (Active Wallpaper) несколько выпусков назад. Иногда при запуске обоев все просто падало. Решение было простым, а мы выдали его так быстро, что пользователь почти ничего не заметил. Но это нас не оправдывает. Мы написали тесты для этого случая, поверьте мне, мы их написали!

 

Интервью с Джоэлом Хиноски, тест-менеджером Chrome

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

Недавно мы встретились с Джоэлом и обсудили его представления о тестировании и опыт работы с Chrome и Chrome OS.

— Признавайся, на каком компьютере ты работаешь!

Джоэл (достает ноутбук): Chromebook — вот моя детка!

— Сколько еще гаджетов затерялось в твоем рюкзаке?

Джоэл: Ха! У меня в кармане сотовый телефон, а где-то рядом лежал планшет. Я использую свой Chromebook для работы, а когда он делает что-то не так, я сообщаю об ошибке. Надо пользоваться оборудованием, которое ты тестируешь!

— Итак, ты руководишь тестированием и управляешь полным спектром продуктов: панели инструментов, инсталлеры Chrome и Chrome OS и все, что работает на клиентской операционной системе (и сама операционная система), — твои зоны ответственности. Тебе приходится управляться с множеством команд разработчиков. Как ты сохраняешь баланс?

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

— Ты жонглер или осьминог? А если серьезно, какое место ты занимаешь в этой многоходовой комбинации?

Джоэл: Стараюсь быть практичным. Мне нужно выпустить программу, а для этого придется чем-то пожертвовать. Это всегда торги. Конечно, у нас гибкая система разработки, но все равно приходится делать обязательную финальную проверку качества (мы называем ее «последняя миля»). Мы проводим исследовательское тестирование, но все равно отслеживаем разные версии и платформы. Все относительно.

Не бывает универсальных моделей тестирования, даже внутри одной компании условия различаются. Пример: мои команды Chrome и Chrome OS используют разные процессы, хотя работают в одном здании! Может, одна команда лучше другой? Не думаю. Я помогаю командам обмениваться информацией о рабочих методах, что делает нашу работу по тестированию более производительной. Моя команда тестирования должна быть готова ко всему, знать, какие приемы работают, а если она сталкивается с неработающими методами, то должна легко от них отказываться. Пока я не разобрался со всем этим до конца, я предпочитаю использовать гибридный метод — сочетание тестирования разработчиками, сценарного тестирования, исследовательского тестирования, тестирования на базе оценки рисков и функциональной автоматизации.

— Кажется, на горизонте маячит еще одна книга по организации тестирования в Google.

Джоэл: Да, дайте мне год, и мы сравним объемы продаж или рейтинги на Amazon. Хотя какого черта, мы в Google — мы померяемся релевантностью!

— Ладно, вернемся к тестированию в Chrome и Chrome OS. В этой книге мы обсуждаем общую инфраструктуру тестирования Google для команд веб-приложений. Ты ведь работаешь в клиентском пространстве, твоя работа сильно отличается?

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

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

— Мы узнаем ребят, которых ты описал. А после того как команда была сформирована, какая проблема стала самой серьезной?

Джоэл: Сам веб! Серьезно, среда постоянно меняется, а Chrome обязан поспевать. Поток дополнений, расширений, приложений, версий HTML и Flash не прекращается. Количество переменных факторов зашкаливает, а ведь все они должны работать. Если мы выпустим браузер, который не отображает ваш любимый сайт или приложение, вам не придется долго искать альтернативный браузер.

Еще мы тестируем на разных операционных системах, но их не так много, а наша инфраструктура виртуализации упрощает процесс. Так что все проблемы, которые меня беспокоят, идут из веба.

— Да, разнообразие не на руку тестировщику. Мы понимаем, что ты будешь писать свою книгу, и не станем есть твой хлеб. Однако назови хотя бы две технологии или два решения, которые помогли тебе приручить веб.

Джоэл: Две? Хмм… Ладно, я назову совместимость приложений и автоматизацию пользовательского интерфейса, потому что в этих областях мы добились больших успехов. Все остальное я приберегу для следующей книги, той, более успешной!

Совместимость приложений очень важна для браузеров. Совместим ли Chrome с приложениями и сайтами в вебе? Правильно ли в Chrome отображаются страницы и запускаются веб-приложения? Разумеется, мы не можем проверить все приложения и сайты. И даже если бы могли, с чем их сравнивать? Мы отвечаем на эти вопросы, тестируя самые популярные сайты (в Google эту информацию не нужно долго искать) в контрольных версиях Chrome и браузерах конкурентов. Наши инструменты автоматически открывают тысячи сайтов и сверяют правильность их отображения. Мы делаем это для каждой ежедневной сборки, поэтому регрессии обнаруживаются очень быстро. Если сайт отображается иначе, сразу же подключается человек, чтобы найти, в чем проблема.

Впрочем, это только вершина айсберга. Нам еще было нужно уметь запускать сайты и приложения, а для этого нужны были средства автоматизации на уровне пользовательского интерфейса. Chrome поддерживает API, называемый Automation Proxy, который можно использовать для запуска браузера, открытия URL-адреса, проверки его состояния, получения информации о вкладках и т.д. Мы разработали для него интерфейс на Python, так что теперь можно написать скрипт для браузера на Python (этот язык знают большинство тестировщиков в Google). Так автоматизация функциональных тестов стала возможна, и мы создали большую библиотеку PyAuto, над которой работали и разработчики, и тестировщики.

— Ладно, ты победил Chrome. Так как Chrome OS — это тот же Chrome, только встроенный в ноутбук, его тестирование, наверное, было простым?

Джоэл: Можно подумать, если я тестирую Safari, то заодно тестирую и Mac OS? А если я протестировал IE, то и Windows летает? Ага, сейчас! Само существование Chrome OS только усложняет тестирование Chrome, потому что мне приходится добавлять еще одну платформу в список совместимости приложений.

И все же я скажу вам, что у нас все схвачено, и это очень круто. Google контролирует все в этой системе с самого низа, от компонентов, работающих с материнской платой, и поднимаясь наверх до пользовательских интерфейсов. Поэтому спускаясь обратно вниз, видишь много знакомого — многое перекликается с тестированием Chrome. Я могу использовать PyAuto и строю хорошие автоматизированные пакеты с возможностями повторного использования результатов команды Chrome. А потом начинается: прошивка, ядро, графический процессор, сетевой адаптер, беспроводной модем, 3G… Чего только нет в этих миниатюрных устройствах! Здесь уже сложнее применять автоматизацию. Это трудоемкие задачи тестирования, которые не работают при стандартном для Google соотношении количества разработчиков к количеству тестировщиков. Здесь нужно больше тестирования. Мы работали с этими системами со стадии прототипа, и нам даже приходилось монтировать электронные платы на картонных коробках.

Известные инструменты тестирования нашей системе не подходили. Chrome OS работает с открытым кодом и находится за рамками обычной системы разработки Google. Нам пришлось заново изобретать колесо (причем почти буквально) во многих тестовых инструментах, менять процессы с учетом особенностей новых инструментов и предоставлять эти инструменты внешним разработчикам. Мы выпускаем эту ОС для пяти разных платформ на трех каналах (разработчиков, бета, стабильном) с шестинедельным графиком. Если бы я не был австралийцем, я бы сошел с ума!

Итак, нам пришлось творчески решать задачи. Где мы можем переложить создание инструментов на разработчиков? Какой объем тестирования можно требовать от партнеров и производителей? Как обучить нашу команду эффективно тестировать оборудование? Что можно придумать, чтобы снизить нагрузку на ручное тестирование? И как это будет соотноситься с запуском на реальных устройствах?

— То, что ты начал отвечать вопросами, говорит о том, что нам придется ждать выхода твоей книги для получения ответов!

Джоэл: Да, придется ждать, потому что даже у меня нет всех ответов, и это моя работа — найти их. Мы в самом начале пути, нам еще нужно найти подход, гармонично сочетающий ручное тестирование с автоматизацией. Мы переработали Autotest (опенсорс-инструмент для тестирования ядра Linux) для управления большим набором автоматизированных тестов оборудования Chrome OS. Команда, работающая над этим, значительно расширила программу с учетом особенностей нашей платформы и внесла много изменений, причем все это в условиях открытого кода. В итоге Autotest выполняет наш цикл предстартовых тестов, смоук-пакет, а также тесты проверки сборки на реальном оборудовании и на виртуальных машинах. Конечно, мы не забываем PyAuto и с его помощью управляем автоматизацией тестирования браузера Chrome, работающего в Chrome OS.

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

Джоэл: Мы с Джеймсом давно работаем в одном офисе, и мы оба ревностно относимся к тестированию. Однажды мы объединили свои силы. Джеймс — очень общительный, часто выступает на конференциях, кажется, что он знаком со всеми. Круг его общения велик и работает на него. А на меня работает то, что я умею зажечь в людях интерес к тестированию. Это совершенно другой подход, как разница между везением и мастерством!

Конечно, это шутка, но я действительно ревностно отношусь к тестированию и поэтому готов нанимать только правильных кандидатов на роли инженеров Google. Например, найти людей для Chrome было непросто из-за тенденции бросать все силы на решение проблемы. Возникли неполадки с проверкой CR-48, Samsung Chromebook и новых экспериментальных платформ по трем каналам за неделю? Бросаем тридцать специалистов, пускай разбираются! Нужно проверить стабильную сборку Chrome S за двадцать четыре часа? С восемнадцатью ручными тестировщиками это будет легче легкого!

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Во время своей работы в Google ты работал над многими проектами, включая ключевой для компании проект поисковой системы. Что было самым трудным в его тестировании?

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

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

— С чего ты обычно начинаешь работу над новым проектом? Что делаешь в первую очередь? С точки зрения формирования команды? С точки зрения технической инфраструктуры? С точки зрения процесса тестирования?

Шелтон: Обычно мой первый вопрос к команде: «Что самое важное для тестируемой системы?». Для поиска важно быстродействие, для новостей — актуальность, для карт — покрытие. Каждое приложение стоит на своих китах. Тип системы помогает нам определить ее важные аспекты: целостность данных важна для хранилища, возможность масштабирования — для сетевых программ, возможность совместного использования — для систем управления проектами.

Определили важные части тестируемого продукта? Направляйте на их проработку основные силы. Несложными компонентами (типа доработки пользовательского интерфейса и прочей мишуры) можно заняться после. Сосредоточьтесь на базовых атрибутах продукта, которые трудно изменить, и не тратьте много времени на вещи, которые изменяются легко. Например, если тестировщик рано начал заводить баги, пойманные в шрифтах, я решу, что он неправильно расставил приоритеты.

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

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

Должен сказать, что ручное тестирование тоже в чем-то уникально. В области мобильных приложений, например. Изобилие оборудования, экранов, форм-факторов и драйверов порождает разнообразие в отображении и визуализации. Нам приходится тестировать эту область вручную. Но мы все равно стараемся автоматизировать и этот процесс, насколько это возможно. Пусть машина выполнит 90% работы, а человеческие ресурсы мы подключим только на последних 10% цикла проверки, которые мы называем «последней милей». Автоматизация может сделать снимки экранов устройств, а человек быстро проверит различия в изображениях, найденные алгоритмом. Человеческий разум слишком ценен, чтобы тратить его на то, с чем справится компьютер. Оставьте однообразные задачи машинам, человек нам еще пригодится.

— Опиши баг, который ускользнул от вас и заставил краснеть после выпуска.

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

— Как вы определили, какие тесты конфигураций нужно автоматизировать?

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

 

Интервью с директором разработки инженерных инструментов Ашишем Кумаром

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

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

— Область автоматизации в Google кажется чем-то магическим, во многом благодаря GTAC, а ты — человек, который за всем этим стоит. Приоткрой нам завесу тайны, какие возможности предоставляет твой инструментарий инженерам Google?

Ашиш: Команда разработки инженерных инструментов, а именно так мы называемся, отвечает за создание 90% инструментов, ежедневно используемых разработчиками Google, когда они пишут, собирают и выпускают качественные приложения. Последние 10% мы охватим, когда сможем поддерживать все команды, работающие с открытым кодом.

Google уникален тем, что огромное внимание уделяется созданию мощной и масштабируемой инфраструктуры для разработчиков. Люди извне обычно знакомы с технологиями MapReduce и BigTable, которые наши разработчики постоянно используют. Но наша внутренняя инфраструктура для разработки — это тоже большая часть нашей работы.

— Можно конкретнее?

Ашиш: Ладно, сами напросились! Набор инструментов включает:

— Инструменты для работы с исходным кодом. Они упрощают создание рабочих пространств, заливку изменений в код и соблюдение гайдлайнов. Эти инструменты помогают просматривать сотни миллионов строк кода и дают удобный поиск для предотвращения дублирования. Они делают возможным индексирование и рефакторинг в облаке.

— Инструменты разработки. Это плагины для IDE, которые приспосабливают инструменты к коду Google и связывают их с нашими облачными сервисами. Эти инструменты помогают быстро и качественно рецензировать код благодаря возможности встроенных сигналов во время код-ревью.

— Инфраструктура сборки. Эта система позволяет нам распределить сборку мультиязычного кода по десяткам тысяч процессоров, используя такие объемы памяти и дискового пространства, что мне даже представить страшно! Система сборки работает как для интерактивного, так и для автоматизированного использования. Она формирует результаты за секунды, хотя та же работа в другом случае занимала бы часы.

— Инфраструктура тестирования. Это масштабная непрерывная интеграция. Это означает ежедневное выполнение миллионов тестовых пакетов по каждой заливке кода разработчиками. Наша цель — предоставить мгновенную (или почти мгновенную) обратную связь для каждого разработчика. У этого есть и другая сторона: нужно масштабировать веб-тестирование. Для тестирования продуктов Google каждый день запускаются сотни тысяч браузерных сессий с разными сочетаниями браузеров и платформ.

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

— Метрики, графики и отчеты. Здесь речь об управлении багами по всем продуктам Google, сборе и хранении метрик разработки, тестирования и выпусков. Наша задача — предоставлять командам обратную связь, чтобы они могли улучшить свою работу.

— Значит, ты одновременно работаешь на всех фронтах. Чтобы достичь такого успеха, вы наверняка добавили много инноваций в рабочий процесс. Как вам удается сохранять баланс между новыми разработками и профильной работой? Ведь твоя команда не такая уж большая.

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

Мы много экспериментируем. Чтобы добиться большого успеха в следующем году, нужно работать уже сейчас, поэтому несколько небольших команд по одному-два человека всегда работают над экспериментами. Часто опыты проходят в «двадцатипроцентное» время, и я не против, так как это личное время инженеров, которым они вольны распоряжаться. Разумеется, часть экспериментов провалится, но те, которые приведут к успеху, с лихвой компенсируют любые неудачи. Мечтайте о большом, быстро понимайте, если идете не туда, и не сдавайтесь!

Некоторые инструментальные проекты не самодостаточны, поэтому сложно измерить их влияние, но они все должны давать ощутимый толчок в сторону увеличения производительности Google.

— А была ли идея, которая казалась тебе неудачной, но привела к успеху?

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

— А есть ли инструмент, который обещал быть успешным, но провалился?

Ашиш: Снова да! Удаленное парное программирование. В Google много распределенных команд. Многие команды применяют парное программирование и другие гибкие методы разработки. Часто бывает, что вы работаете над кодом, который написал человек из другого офиса, и если у вас появляются вопросы, то возникает задержка, влияющая на производительность.

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

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

— Твой совет компании, которая хочет построить непрерывный процесс автоматизации? С каких инструментов стоит начать?

Ашиш: Самое важное — создать такую среду разработки, чтобы в ней даже разработчик-новичок смог работать с вашей командой. Должно быть невероятно просто взять код из репозитория, отредактировать, протестировать, отладить его и опубликовать. Если вы сформируете настолько удобную среду, то все ваши разработчики будут работать более продуктивно и вы сможете выпускать ваше ПО без задержек.

Как создать такую среду? Нужно четко определить зависимости, сделать их явными и создать систему непрерывной интеграции, которая делает свое дело. Главное, чтобы она быстро предоставляла информацию разработчикам. Если на получение обратной связи уходит больше пары минут, добавьте еще машин. Время процессора стоит гораздо дешевле рабочего времени инженера. Запустить, отладить или развернуть код должно быть так же просто, как ввести команду. Если вы работаете в веб-компании, упростите процедуру частичного развертывания.

— Какие инженеры нужны в твоей команде? Вряд ли любой разработчик сможет разрабатывать инструменты?

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

— Раз уж мы заговорили о пользователях, как ты убеждаешь людей применять твои инструменты?

Ашиш: Разработчики Google — это очень благодарные пользователи. Раз в неделю мы проводим встречи и демонстрируем наши инструменты. Инженеры приходят, задают вопросы, и если инструмент решает их задачи, они берут его на пробу. На инструменты, которые решают насущные проблемы, довольно большой спрос. Чем ближе к реальности, тем эффективнее. Надо быстро отказываться от проектов, которые нерезультативны или не востребованы.

— А тебе когда-нибудь попадались инструменты, которые только мешали работе или приносили больше вреда, чем пользы?

Ашиш: Да, но я даже не запоминаю их, так как все подобные проекты очень быстро забрасываются. Цель разработки инструментов — автоматизация процесса и его упрощение. Не нужно автоматизировать неправильные решения. Если разработчик совершает ошибку, зачем упрощать ему этот процесс? Отступите на шаг и оцените: может быть, нужно заняться чем-то более полезным.

— Над чем сейчас работаешь? Какие новые инструменты готовит твоя команда?

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

 

Интервью с Суджаем Сани, директором по тестированию в индийском Google

Мы привлекаем талантливых людей в разных странах через распределенную систему офисов, создавая региональные и глобальные центры разработки Google. В Индии было много способных инженеров, поэтому наш первый глобальный центр тестирования появился именно там, в Хайдарабаде. Сотрудники центра работают над ключевыми продуктами Google, и это помогает переходу от ручного тестирования (служба тестирования, вы помните?) к инженерному тестированию. Суджай Сани — директор по тестированию, который основал и возглавил направление продуктивности разработки в Индии.

— Индия находится далеко от главного офиса Google в Маунтин-Вью. Почему именно здесь появился столь важный технический отдел?

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

Из регионального офиса мы выросли в глобальный центр. Сейчас Хайдарабад — это центр Азиатско-Тихоокеанского региона Google, офис в Цюрихе — европейского, а в Нью-Йорке — центр Восточного побережья США. Центры объединяют и организовывают работу более мелких офисов Google в своем регионе, они помогают экономить время и распределять ресурсы.

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

— Какую роль сыграл индийский офис в эволюции тестирования Google?

Суджай: Как я уже говорил, наш региональный центр стал первым. Хотя мы открыли офис в Бангалоре, хайдарабадский центр (или сокращенно HYD) быстро стал глобальным хабом инженерных подходов к тестированию. С самого начала в HYD работали и инженеры по тестированию, и разработчики в тестировании, и большое количество временных и внешних сотрудников. Они занимались самыми значительными продуктами Google: Search, Ads, Mobile, Gmail, Toolbar и другими. В первую очередь они разработали инфраструктуру тестирования и фреймворк для автоматизации тестирования, чем сильно ускорили выпуск продуктов. В 2006–2007 годах в команде HYD работала примерно половина всех разработчиков в тестировании в Google. Говорят, что роль разработчика в тестировании укрепилась в результате усилий первого тестировщика, нанятого в HYD. Не знаю, правда это или нет, но мы сделали возможной трансформацию службы тестирования в направление продуктивности разработки.

К концу 2007 года мы бросили все силы на развитие команды в новых областях, уменьшение фрагментации команд и создание зрелого сообщества сильных инженеров, чтобы справиться с растущим количеством новичков. В начале 2008 года мы сами стали открывать региональные центры тестирования, чтобы команды разработки могли работать бок о бок с локальными командами тестирования. Теперь мы могли начать работать с до сих пор нетронутыми областями. У нас дошли руки до продвинутых средств обнаружения задержек, инструментов контроля производительности и стабильности клиент-серверных и облачных систем, механизмов выявления деградации и средств клиентского тестирования.

Тогда же произошло еще одно изменение — мы начали вкладывать время и ресурсы в облачное тестирование и инфраструктуру инженерных инструментов. Мы работали над проектами Cloud Code Coverage, Cloud Scalable Test Infrastructure, Google Toolbox, разными IDE и другими экспериментами, большинство из которых в итоге стали боевыми инструментами. Наша команда не только разрабатывала нужные инструменты для инженеров Google, но и создавала основную инфраструктуру для внешних разработчиков, работающих с открытым кодом. Инженеры из HYD работали над App Engine, Selenium, плагинами Eclipse, IntelliJ и другими проектами опенсорс-сообщества.

— Все это хорошие, важные проекты. А ты можешь привести пример проекта, целиком выполненного в HYD?

Суджай: Да. Например, программа Google Diagnostic Utility была полностью разработана в Хайдарабаде. С ее помощью наша служба поддержки работает с пользователями по диагностике проблем, которые у них возникают с продуктами Google. Эта программа упрощает получение технических подробностей систем и железа пользователя.

Есть и другие примеры. Наш отдел сосредоточен на разработке инженерной инфраструктуры, инструментов и тестов для всего Google. Для разработчиков мы создаем среду разработки, основную облачную инфраструктуру для компилирования, тестирования и измерения покрытия кода, делаем возможным любой статический анализ. Для тестировщиков мы разрабатываем систему для анализа нагрузки и производительности облачных сервисов Google, а еще создаем инструменты тестирования для таких важных продуктов, как Search, Enterprise, Gmail и Ads.

— Давай поговорим об этих инструментах. Даже названия звучат интересно. Ты упомянул инструмент, который измеряет покрытие кода, расскажи о нем подробнее. Эта тема очень популярна в блоге Google Testing.

Суджай: Покрытие кода — это метрика, которая показывает эффективность тестов для кода проекта. В традиционном подходе каждая команда должна выделить отдельные ресурсы (инженерные, аппаратные и программные) для измерения этого покрытия. А в Google есть специальная группа людей, находящаяся в Индии, которая следит за тем, чтобы все инженерные команды легко получали свои метрики покрытия кода. Для этого команда должна потратить всего пять минут, чтобы один раз настроить эту функциональность. После настройки у них будут все метрики проектов и сборок с централизованной системой просмотра и анализа отчетов.

Измерение покрытия поддерживается для тысяч проектов, всех основных языков программирования и миллионов файлов с исходным кодом. Инфраструктура покрытия интегрирована с облачной инфраструктурой Google для компилирования и сборки кода. Она масштабируется для постоянных изменений кода (происходящих ежеминутно!) и десятков тысяч сборок в день. Инфраструктура способна меняться вместе со стремительно растущей кодовой базой Google.

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

— Похоже, это правильный подход к покрытию кода. А теперь расскажи о приложении Diagnostic Utility, которое ты упоминал.

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

Чтобы разобраться в проблеме пользователя, иногда нужны определенные технические данные. Это могут быть простые данные, которые клиент может предоставить (например, версия ОС), но бывает, что требуются подробности о версиях и конфигурациях приложений, поиск которых ставит пользователя в тупик.

Приложение Diagnostic Utility решает эту проблему. Теперь, когда службе поддержки нужна дополнительная информация о системе пользователя, они создают новую конфигурацию для этой утилиты, где перечисляют, какая информация требуется. Дальше пользователь получает по почте или скачивает с сайта поддержки небольшой (около 300 Кбайт) исполняемый файл, подписанный сертификатом Google. Этот файл диагностирует машину пользователя, собирает указанные в конфигурации данные и показывает их пользователю, чтобы он подтвердил их отправку в Google. Приложение хорошо воспитано — после отправки данных оно прибирает за собой и удаляется. Мы заботимся о конфиденциальности, поэтому все собранные данные отправляются только с согласия пользователя.

Служба поддержки пересылает данные разработчику для отладки. Приложение Diagnostic Utility делает работу команд клиентских приложений (например, Google Chrome и Google Toolbar) проще, а самому пользователю облегчает процесс получения технической поддержки.

— Ты пару раз упоминал тестирование нагрузки и производительности. Что здесь интересного расскажешь? Насколько мы понимаем, ваша команда активно участвует в тестировании производительности Gmail?

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

Наше решение состоит из трех частей:

— Предварительные тесты. Инженеры могут проводить тесты и измерять задержки перед отправкой изменений в коде в репозиторий. Это ускоряет обратную связь и снижает вероятность попадания багов в кодовую базу.

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

Оказывается, есть социальные факторы тестирования, которые гораздо сложнее, чем любые технические. Все понимают, что нужны хорошие тесты, но многим менеджерам трудно заставить команды их писать. Лучшее средство для мотивации — соревнования. Хотите получить больше малых тестов? Сравните свою команду с другой. Эй, у той команды тестовое покрытие — 84%, а полный набор тестов выполняется за пять минут! И мы позволим им обыграть нас?!

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

— Это объясняет твое участие в Google Feedback. Можешь немного рассказать о нем? Какие проблемы должен решать этот продукт?

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

— Можешь рассказать, как работает Google Feedback?

Брэд: Feedback собирает всю возможную информацию, соблюдая конфиденциальность пользователя. Браузер, операционная система, плагины — все эти данные очень важны для отладки и легко собираются программой. Особенная хитрость со скриншотами. В целях безопасности браузеры не копируют изображение своего содержимого. Нам пришлось заново реализовать механизм визуализации на JavaScript безопасным путем. Теперь мы делаем скриншот и просим пользователя выделить на нем проблемную область. Потом мы просим его описать проблему текстом. Невозможно научить пользователей создавать идеальные баг-репорты, но со скриншотами расплывчатые описания становятся яснее.

— Разве с таким количеством пользователей вы не будете получать сообщения об одном и том же баге?

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

— Сколько человек в команде Google Feedback?

Брэд: В команде 12 разработчиков и три менеджера. Последних, конечно, больше, чем обычно, но здесь это оправданно, так как нужно координировать много проектов, связанных с Google Feedback.

— Какие самые серьезные проблемы возникали при запуске Google Feedback?

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

— Какое будущее ждет Google Feedback? Возможно ли, что когда-нибудь система станет доступной не только для сайтов Google?

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

— Каким ты видишь следующий шаг в развитии тестирования программных продуктов?

Брэд: Мне бы хотелось увидеть среду разработки, в которой тестирование — первостепенная фича, а не прикрученная позже. Представьте, что язык, библиотеки, фреймворки и инструменты сами знают, какие тесты будут нужны вашему коду, и помогут вам их написать. Это будет круто. А пока нам приходится прилеплять тестовые фреймворки к разработке. Тесты трудно писать и тяжело сопровождать, они нестабильны во время выполнения. Я думаю, что если мы будем выпекать наши тесты на самом низком уровне, это принесет нам много плюшек.

— У тебя есть какой-нибудь компромат на доктора Джеймса Уиттакера, о котором ты бы хотел поведать миру?

Брэд: Кроме того инцидента с костюмом бедняжки Мэри? Пожалуй, нет. Мы, менеджеры, своих не сдаем!

 

Интервью с Джеймсом Уиттакером

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

Джейсон Арбон и Джефф Каролло поговорили с Джеймсом в его офисе.

— В 2009 году ты перешел в Google из Microsoft. Когда ты объявил в своем блоге о том, что уходишь из Microsoft, почему ты не назвал новое место работы? Зачем эта таинственность?

Джеймс: Сразу такой жесткий вопрос? Ого! Мне обещали, что будет просто!

— А ты обещал ответить на наши вопросы, так что давай!

Джеймс: Это был самый простой способ оповестить максимальное количество людей одновременно. Тогда Twitter еще был не очень популярен, и я воспользовался блогом MSDN. Оказывается, коллеги чаще читали мой блог, чем мои электронные письма. Уход из Microsoft немного пугал, и я хотел высказаться один раз, но громко и доступно, чтобы избежать сотни прощальных встреч. Так что это было лучшее решение.

Люди, которые были в курсе моего увольнения, потратили уйму времени, отговаривая меня. Тяжело было уходить из компании, в которой нравилось работать. Трудно было расставаться с людьми, с которыми работал вместе годами. Я чувствовал себя ужасно в связи с уходом, и мне не хотелось повторно обдумывать мое решение. Мне нравится Microsoft, и я уважаю инженеров, которые здесь работают. На самом деле меня действительно могли отговорить от перехода, но я очень хотел работать в Google и в то же время не хотел давать коллегам возможности повлиять на мое решение.

— Почему? Что такого в Google так сильно тебя привлекало?

Джеймс: Знаешь, это может прозвучать странно. Я начинал как профессор-консультант, потом открыл свой бизнес и успел попробовать все, кроме работы в большой компании. И раз уж я решился на работу в большой компании, пусть она будет самой большой! Чем больше, тем лучше! Чем круче работа, тем лучше! Чем больше аудитория, тем интереснее! Я хотел понять, насколько успешным я могу стать в отрасли, так почему бы не проверить это в лидирующей компании? Так я оказался в Microsoft, а потом в Google. Я хочу работать в больших компаниях и выбираю из них лучшие.

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

Собеседования только подкрепили мое мнение. Я встречался с Патриком Коуп­лендом, Альберто Савоя, Брэдом Грином, Шелтоном Маром, Марком Стрибеком и многими другими. Наши разговоры были потрясающими. Мы с Альберто изрисовали целую доску во время интервью. Только потом он заметил, что забыл задать мне необходимые для собеседования вопросы. С Шелтоном мы разошлись во взглядах, но он настолько уважительно принял мое мнение, что это произвело на меня большое впечатление. Сейчас мы соглашаемся с ним гораздо чаще! А Брэд? Он был крут. Во время собеседования на нем не было обуви (а это был февраль), и это только добавило нашему разговору непринужденности. Марк большую часть собеседования уламывал меня перейти в Google. Атмосфера просто-таки фонтанировала идеями. У меня голова шла кругом.

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

— И мы оправдали свою репутацию?

Джеймс: О да, работа оказалась непростой. Но я думаю, вопрос скорее об увлеченности? Честно говоря, и в Microsoft хватает умных и увлеченных тестированием людей. Разница в том, что в Google проще реализовывать свои увлечения. Мы с Альберто никогда не числились в одной команде, но легко работали вместе в «двадцатипроцентное» время. С Брэдом, например, мы до сих пор работаем вместе над средой разработки и автоматизацией баг-репортов (Брэд через Google Feedback, я через BITE). Google хорош тем, что дает возможности для такого сотрудничества и поощряет это.

— Мы работаем с тобой в Киркленде и заметили, насколько отличается темп твоей здешней команды и ее общий настрой. В чем твой секрет?

Джеймс: Да, сейчас в Киркленде дела идут гораздо лучше, но это не только моя заслуга. Частично дело в критической массе правильных людей. Как раз перед моим приходом наняли много талантливых специалистов, и за первые несколько кварталов наш штат тестировщиков стал в четыре раза больше. Я смог строить большие команды и объединять людей, занимающихся похожей работой, даже если они работали над разными продуктами. Теперь вместо одного тестировщика в команде разработки появилась группа специалистов, которые сотрудничали друг с другом и делились идеями. Такая схема творит чудеса и с настроением команды, и с ее производительностью.

Так как у меня было достаточно людей, я смог снять ветеранов вроде вас двоих с текущих проектов, заняв более серьезными задачами. Джефф тогда занимался реализацией очереди предварительной отправки для Google Toolbar, а Джейсон тестировал Google Desktop. Какое глупое использование ваших талантов! Поделюсь секретом хорошего менеджера: подберите каждому человеку идеальную для него задачу — и ваша работа сделана. Люди счастливы, и проекты делаются лучше. Правда, эта роскошь стала доступной только благодаря тому, что к моему приходу набралась критическая масса сотрудников.

Еще один плюс большого количества сотрудников — стало больше людей, которые могут тратить свое «двадцатипроцентное время» на эксперименты. Мне удалось собрать команды на несколько рискованных проектов. Мы начали с инструментов и опытов, которые не имели отношения к выпуску программных продуктов, скорее мы просто делали то, что нам было интересно. Оказалось, что ничто так не воодушевляет тестировщиков, как разработка инструментов. Честно говоря, наверное, это самая приятная часть работы. Наверное, в душе я больше разработчик инструментов, чем тестировщик.

— Что тебе больше всего нравится в организации работы Google?

Джеймс: Командная игра. Я твержу об этом кандидатам, когда хочу убедить их работать у нас: тестировщики рапортуют тестировщикам и сами определяют свою судьбу — это то, что я больше всего люблю в Google. Тестировщики сами нанимают сотрудников, сами проводят собеседования, сами решают, кого повышать. ООН признала нашу Республику Тестирование независимым государством!

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

— Долго ты привыкал к культуре Google? Ведь ты пришел из Microsoft, где не было централизованной организации тестирования?

Джеймс: В начале моей работы Пат Коупленд дал мне два совета. Первый — просто изучи обстановку. Это было критически важно. Нужно время, чтобы разобраться в том, как работает большая компания. Чтобы успешно работать в Google, нужен другой набор навыков, не такой, как в Microsoft. Так что первые пару месяцев я следовал совету Пата — только слушал и задавал вопросы. Кажется, я даже продлил себе период адаптации на пару недель.

— А второй совет?

Джеймс: Да, извини, увлекся. Иногда Пат говорит умные вещи, и, кажется, мне попалась как раз такая. Второй совет мне совсем не понравился, но оказался еще полезнее первого. Пат отвел меня в сторонку и сказал: «Слушай, парень, я знаю, что у тебя есть репутация за пределами Google, но внутри ты еще ничего не сделал». Пат — человек прямой, и в разговоре его сложно понять неправильно. И я осознал — Google не было дела до того, чем я занимался до прихода сюда. Чтобы состояться именно здесь, я должен сделать что-то внутри компании. Нельзя заслужить уважение в Google, просто прогуливаясь и насвистывая. Пат предложил мне взяться за большой проект и удачно завершить его, да еще и так, чтобы это было заметно. Я выбрал Chrome и Chrome OS и стал там первым менеджером по тестированию. Проект был выпущен, и я передал его одному из своих ребят.

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

— Кроме тестирования продуктов, какими направлениями ты занимался по совету Пата?

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

— И что же ты сделал для инженеров по тестированию?

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

Рабочая команда много сделала для определения роли инженера по тестированию. Например, мы переписали рекомендации по карьерному продвижению. Мы выдвинули новый вариант карьерной лестницы на открытое голосование всего сообщества инженеров по тестированию в Google, и ее приняли. Это было здорово — я даже выписал премию всей рабочей группе, чтобы отпраздновать это событие. Наши идеи исходили «снизу», от людей, работающих в специальности, и поэтому принимались легко. Мы написали рекомендации по проведению интервью и разослали их рекрутерам и инженерам, участвующим в собеседованиях. Я думаю, что сейчас роль инженеров по тестированию определена так же четко, как и роль разработчика в тестировании.

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

Джеймс: Рецепт такой: возьмите высокую квалификацию тестировщиков, добавьте дефицит человеческого ресурса (который заставляет разработчиков помогать, а тестировщиков — оптимизировать), первым делом автоматизируйте (чтобы люди делали только то, в чем компьютеры не сильны), введите способность работать итеративно и быстро внедрять изменения после обратной связи от пользователей. Смешать, но не взбалтывать! Любая компания, которая захочет воспроизвести нашу организацию тестирования, должна начать с этих четырех ингредиентов.

— Как насчет другой книги? У тебя уже задумана следующая книга по тестированию?

Джеймс: Не знаю, я ведь никогда не планирую книги заранее. Моя первая книга родилась из курсовых заметок, которые я использовал для преподавания тестирования в Политехническом университете Флориды. Однажды после презентации на конференции STAR ко мне подошла женщина и спросила, не думал ли я о написании книги. Вопрос оказался с подвохом, так как она была книгоиздателем. Так родилась серия «How to Break Software». Я написал первую книгу сам до последнего слова и был сильно утомлен процессом, поэтому решил больше не писать в одиночку. Над следующими двумя книгами я работал с соавторами. Хью Томпсон написал книгу «How to Break Software Security», Майк Эндрюс написал «How to Break Web Software», а я помогал им обоим. Это действительно их книги. Я всего лишь написал часть материалов и управлял процессом. Мне нравится писать, но ни Хью, ни Майк не стали бы смущать меня, утверждая, что я пишу лучше, чем они. А вы двое? Я так не думаю. Но факт в том, что без меня никто бы не решился писать. В конечном итоге все, что происходит в моей карьере, заканчивается книгой, а окружающие меня люди становятся соавторами. Будете отрицать?

— Вообще-то читатель сейчас держит в руках доказательство твоих слов. Как тут поспоришь!

Джеймс: Не буду говорить, что я совсем не могу писать в одиночку. «Exploratory Testing» — книга, которая была написана без соавторов. Она появилась из презентаций, которые я проводил на конференциях. Я создал тонну материалов, и со временем их накопилось достаточно на книгу.

А за эту книгу я бы вряд ли взялся, если бы вы двое не согласились помочь. Впрочем, это моя первая книга, которая по-настоящему писалась коллективно. На мой взгляд, каждый из нас внес равный вклад.

— Да, это так, и мы были очень рады возможности поучаствовать. Возможно, в программировании мы сильнее тебя, а Джефф вообще круче всех на этой планете, но ты умеешь создавать легко читаемый текст! Скажи, какая часть книги тебе нравится больше всего?

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

— А чем бы ты занимался, если бы не попал в тестирование?

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

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

— А если бы пришлось работать за пределами технологической области?

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

Да, и я люблю пиво. Я очень люблю пиво. Когда-нибудь я бы мог сыграть Норма из сериала «Cheers». Могу себе представить: я вхожу в бар, все кричат: «Джеймс!», а тот, кто занимает мой табурет, уступает мне место.

Вот это я называю хорошо сделанной работой. Пожалуй, я бы выписал премию Норму из чистого уважения.