Уиттакер . - Как тестируют в Google
— Стратегические инициативы. Менеджмент тестирования часто спрашивают, что еще такого можно сделать в 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, покрывающий самые важные функции продукта.
Потом мы принялись изучать старые тест-кейсы. Многие из них было сложно даже понять. Например, там были ссылки на код из прототипов или уже удаленных функций ранних версий или же они сильно зависели от контекста и состояния машин. К сожалению, большая часть документации жила только в головах разработчиков из Хайдарабада. Если бы нам вдруг понадобилось быстро проверить сборку с фиксами безопасности, у нас бы ничего не вышло. Это обошлось бы слишком дорого. Поэтому мы решились на смелый шаг — проанализировали все 2500 тестов, выявили самые важные и актуальные из них, а потом удалили все, оставив примерно 150 тестов. Да, количество тест-кейсов удалось здорово сократить. Поработав вплотную с подрядчиками, мы довели до ума оставшиеся ручные тест-кейсы — последовательность действий стала настолько ясной и подробной, что ее мог выполнить любой, кто пользовался Google Desktop хотя бы несколько минут. Мы не хотели остаться единственными людьми, которые могли выполнить регрессионную серию.
К этому моменту у нас было покрытие автоматизированными тестами для сборок, которое уже начало вылавливать регрессионные баги за нас, и очень небольшой набор ручных тестов, которые мог выполнить кто угодно за день для релизной версии. Все это дало подрядчикам время заняться более приоритетными вещами, затраты сократились, а задержки выпуска заметно уменьшились при практически неизменном функциональном покрытии.
Примерно тогда же начался проект Chrome, и это направление считали будущим для сервисов Google на клиентских машинах. Мы уже были готовы пожинать плоды наших трудов по автоматизации с полнофункциональным тестовым API, занесли руку над построением генерируемых тестов для длительного выполнения, но тут пришло распоряжение быстро перебросить ресурсы на браузер Chrome.
С автоматическими регрессионными тестами, проверявшими каждую внутреннюю и публичную сборку, с очень простым ручным тестированием нам не стыдно было оставить Desktop в режиме сопровождения и сосредоточиться на менее устойчивом и рискованном проекте Chrome.
Но у нас оставался еще один капризный баг: в некоторых версиях Google Desktop у некоторых пользователей поглощалось свободное пространство на диске. Решение проблемы откладывалось, потому что мы не могли воспроизвести его. Мы попросили своего коммьюнити-менеджера собрать больше информации от пользователей, но никто не смог четко определить проблему. Мы переживали, что со временем этот баг мог затронуть большее количество пользователей, а без полноценной команды на проекте он не будет решен вообще. Поэтому перед уходом мы бросили все силы на исследование этой проблемы. Дошло до того, что автора исходного кода индексирования выдернули на проект из другого места, полагая, что он знает, где нужно искать. И он знал. Разработчик заметил, что Desktop продолжает повторно индексировать задачи, если у пользователя установлен Outlook. Дело в том, что код индексирования при каждом сканировании принимал старую задачу за новую и медленно, но верно пожирал жесткий диск. А предпочитал этот гурман только диски тех пользователей, которые пользовались планировщиком задач Outlook. Так как максимальный размер индекса 2 Гбайта, он заполнялся очень медленно, и пользователи замечали только то, что их новые документы не проиндексировались. Мы выпустили последнюю версию Desktop с исправлением этого бага, чтобы нам не пришлось возвращаться к этой проблеме через полгода на проекте с урезанной командой.
