— Старший директор по тестированию (Senior Test Director). Такой человек у нас один — Патрик Коупленд. Он отвечает перед высшим руководством компании за единообразие должностных инструкций, найм, внешние взаимодействия и общую стратегию тестирования в Google. Это его работа — распространять передовые практики, создавать и продвигать новые начинания, например инфраструктуру глобальной сборки или тестирования. Статический анализ и задачи по тестированию, которые касаются всех продуктов Google, пользовательские проблемы и база тестового кода — все это лежит в ответственности старшего директора по тестированию.
Большинство тех, кто работает в тестировании в Google, особенно директора и даже сам Патрик Коупленд, участвуют в поиске и наборе людей. Есть несколько подводных камней, на которые мы натыкаемся во время собеседований. Например, большинство кандидатов отлично знают компанию, ее основные технологии и то, что это отличное место для работы. Инженеры очень осторожны на собеседовании: они опасаются показать свое волнение и не пройти отбор. Хорошие кандидаты и так работают в хороших условиях, и их беспокоит сильная конкуренция внутри Google. Часто можно развеять все опасения, если интервьюер представится и расскажет немного о себе. Инженеры в Google, безусловно, профессиональные и воодушевленные. И все же большая часть того, что заставляет их работу выглядеть такой интересной и даже героической, — это просто грамотное использование коллективного разума сообщества инженеров-единомышленников и технических мощностей Google.
У нас есть и процесс внутреннего подбора людей. Инженеров поощряют менять проекты, поэтому движение между командами есть всегда. Если команде нужны люди, ей нужно рассказывать всем о том, почему у них круто работать. Большинство внутренних перемещений — результат личного общения, когда инженеры обсуждают интересные проекты, технические проблемы и общую атмосферу в команде. Иногда проводятся полуформальные встречи, на которых команды, желающие привлечь инженеров, показывают, над чем они работают. Но по большей части внутренний набор людей в команды — процесс очень естественный и гармоничный. Люди просто могут перейти туда, где они хотят работать и где, как им кажется, их работа принесет наибольшую пользу.
Давайте отметим основные аспекты работы руководителей тестирования.
— Технический момент. Тест-менеджеры и особенно ведущие инженеры должны быть технически сильными. Им придется писать прототипы, проводить код-ревью. Они всегда должны стремиться узнать продукт и пользователей лучше, чем все остальные участники команды.
— Переговоры. Невозможно постоянно заниматься только тестированием. Руководители разработки постоянно требуют ресурсов и внимания тестирования, поэтому тест-менеджеры должны уметь вежливо и обоснованно отказывать.
— Внешние коммуникации. Менеджерам доводится работать с внешними исполнителями, нанятыми для временной работы в проекте или для тестирования продуктов извне. В зоне их ответственности организация мероприятий для обсуждения и обмена новыми инженерными практиками в области тестирования с широкой публикой. Живой пример тому — конференция GTAC.
— Стратегические инициативы. Менеджмент тестирования часто спрашивают, что еще такого можно сделать в Google, чего нельзя сделать нигде больше? Как мы можем расширить свою тестовую инфраструктуру и поделиться ею, чтобы улучшить интернет в целом, а не только наш продукт или компанию? Что будет, если мы объединим наши ресурсы и возьмемся за долгосрочные проекты? Поддержка таких инициатив идеями, финансами и защитой от натиска команд, желающих срочно заполучить тестировщика, — это работа, требующая огромной отдачи.
— Аттестация и оценка персонала. Чтобы оценивать своих сотрудников, менеджеры в Google опрашивают всех участников команд. Результаты сравнивают между командами, чтобы выровнять их. Всех сотрудников Google оценивают раз в квартал. Мы делаем упор на то, что человек сделал за последнее время и как он повлиял на качество продукта, что он сделал для команды и для пользователей.
Наша система аттестации не позволяет сотруднику выезжать на прошлых успехах, важно постоянное развитие. Механика оценки эффективности все еще формируется, поэтому мы не будем подробно ее описывать. В общих чертах: сотрудники Google составляют краткое описание того, над чем они работали и как хорошо, по их мнению, они справились. Их коллеги и начальство добавляют комментарии, а затем на собраниях независимых комиссий проводится оценка и согласование результатов между командами. Мы ожидаем, что наши сотрудники Google будут ставить себе цели выше, чем они считают возможным достичь. Поэтому если сотрудник выполнил все намеченное, значит планка была не так уж высока.
Оценивая людей таким способом, мы выявляем и поддерживаем ребят, которым пора сменить специализацию на более подходящую. Перемещения происходят постоянно и во всех направлениях. Чаще всего инженеры по тестированию переходят в разработчики в тестировании, а разработчики в тестировании — в разработчики. Ребята прокачиваются технически и специализируются на своих новых интересах. На втором месте — перемещения из роли разработчика в тестировании на роль инженера по тестированию и из роли инженера по тестированию на роль руководителя проекта. Это легко объяснить тем, что людям надоедает целыми днями программировать и хочется расширить поле деятельности.
Руководители помогают людям устанавливать ежеквартальные и годовые OKR.[46] Они следят за тем, чтобы цели ставились высокие и амбициозные, поощряют людей метить высоко даже при краткосрочном планировании. Менеджеры следят, чтобы цели отвечали способностям и интересам инженеров и не конфликтовали с требованиями проекта и бизнеса.
Управлять тестированием — значит находить компромиссы и прислушиваться к каждому человеку. Управлять в Google — значит направлять и опекать своих людей, а не командовать ими. Возвращаясь к аналогии с пиратами: хороший руководитель обеспечивает семь футов под килем и попутный ветер.
Тестирование в режиме сопровождения
Google известен своими ранними и частыми выпусками, а еще — стремлением понять, что проект провальный, как можно быстрее. Поэтому мы можем срочно перебросить ресурсы на проект с наибольшими рисками. Что это значит для тестировщика? Фичи, над которыми он работает, а иногда и целые проекты могут потерять приоритет или полностью свернуться. Как с технической, так и с эмоциональной стороны инженер должен быть готов к этому. Да, возможно, вам придется бросить все, когда вы только что расставили все по полочкам, и начать сначала. Это не самые приятные моменты, и изменения могут обернуться высокими рисками и затратами, если действовать неосторожно.
Пример режима сопровождения: Google Desktop
Джейсон Арбон
На середине очередного проекта мне предложили взяться за колоссальную задачу тестирования Google Desktop с десятками миллионов пользователей, клиентскими и серверными компонентами и интеграцией с поиском Google. Я стал последним в длинном списке тест-лидов этого проекта с типичными проблемами качества и техническим долгом. Проект был внушительным, но, как и в большинстве проектов такого объема, наращивание функциональности постепенно замедлилось, а за несколько лет тестирования и использования сократились и риски.
Когда мы с двумя коллегами-тестировщиками влились в работу над проектом, у Google Desktop уже было около 2500 тест-кейсов в старой базе данных Test Case Manager, а несколько старательных подрядчиков в хайдарабадском офисе прогоняли эти тест-кейсы для каждого выпуска. Циклы прохождения тестов часто занимали по неделе и больше. Раньше уже были попытки автоматизировать тестирование продукта через пользовательский интерфейс, но они не удались из-за сложности проекта и их затратности. Управлять веб-страницами и пользовательским интерфейсом окна рабочего стола через C++ было непросто, постоянно возникали проблемы с задержками.
Моими коллегами-тестировщиками были Теджас Шах и Майк Мид. Тогда в Google ресурсы клиентского тестирования были ограничены. Так как большинство продуктов уже работало в веб или быстро туда переходило, мы решили взять фреймворк тестирования на Python, который разработали для Google Talk Labs Edition. Он управлял продуктом через веб-модель DOM. В этом простом фреймворке были реализованы основные средства — например, класс тест-кейсов, производный от PyUnit. Многие тестировщики и разработчики знали Python, так что у нас была стратегия выхода на всякий случай. А если бы что-то сломалось, многие другие инженеры могли помочь. Кроме того, Python прекрасно подходит для итеративной разработки маленьких фрагментов кода без компиляции. В Google он устанавливается на рабочие станции инженеров по умолчанию, так что весь тестовый пакет мог быть развернут одной командной строкой.
