Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 23 (всего у книги 26 страниц)

Интервью с Джеймсом Уиттакером

В Google приход Джеймса был встречен фанфарами, и он сразу стал одним из самых известных людей в нашем тестировании. Он обладает феноменальной харизмой, и все, что он делает, привлекает повышенное внимание: его выступления на GTAC собирают толпы, посты Джеймса в нашем блоге становятся самыми популярными. Он покорил наши офисы в Сиэтле и Киркленде, а по уровню влияния на всю компанию Google он приближается к Патрику Коупленду. Конечно, Пат – формальный руководитель, но у нас есть еще один неформальный лидер в области тестирования – Джеймс Уиттакер.

Джейсон Арбон и Джефф Каролло поговорили с Джеймсом в его офисе.

– В 2009 году ты перешел в Google из Microsoft. Когда ты объявил в своем блоге о том, что уходишь из Microsoft, почему ты не назвал новое место работы? Зачем эта таинственность?

Джеймс:Сразу такой жесткий вопрос? Ого! Мне обещали, что будет просто!

– А ты обещал ответить на наши вопросы, так что давай!

Джеймс:Это был самый простой способ оповестить максимальное количество людей одновременно. Тогда Twitter еще был не очень популярен, и я воспользовался блогом MSDN. Оказывается, коллеги чаще читали мой блог, чем мои электронные письма. Уход из Microsoft немного пугал, и я хотел высказаться один раз, но громко и доступно, чтобы избежать сотни прощальных встреч. Так что это было лучшее решение.

Люди, которые были в курсе моего увольнения, потратили уйму времени, отговаривая меня. Тяжело было уходить из компании, в которой нравилось работать. Трудно было расставаться с людьми, с которыми работал вместе годами. Я чувствовал себя ужасно в связи с уходом, и мне не хотелось повторно обдумывать мое решение. Мне нравится Microsoft, и я уважаю инженеров, которые здесь работают. На самом деле меня действительно могли отговоритьот перехода, но я очень хотел работать в Google и в то же время не хотел давать коллегам возможности повлиять на мое решение.

– Почему? Что такого в Google так сильно тебя привлекало?

Джеймс:Знаешь, это может прозвучать странно. Я начинал как профессор-консультант, потом открыл свой бизнес и успел попробовать все, кроме работы в большой компании. И раз уж я решился на работу в большой компании, пусть она будет самой большой! Чем больше, тем лучше! Чем круче работа, тем лучше! Чем больше аудитория, тем интереснее! Я хотел понять, насколько успешным я могу стать в отрасли, так почему бы не проверить это в лидирующей компании? Так я оказался в Microsoft, а потом в Google. Я хочу работать в больших компаниях и выбираю из них лучшие.

Но самый сильный аргумент – это репутация Google как компании с самой крутой организацией тестирования. Это меня покорило. Долгое время это звание принадлежало Microsoft, но Патрику Коупленду удалось его отбить. Я решил, что самое интересное место работы для тестировщика – это Google.

Собеседования только подкрепили мое мнение. Я встречался с Патриком Коуплендом, Альберто Савоя, Брэдом Грином, Шелтоном Маром, Марком Стрибеком и многими другими. Наши разговоры были потрясающими. Мы с Альберто изрисовали целую доску во время интервью. Только потом он заметил, что забыл задать мне необходимые для собеседования вопросы. С Шелтоном мы разошлись во взглядах, но он настолько уважительно принял мое мнение, что это произвело на меня большое впечатление. Сейчас мы соглашаемся с ним гораздо чаще! А Брэд? Он был крут. Во время собеседования на нем не было обуви (а это был февраль), и это только добавило нашему разговору непринужденности. Марк большую часть собеседования уламывал меня перейти в Google. Атмосфера просто-таки фонтанировала идеями. У меня голова шла кругом.

Признаюсь, после всех собеседований я был утомлен. Помню, я упал в свою машину и думал, что нашел лучшую компанию, но хватит ли мне сил, чтобы здесь работать? Я не был уверен, что смогу внести ощутимый вклад в общее дело. Это все пугало меня, это все было за пределами моей зоны комфорта. Но я люблю сложные задачи, и дух соревнования пересилил мой страх. Кому нужна легкая работа?

– И мы оправдали свою репутацию?

Джеймс:О да, работа оказалась непростой. Но я думаю, вопрос скорее об увлеченности? Честно говоря, и в Microsoft хватает умных и увлеченных тестированием людей. Разница в том, что в Google проще реализовывать свои увлечения. Мы с Альберто никогда не числились в одной команде, но легко работали вместе в «двадцатипроцентное» время. С Брэдом, например, мы до сих пор работаем вместе над средой разработки и автоматизацией баг-репортов (Брэд через Google Feedback, я через BITE). Google хорош тем, что дает возможности для такого сотрудничества и поощряет это.

