Книга: Как тестируют в Google
Интервью с тест-менеджером Брэдом Грином
Интервью с тест-менеджером Брэдом Грином
Брэд Грин, которого прозвали Босоногим, был тест-менеджером многих продуктов Google, включая Gmail, Google Docs и Google+. Сейчас он менеджер в разработке Google Feedback и еще экспериментирует с фреймворками веб-разработки в проекте Angular. Он известен тем, что у него много гениальных идей и нет обуви.
— Мы знаем, что раньше ты был разработчиком в компании Apple. Что заставило тебя перейти в Google и почему именно в направление продуктивности разработки?
Брэд: Линус Апсон помог мне решиться. Мы работали с ним в NeXT,[73] и он был воодушевлен компанией Google. Собеседования шли полгода, и в какой-то момент Патрик Коупленд заманил меня в направление продуктивности разработки. Фокус удался: я узнал в этом отделе так много, что теперь гораздо лучше подхожу на должность менеджера по разработке, на которую я вернулся. Пожалуй, каждого разработчика стоит отправлять на стажировку в команду тестирования.
— Что тебя больше всего удивило в культуре тестирования Google в начале твоей работы?
Брэд: Я пришел в Google в начале 2007 года, и изменения, о которых Патрик говорил в своем предисловии, еще не завершились. Меня поразило, как много ноу-хау тестирования здесь использовали. В любой новой команде я находил эксперта по тестированию, который меня удивлял. Проблема была в том, что весь этот богатый опыт был неуправляем. У эскимосов есть сотни слов для обозначения снега,[74] а в Google были десятки терминов для одного вида теста. Когда я присоединялся к команде, мне приходилось учить их язык тестирования и термины. В одних командах процессы были жестко формализованы, а в других нет. Нужно было что-то менять.
— Что больше всего изменилось в тестировании с момента твоего прихода в Google?
Брэд: Две вещи. Первая: средний разработчик сейчас больше участвует в процессе тестирования и автоматизации. Он знает, что такое тесты API, что такое модульные, интеграционные и системные тесты. Он инстинктивно создает больше тестов, если сталкивается с проблемами во время непрерывной сборки. Ему даже не нужно напоминать об этом. Конечно, это существенно улучшило исходное качество и увеличило скорость выпуска. Вторая: нам удалось привлечь сотни первоклассных разработчиков на роли, связанные с тестированием. Я думаю, эти две вещи связаны. В Google появилась культура, в которой тестирование имеет значение, и тестировать — это круто.
— Расскажи, что значит быть менеджером в Google? Что самое трудное, самое простое и самое интересное в работе менеджера в Google?
Брэд: Самое сложное — научиться управлять людьми, которые могут руководить своей работой сами. Вариант «делай так, как я сказал» сработает разок, а потом вы потеряете контакт с этими талантливыми ребятами, и они будут делать только то, что, по их мнению, лучше для проекта. Моя работа приносила максимальную пользу, когда я помогал, а не руководил, когда я делился информацией и создавал комфортные условия для моих сотрудников, чтобы они занимались любимым делом. Если мне приходилось приказывать, я чувствовал, что не развиваю ребят, не помогаю им учиться принимать решения. Надо стать не названным, а признанным лидером среди чрезвычайно умных и увлеченных инженеров. Менеджеры, будьте осторожны!
— Твоя команда провела масштабную разработку метрик для разработчиков, которые тестируют. Какие метрики вы используете? Какие данные отслеживаете? Как это влияет на качество?
Брэд: Признаюсь, мы двигаемся два шага вперед, один назад. Я терплю неудачи в этой области уже четыре года — и многому научился! Я говорю «неудачи», потому что мы проделали колоссальный путь в поисках волшебных метрик для качества кода и тестов, которые могла бы использовать любая команда. Метрики трудно обобщить, потому что контекст очень важен. Да, чем больше тестов — тем лучше, если только они не медленные и не ненадежные. Да, малые тесты лучше больших, если только вам не нужно проверить строение всей системы. Измерения полезны, но реализация каждого теста уникальна и, наверное, так же близка к искусству, как и код самого приложения.
Оказывается, есть социальные факторы тестирования, которые гораздо сложнее, чем любые технические. Все понимают, что нужны хорошие тесты, но многим менеджерам трудно заставить команды их писать. Лучшее средство для мотивации — соревнования. Хотите получить больше малых тестов? Сравните свою команду с другой. Эй, у той команды тестовое покрытие — 84%, а полный набор тестов выполняется за пять минут! И мы позволим им обыграть нас?!
Измеряйте все, что плохо лежит, но доверяйте людям. При этом все равно будьте реалистом: можно сколь угодно тщательно тестировать продукт внутри компании, но он все равно окажется в руках пользователя. Во внешней среде работают другие законы, вы не можете их ни предсказать, ни воспроизвести.
— Это объясняет твое участие в Google Feedback. Можешь немного рассказать о нем? Какие проблемы должен решать этот продукт?
Брэд: Feedback помогает пользователям сообщить о проблемах, которые они находят в продуктах Google. Звучит несложно? Просто прикрутить к странице форму отправки данных и дать пользователю проставить галочки? Много команд шло этим путем, а потом они не справлялись с лавинами отчетов — часто их приходило по несколько тысяч в день. Еще возникали трудности с отладкой, потому что информация от пользователей не всегда была полной и точной. Для решения этих проблем был создан Feedback.
— Можешь рассказать, как работает Google Feedback?
Брэд: Feedback собирает всю возможную информацию, соблюдая конфиденциальность пользователя. Браузер, операционная система, плагины — все эти данные очень важны для отладки и легко собираются программой. Особенная хитрость со скриншотами. В целях безопасности браузеры не копируют изображение своего содержимого. Нам пришлось заново реализовать механизм визуализации на JavaScript безопасным путем. Теперь мы делаем скриншот и просим пользователя выделить на нем проблемную область. Потом мы просим его описать проблему текстом. Невозможно научить пользователей создавать идеальные баг-репорты, но со скриншотами расплывчатые описания становятся яснее.
— Разве с таким количеством пользователей вы не будете получать сообщения об одном и том же баге?
Брэд: Чтобы избежать дублирования багов, мы автоматически группируем похожие сообщения. Если тысяча пользователей сообщает об одной проблеме, мы объединяем эти сообщения в один слот. Вручную обработать такое количество сообщений было бы невозможно. Затем группы ранжируются, и мы определяем, какие проблемы затрагивают большее количество пользователей. Их мы и будем решать в первую очередь.
— Сколько человек в команде Google Feedback?
Брэд: В команде 12 разработчиков и три менеджера. Последних, конечно, больше, чем обычно, но здесь это оправданно, так как нужно координировать много проектов, связанных с Google Feedback.
— Какие самые серьезные проблемы возникали при запуске Google Feedback?
Брэд: Технически снятие скриншота было невероятно сложной задачей. Многие думали, что даже браться за такое — безумие. А сейчас все функционирует отлично. Мы справились с тем, что баг-репорты создаются на разных языках, но нам предстоит еще много работы. Автоматизированная группировка проблем была и остается очень сложной задачей.
— Какое будущее ждет Google Feedback? Возможно ли, что когда-нибудь система станет доступной не только для сайтов Google?
Брэд: Наша цель — дать пользователям возможность общаться с нами о проблемах в наших продуктах. Сейчас это монолог. Я думаю, что в будущем нам удастся создать инструменты для диалога. Мы не планировали выпускать наш продукт в большой мир, но сейчас мне кажется, что это хорошая идея.
— Каким ты видишь следующий шаг в развитии тестирования программных продуктов?
Брэд: Мне бы хотелось увидеть среду разработки, в которой тестирование — первостепенная фича, а не прикрученная позже. Представьте, что язык, библиотеки, фреймворки и инструменты сами знают, какие тесты будут нужны вашему коду, и помогут вам их написать. Это будет круто. А пока нам приходится прилеплять тестовые фреймворки к разработке. Тесты трудно писать и тяжело сопровождать, они нестабильны во время выполнения. Я думаю, что если мы будем выпекать наши тесты на самом низком уровне, это принесет нам много плюшек.
— У тебя есть какой-нибудь компромат на доктора Джеймса Уиттакера, о котором ты бы хотел поведать миру?
Брэд: Кроме того инцидента с костюмом бедняжки Мэри? Пожалуй, нет. Мы, менеджеры, своих не сдаем!
- Кто такой тест-менеджер
- Жонглирование людьми и дирижирование проектами
- Влияние
- Интервью с Анкитом Мехтой, тест-менеджером Gmail
- Интервью с Хуном Даном, тест-менеджером Android
- Интервью с Джоэлом Хиноски, тест-менеджером Chrome
- Директор по тестированию
- Интервью с Шелтоном Маром, директором по тестированию проектов Search и Geo
- Интервью с директором разработки инженерных инструментов Ашишем Кумаром
- Интервью с Суджаем Сани, директором по тестированию в индийском Google
- Интервью с тест-менеджером Брэдом Грином
- Интервью с Джеймсом Уиттакером
- Глава 4. Тест-менеджер
- Тестирование Web-сервиса XML с помощью WebDev.WebServer.exe
- Кто такой тест-менеджер
- Разработка через тестирование и разработка с тестами
- Директор по тестированию
- 2. Операции декартового произведения и естественного соединения
- 6. Операция естественного соединения.
- Часть III. Шаблоны разработки через тестирование
- Приложение 1 Тестирование ПК при включении
- Программы для тестирования привода
- Программы для тестирования монитора
- Диагностика аудиокарт – тестирующие программы