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

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

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

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

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

Руководители помогают людям устанавливать ежеквартальные и годовые OKR. [46] OKR (Objectives and Key Results, то есть «цели и ключевые результаты») — это список целей и оценка успеха в достижении этих целей. Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны. Они следят за тем, чтобы цели ставились высокие и амбициозные, поощряют людей метить высоко даже при краткосрочном планировании. Менеджеры следят, чтобы цели отвечали способностям и интересам инженеров и не конфликтовали с требованиями проекта и бизнеса.

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

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

На середине очередного проекта мне предложили взяться за колоссальную задачу тестирования 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] Смоук-тестирование — это минимальный набор тестов, который проводят, чтобы убедиться, что базовые функции программы работают корректно. Если система не проходит смоук-тестирование, то дальнейшие тесты не имеют смысла. Термин родился в ходе проверки радиоэлектронных устройств — если после пробного включения детали аппарата перегреваются, «идет дым», то все устройство нужно отправлять на доработку. — Примеч. перев. покрывающий самые важные функции продукта.