– Мы работаем с тобой в Киркленде и заметили, насколько отличается темп твоей здешней команды и ее общий настрой. В чем твой секрет?

Джеймс:Да, сейчас в Киркленде дела идут гораздо лучше, но это не только моя заслуга. Частично дело в критической массе правильных людей. Как раз перед моим приходом наняли много талантливых специалистов, и за первые несколько кварталов наш штат тестировщиков стал в четыре раза больше. Я смог строить большие команды и объединять людей, занимающихся похожей работой, даже если они работали над разными продуктами. Теперь вместо одного тестировщика в команде разработки появилась группа специалистов, которые сотрудничали друг с другом и делились идеями. Такая схема творит чудеса и с настроением команды, и с ее производительностью.

Так как у меня было достаточно людей, я смог снять ветеранов вроде вас двоих с текущих проектов, заняв более серьезными задачами. Джефф тогда занимался реализацией очереди предварительной отправки для Google Toolbar, а Джейсон тестировал Google Desktop. Какое глупое использование ваших талантов! Поделюсь секретом хорошего менеджера: подберите каждому человеку идеальную для него задачу – и ваша работа сделана. Люди счастливы, и проекты делаются лучше. Правда, эта роскошь стала доступной только благодаря тому, что к моему приходу набралась критическая масса сотрудников.

Еще один плюс большого количества сотрудников – стало больше людей, которые могут тратить свое «двадцатипроцентное время» на эксперименты. Мне удалось собрать команды на несколько рискованных проектов. Мы начали с инструментов и опытов, которые не имели отношения к выпуску программных продуктов, скорее мы просто делали то, что нам было интересно. Оказалось, что ничто так не воодушевляет тестировщиков, как разработка инструментов. Честно говоря, наверное, это самая приятная часть работы. Наверное, в душе я больше разработчик инструментов, чем тестировщик.

– Что тебе больше всего нравится в организации работы Google?

Джеймс:Командная игра. Я твержу об этом кандидатам, когда хочу убедить их работать у нас: тестировщики рапортуют тестировщикам и сами определяют свою судьбу – это то, что я больше всего люблю в Google. Тестировщики сами нанимают сотрудников, сами проводят собеседования, сами решают, кого повышать. ООН признала нашу Республику Тестирование независимым государством!

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

– Долго ты привыкал к культуре Google? Ведь ты пришел из Microsoft, где не было централизованной организации тестирования?

Джеймс:В начале моей работы Пат Коупленд дал мне два совета. Первый – просто изучи обстановку. Это было критически важно. Нужно время, чтобы разобраться в том, как работает большая компания. Чтобы успешно работать в Google, нужен другой набор навыков, не такой, как в Microsoft. Так что первые пару месяцев я следовал совету Пата – только слушал и задавал вопросы. Кажется, я даже продлил себе период адаптации на пару недель.

– А второй совет?

Джеймс:Да, извини, увлекся. Иногда Пат говорит умные вещи, и, кажется, мне попалась как раз такая. Второй совет мне совсем не понравился, но оказался еще полезнее первого. Пат отвел меня в сторонку и сказал: «Слушай, парень, я знаю, что у тебя есть репутация за пределами Google, но внутри ты еще ничего не сделал». Пат – человек прямой, и в разговоре его сложно понять неправильно. И я осознал – Google не было дела до того, чем я занимался до прихода сюда. Чтобы состояться именно здесь, я должен сделать что-то внутри компании. Нельзя заслужить уважение в Google, просто прогуливаясь и насвистывая. Пат предложил мне взяться за большой проект и удачно завершить его, да еще и так, чтобы это было заметно. Я выбрал Chrome и Chrome OS и стал там первым менеджером по тестированию. Проект был выпущен, и я передал его одному из своих ребят.

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

– Кроме тестирования продуктов, какими направлениями ты занимался по совету Пата?

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

– И что же ты сделал для инженеров по тестированию?

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

Рабочая команда много сделала для определения роли инженера по тестированию. Например, мы переписали рекомендации по карьерному продвижению. Мы выдвинули новый вариант карьерной лестницы на открытое голосование всего сообщества инженеров по тестированию в Google, и ее приняли. Это было здорово – я даже выписал премию всей рабочей группе, чтобы отпраздновать это событие. Наши идеи исходили «снизу», от людей, работающих в специальности, и поэтому принимались легко. Мы написали рекомендации по проведению интервью и разослали их рекрутерам и инженерам, участвующим в собеседованиях. Я думаю, что сейчас роль инженеров по тестированию определена так же четко, как и роль разработчика в тестировании.

