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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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