Уиттакер . - Как тестируют в Google

Давайте отметим основные аспекты работы руководителей тестирования.

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

— Переговоры. Невозможно постоянно заниматься только тестированием. Руководители разработки постоянно требуют ресурсов и внимания тестирования, поэтому тест-менеджеры должны уметь вежливо и обоснованно отказывать.

— Внешние коммуникации.Менеджерам доводится работать с внешними исполнителями, нанятыми для временной работы в проекте или для тестирования продуктов извне. В зоне их ответственности организация мероприятий для обсуждения и обмена новыми инженерными практиками в области тестирования с широкой публикой. Живой пример тому — конференция GTAC.

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

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

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

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

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

Управлять тестированием — значит находить компромиссы и прислушиваться к каждому человеку. Управлять в 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 он устанавливается на рабочие станции инженеров по умолчанию, так что весь тестовый пакет мог быть развернут одной командной строкой.

Мы с ребятами решили применить весь диапазон возможностей Python API для управления продуктом. Мы использовали ctype для управления COM API на стороне клиента для поиска, мы моделировали ответы сервера для тестового внедрения локальных результатов в результаты google.com (нетривиальная задача!), работали с множеством библиотечных функций, чтобы имитировать пользователя и воссоздать его путь в приложении. Мы даже построили систему виртуальных машин для автоматизации тестов, которым нужны индексы Google Desktop. Иначе нам пришлось бы несколько часов ждать завершения индексирования на новой установке. Мы сформировали небольшой автоматизированный пакет смоук-тестирования47, покрывающий самые важные функции продукта.