– Ты уже достаточно давно работаешь в Google и знаешь всю подноготную. Можешь выдать нам секретный ингредиент Google? Что делает наше тестирование магическим?

Джеймс:Рецепт такой: возьмите высокую квалификацию тестировщиков, добавьте дефицит человеческого ресурса (который заставляет разработчиков помогать, а тестировщиков – оптимизировать), первым делом автоматизируйте (чтобы люди делали только то, в чем компьютеры не сильны), введите способность работать итеративно и быстро внедрять изменения после обратной связи от пользователей. Смешать, но не взбалтывать! Любая компания, которая захочет воспроизвести нашу организацию тестирования, должна начать с этих четырех ингредиентов.

– Как насчет другой книги? У тебя уже задумана следующая книга по тестированию?

Джеймс:Не знаю, я ведь никогда не планирую книги заранее. Моя первая книга родилась из курсовых заметок, которые я использовал для преподавания тестирования в Политехническом университете Флориды. Однажды после презентации на конференции STAR ко мне подошла женщина и спросила, не думал ли я о написании книги. Вопрос оказался с подвохом, так как она была книгоиздателем. Так родилась серия «How to Break Software». Я написал первую книгу сам до последнего слова и был сильно утомлен процессом, поэтому решил больше не писать в одиночку. Над следующими двумя книгами я работал с соавторами. Хью Томпсон написал книгу «How to Break Software Security», Майк Эндрюс написал «How to Break Web Software», а я помогал им обоим. Это действительно ихкниги. Я всего лишь написал часть материалов и управлял процессом. Мне нравится писать, но ни Хью, ни Майк не стали бы смущать меня, утверждая, что я пишу лучше, чем они. А вы двое? Я так не думаю. Но факт в том, что без меня никто бы не решился писать. В конечном итоге все, что происходит в моей карьере, заканчивается книгой, а окружающие меня люди становятся соавторами. Будете отрицать?

– Вообще-то читатель сейчас держит в руках доказательство твоих слов. Как тут поспоришь!

Джеймс:Не буду говорить, что я совсем не могу писать в одиночку. «Exploratory Testing» – книга, которая была написана без соавторов. Она появилась из презентаций, которые я проводил на конференциях. Я создал тонну материалов, и со временем их накопилось достаточно на книгу.

А за эту книгу я бы вряд ли взялся, если бы вы двое не согласились помочь. Впрочем, это моя первая книга, которая по-настоящему писалась коллективно. На мой взгляд, каждый из нас внес равный вклад.

– Да, это так, и мы были очень рады возможности поучаствовать. Возможно, в программировании мы сильнее тебя, а Джефф вообще круче всех на этой планете, но ты умеешь создавать легко читаемый текст! Скажи, какая часть книги тебе нравится больше всего?

Джеймс:Мне нравится вся книга. Писать ее было очень интересно. Дело даже не в поиске материала – он у нас уже был. Нам оставалось только записать его. Наверное, если все-таки выбирать любимые части книги, то я выберу интервью. Их было интересно и проводить, и записывать. Надо было с них начинать работу. Беседа с Хун Даном стала для меня настоящим откровением. Он провел для меня экскурсию по своей лаборатории Android, где мы обсуждали философию тестирования, и интервью получилось крайне насыщенным. Я так быстро не записывал со времен аспирантуры. Это было самое ценное время, которое я когда-либо проводил с ним. Я узнал о людях и процессах то, чего не знал раньше. Наверное, это особенность работы журналиста – удается по-настоящему узнать тему.

– А чем бы ты занимался, если бы не попал в тестирование?

Джеймс:В технологической области я, наверное, занимался бы инструментами для разработки и стал бы евангелистом. Мне нравится упрощать создание программного кода. Не все программисты так хороши, как Джефф Каролло! Не могу поверить, что мы до сих пор пишем приложения вручную. Навыки разработчика, которые я освоил в 80-е годы, до сих пор востребованы. Это какое-то безумие. Весь технологический мир изменился, а мы все еще пишем на C++. Почему разработка не упрощается? Почему написание ужасного, ненадежного кода до сих пор остается нормой? Писать хороший код должно быть проще, чем плохой. Я бы работал над этой проблемой.

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

– А если бы пришлось работать за пределами технологической области?

Джеймс:С этим сложнее, потому что пока я не вижу для себя иной специальности – я все еще горю этой. Думаю, я мог бы вести курсы менеджмента. Вы, парни, часто говорите мне, что я неплохой менеджер; когда-нибудь я сяду и подумаю над тем, как мне удается не лажать. Может, это станет темой моей следующей книги – «Как быть менеджером и не лажать». Также мне хотелось бы поработать на пользу окружающей среде. Мне нравится эта планета, и я думаю, ее стоит держать в порядке.

Да, и я люблю пиво. Я очень люблю пиво. Когда-нибудь я бы мог сыграть Норма из сериала «Cheers». Могу себе представить: я вхожу в бар, все кричат: «Джеймс!», а тот, кто занимает мой табурет, уступает мне место.

Вот это я называю хорошо сделанной работой. Пожалуй, я бы выписал премию Норму из чистого уважения.

Глава 5. Как мы улучшали тестирование в Google

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

Если ваша компания достигла такого уровня качества, встает вопрос: «А что дальше?».

Google уже столкнулся с этим «дальше». Пока мы совершенствовали роль тестирования, мы встретились с немалым количеством побочных проблем. В этой главе мы расскажем о наших ошибках и разберем, как тестирование помогает (или мешает) их исправлять. В конце концов, наше тестирование ушло от централизованного управления, повышение продуктивности разработки перестало управляться из одной точки и разошлось по командам. Мы думаем, что когда уровень тестирования достигает зрелости, такая перестановка сил неизбежна. Модель, в которой разработка отделена от тестирования, больше не жизнеспособна в Google.

Роковые ошибки в процессе тестирования Google

Понятие «тестирование» часто подменяет понятие «качество». Если спросить разработчика, что он делает для качества продукта, нередко можно услышать: «Я его тестирую». Но смысл тестирования не в улучшении качества. Качество должно быть встроено в продукт по умолчанию, а не привинчено к нему позже, поэтому качество должен обеспечивать разработчик, и точка. Итак, встречайте роковую ошибку номер один: тестировщики превратились в «костыли» для разработчиков. Чем меньше мы заставляем разработчиков думать о тестировании, чем сильнее его упрощаем для них, тем меньше они им занимаются.

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

Проблема усугубляется тем, что тестирование в Google выделено в отдельное направление. Качество – это не только проблема кого-то другого, это проблема другого отдела. Как и в случае с газоном, легко найти ответственного и повесить на него все, что пошло не так.

Роковая ошибка номер два тоже связана с разделением разработчиков и тестировщиков: тестировщики отождествляются со своей ролью, а не с продуктом.

Если фокус не на продукте – продукт всегда страдает. В конце концов, цель всей разработки – создание продукта, а не программирование, тестирование или документирование. Каждый инженер работает на продукт. Его должность при этом вторична. Признак здоровой компании – когда люди говорят «Я работаю в Chrome», а не «Я работаю тестировщиком».

Пару лет назад я видел на конференции по тестированию футболку с надписью «Я тестирую, следовательно, я существую» на греческом и английском языках. Не сомневаюсь, что ее автор дьявольски умен, но этот агрессивный слоган раздувает роль тестировщика, хотя она этого не стоит. Ни одна роль этого не стоит. Все участники команды работают над продуктом, а не над отдельными его частями. Сначала появился продукт, а потом вылупился процесс. Зачем же нам процесс, если не для создания хорошего продукта? Пользователи любят продукты, а не процессы.

Разделение разработки и тестирования в Google подчеркивает эту разницу в ролях и мешает тестировщикам осознавать свое место в продукте.

Роковая ошибка номер три: тестировщики часто ставят артефакты тестирования выше самого продукта. Ценность тестирования – в действии, а не в артефактах.

Каждый артефакт, который создает тестировщик, уже вторичен по отношению к исходному коду. Тест-кейсы и план тестирования менее важны. Даже баг-репорты менее важны. Действия, которые стоят за этими артефактами, – вот что приносит пользу. К сожалению, восхваляя стопку баг-репортов, представленную тестировщиками во время ежегодного отчета, мы забываем о продукте. Ценность артефактов определяется тем, как они влияют на исходный код, а значит, на продукт.

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

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

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

О’кей, и что же со всем этим делать? Как взять только хорошее из организации тестирования в Google и переориентировать все процессы на продукты и команды? Мы только вступаем на эту неисследованную территорию, поэтому можем только предполагать. Но нам кажется, что тренды, которые мы описываем в книге, задают тон будущего тестирования в Google и за его пределами. Более того, выделившиеся роли разработчика в тестировании и инженера по тестированию – это изменение в сторону как раз этого будущего.

В Google эти две роли все сильнее расходятся. Разработчик в тестировании все больше напоминает разработчика, а инженер по тестированию идет в противоположную сторону и почти сливается с пользователем. Это происходит естественно, в результате взросления процессов разработки. С одной стороны, этот тренд объясняется такими техническими новшествами, как сжатые циклы разработки и непрерывная доступность последней сборки для разработчиков, тестировщиков и пользователей. У нас стало больше возможностей подключать неинженерных участников к разработке. С другой стороны, взросление процессов разработки привело к тому, что качество стало общей заботой, а не только обязанностью инженеров, в должности которых есть слово «тестирование».