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

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

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

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

Интервью с Хуном Даном, тест-менеджером Android

До того как Хун Дан был приглашен возглавить команду тестирования Android, он успел успешно поработать инженером в Apple и TiVo. [67]67
  TiVo – компания, которая разработала цифровое устройство для записи видео – TiVo. Устройство по сети связывается с сервером и записывает выбранные пользователем телепередачи или сериалы, которые он может просмотреть в любое время на своем телевизоре.


[Закрыть]

Cтратегическую важность Android для Google трудно отрицать. Этот проект стал таким же хитом, как Search или Ads. Android получил особое внимание руководства и привлек первоклассных специалистов. Его кодовая база растет на глазах, и одна сборка может насчитывать сотни изменений в день. На базе этой операционной системы запускаются тысячи приложений, вокруг нее формируется сообщество разработчиков. Количество устройств, работающих на платформе Android, постоянно растет; она стоит на новых телефонах и планшетах множества производителей. В зоне ответственности Хуна и его команды все: от тестирования совместимости устройств и управления питанием до проверки работы приложений.

Мы встретились с Хуном, чтобы узнать, как организовано тестирование Android.

– Расскажи нам о том, как начиналось тестирование. Наверное, на первых порах, до появления смартфонов и многочисленных приложений, было проще?

Хун:К сожалению, нет. Когда я взял на себя руководство тестированием Android, команда только сформировалась и многие инженеры никогда не тестировали до этого операционные системы, не говоря уже о мобильных устройствах. Моей первой задачей было скоординировать работу команды и построить инфраструктуру тестирования. Я думаю, что начальная фаза проекта тестирования – самая трудная часть работы. Когда у тебя есть крепко сбитая команда и налаженная инфраструктура, то можно справиться с продуктом любой сложности. Тяжелее всего в планировании, зато потом легко в тестировании!

– Давай остановимся здесь, ведь множество менеджеров по тестированию бьются на ранних стадиях своих проектов прямо сейчас. Расскажи, что вы делали на ранней стадии проекта Android?

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

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

– Звучит впечатляюще. И как команда справлялась?

Хун:На самом деле я потерял около 80% старой команды. Зато оставшиеся стали техническими лидами. Они подавали пример и работали с новичками, которых мы привлекали в команду. Нет универсальных людей, которые вписываются во все проекты. В Google достаточно работы, и если кому-то не подошел Android, то, возможно, подойдет другой проект. В Google такое разнообразие и создает здоровую среду тестирования.

– Какие были приятные моменты тестирования?

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

– Это непросто, хотя по твоим словам этого и не скажешь! Расскажи нам более подробно об организации тестирования, о которой ты обмолвился. Ты коснулся процесса сообщения о багах, но, конечно, это не все. Как ты организуешь саму работу?

Хун:Я воспринимаю структуру Android как своеобразную «колоннаду». Я знаю, что при тестировании Chrome OS вы используете другую терминологию, но мне нравится идея тестовых колонн. Каждая группа тестировщиков отождествляется с одной из таких колонн, на которых держится весь продукт. Для Android мы организовали четыре колонны: системную (ядро, носители информации и т.д.), колонну фреймворков, колонну приложений и колонну магазина приложений. Спросите любого из моих тестировщиков, что они тестируют, и вам укажут одну из этих колонн.

– Логично, что колонны соответствуют разным навыкам тестировщиков. Одни хорошо работают с низкоуровневыми аспектами, другие лучше справляются с высокоуровневыми, а вместе они поддерживают всю систему. Хорошая схема. А как насчет автоматизации? Как она вписывается в вашу задачу?

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

– Минуточку! Что за Droid-канал?

Хун:О, извини. Как я уже упоминал в начале разговора, в проекте Android некоторые вещи делаются иначе. И называются тоже по-другому – мы используем не те каналы, к которым вы привыкли в Chrome. У нас есть канареечный канал, Droid-канал (аналог канала внутренних пользователей, но для команды Android), экспериментальный канал, Google-канал и уличный канал (сборка, которую мы передаем для внешнего использования). Идея та же, просто другое название.

– Итак, у вас есть пакет автоматизированных тестов для выявления багов, препятствующих переходу канареечной сборки в канал для разработчиков. Этими тестами занимаются выделенные разработчики в тестировании?

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

– Так значит, у вас больше тестировщиков, чем разработчиков в тестировании?

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

– Что ж, поговорим о ручном тестировании, потому что ты явно относишься к нему серьезно (и это восхищает!).

Хун:Я верю в пользу целенаправленного ручного тестирования. Действовать наугад неэффективно. Мы внимательно присматриваемся к ежедневной сборке, которую тестируем, и анализируем ее содержимое. Что изменилось? Сколько изменений добавилось или трансформировалось? Какая функциональность добавилась, а какая изменилась? Кто из разработчиков отправлял изменения? Насколько обширны изменения по сравнению со вчерашней сборкой? Это помогает сфокусироваться, и вместо рысканья по всему продукту мы сосредоточены на проверке изменений изо дня в день, что и делает нашу работу намного более производительной.

Понятно, что координация в команде очень важна. Так как я настаиваю, что каждый участник должен заниматься исследовательским тестированием, нужно свести к минимуму перекрытия. На планерках мы уточняем, что нужно тестировать, и определяем, кто чем занимается. Я считаю ручное тестирование успешным, если оно целенаправленно и скоординировано. Если эти условия соблюдены, значит время на тестирование потрачено с пользой.

– Вы создаете документацию для ручного тестирования или занимаетесь исследовательским тестированием?

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

– Расскажи нам о своих требованиях к разработчикам. Ты требуешь от них спецификаций? Заставляешь применять TDD? Как насчет юнит-тестов?

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

Если вы требуете спецификацию, это не значит, что вы ее получите. Если вы настаиваете на юнит-тестах, это еще не значит, что они принесут пользу. Ни написание спецификации, ни создание юнит-теста не поможет вам найти проблему, с которой столкнется реальный пользователь (кроме обнаружения очевидного регрессионного бага). Это законы моего мира – мира тестировщиков. Вы работаете с тем, что дано, и выжимаете из этого максимальную пользу для продукта и команды.

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

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

– Хун, мы рады, что ты на нашей стороне! А теперь блиц-опрос. Если бы тебе дали лишний день для тестирования выпуска Android, что бы ты сделал?

Хун:Если бы у меня был лишний день, я бы сделал еще одну сборку! Нет такого понятия – лишний день!

– Туше! Тебе есть о чем жалеть? Есть баг, который пробрался через канал выпуска к пользователю?

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

– Нет, ты так легко не отвертишься! Назови хотя бы один!

Хун:Ладно, был у нас баг с активными обоями (Active Wallpaper) несколько выпусков назад. Иногда при запуске обоев все просто падало. Решение было простым, а мы выдали его так быстро, что пользователь почти ничего не заметил. Но это нас не оправдывает. Мы написали тесты для этого случая, поверьте мне, мы их написали!

Интервью с Джоэлом Хиноски, тест-менеджером Chrome

Джоэл работал тест-менеджером в Google с первых дней открытия офиса в Сиэтле (Киркленде) и успел поруководить множеством команд за эти годы. Сейчас он отвечает за все клиентские продукты, включая Chrome и Chrome OS. Джоэла прозвали «капризным австралийцем», и, возможно, это характеризует его требовательный стиль тестирования, но совсем не вяжется с его высокими рейтингами как руководителя.

Недавно мы встретились с Джоэлом и обсудили его представления о тестировании и опыт работы с Chrome и Chrome OS.

– Признавайся, на каком компьютере ты работаешь!

Джоэл( достает ноутбук): Chromebook – вот моя детка!

– Сколько еще гаджетов затерялось в твоем рюкзаке?

Джоэл:Ха! У меня в кармане сотовый телефон, а где-то рядом лежал планшет. Я использую свой Chromebook для работы, а когда он делает что-то не так, я сообщаю об ошибке. Надо пользоваться оборудованием, которое ты тестируешь!

– Итак, ты руководишь тестированием и управляешь полным спектром продуктов: панели инструментов, инсталлеры Chrome и Chrome OS и все, что работает на клиентской операционной системе (и сама операционная система), – твои зоны ответственности. Тебе приходится управляться с множеством команд разработчиков. Как ты сохраняешь баланс?

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

– Ты жонглер или осьминог? А если серьезно, какое место ты занимаешь в этой многоходовой комбинации?

Джоэл:Стараюсь быть практичным. Мне нужно выпустить программу, а для этого придется чем-то пожертвовать. Это всегда торги. Конечно, у нас гибкая система разработки, но все равно приходится делать обязательную финальную проверку качества (мы называем ее «последняя миля»). Мы проводим исследовательское тестирование, но все равно отслеживаем разные версии и платформы. Все относительно.

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

– Кажется, на горизонте маячит еще одна книга по организации тестирования в Google.

Джоэл:Да, дайте мне год, и мы сравним объемы продаж или рейтинги на Amazon. Хотя какого черта, мы в Google – мы померяемся релевантностью!

– Ладно, вернемся к тестированию в Chrome и Chrome OS. В этой книге мы обсуждаем общую инфраструктуру тестирования Google для команд веб-приложений. Ты ведь работаешь в клиентском пространстве, твоя работа сильно отличается?

Джоэл:Отличается, и это создает много проблем. Клиентское направление не основное направление в Google. Мы – веб-компания и знаем, как хорошо построить и протестировать веб-приложения. Основная проблема с клиентскими продуктами в том, чтобы преобразовать накопленный опыт и инструментарий для клиентских машин. Это серьезная трудность, ведь инфраструктура Google не может помочь моим проектам.

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

– Мы узнаем ребят, которых ты описал. А после того как команда была сформирована, какая проблема стала самой серьезной?

Джоэл:Сам веб! Серьезно, среда постоянно меняется, а Chrome обязан поспевать. Поток дополнений, расширений, приложений, версий HTML и Flash не прекращается. Количество переменных факторов зашкаливает, а ведь все они должны работать. Если мы выпустим браузер, который не отображает ваш любимый сайт или приложение, вам не придется долго искать альтернативный браузер.

Еще мы тестируем на разных операционных системах, но их не так много, а наша инфраструктура виртуализации упрощает процесс. Так что все проблемы, которые меня беспокоят, идут из веба.

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

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

Совместимость приложений очень важна для браузеров. Совместим ли Chrome с приложениями и сайтами в вебе? Правильно ли в Chrome отображаются страницы и запускаются веб-приложения? Разумеется, мы не можем проверить все приложения и сайты. И даже если бы могли, с чем их сравнивать? Мы отвечаем на эти вопросы, тестируя самые популярные сайты (в Google эту информацию не нужно долго искать) в контрольных версиях Chrome и браузерах конкурентов. Наши инструменты автоматически открывают тысячи сайтов и сверяют правильность их отображения. Мы делаем это для каждой ежедневной сборки, поэтому регрессии обнаруживаются очень быстро. Если сайт отображается иначе, сразу же подключается человек, чтобы найти, в чем проблема.

Впрочем, это только вершина айсберга. Нам еще было нужно уметь запускать сайты и приложения, а для этого нужны были средства автоматизации на уровне пользовательского интерфейса. Chrome поддерживает API, называемый Automation Proxy, который можно использовать для запуска браузера, открытия URL-адреса, проверки его состояния, получения информации о вкладках и т.д. Мы разработали для него интерфейс на Python, так что теперь можно написать скрипт для браузера на Python (этот язык знают большинство тестировщиков в Google). Так автоматизация функциональных тестов стала возможна, и мы создали большую библиотеку PyAuto, [68]68
  Почитать подробнее о PyAuto можно по адресу: http://www.chromium.org/developers/testing/pyauto


[Закрыть]над которой работали и разработчики, и тестировщики.

– Ладно, ты победил Chrome. Так как Chrome OS – это тот же Chrome, только встроенный в ноутбук, его тестирование, наверное, было простым?

Джоэл:Можно подумать, если я тестирую Safari, то заодно тестирую и Mac OS? А если я протестировал IE, то и Windows летает? Ага, сейчас! Само существование Chrome OS только усложняет тестирование Chrome, потому что мне приходится добавлять еще одну платформу в список совместимости приложений.

И все же я скажу вам, что у нас все схвачено, и это очень круто. Google контролирует все в этой системе с самого низа, от компонентов, работающих с материнской платой, и поднимаясь наверх до пользовательских интерфейсов. Поэтому спускаясь обратно вниз, видишь много знакомого – многое перекликается с тестированием Chrome. Я могу использовать PyAuto и строю хорошие автоматизированные пакеты с возможностями повторного использования результатов команды Chrome. А потом начинается: прошивка, ядро, графический процессор, сетевой адаптер, беспроводной модем, 3G… Чего только нет в этих миниатюрных устройствах! Здесь уже сложнее применять автоматизацию. Это трудоемкие задачи тестирования, которые не работают при стандартном для Google соотношении количества разработчиков к количеству тестировщиков. Здесь нужно больше тестирования. Мы работали с этими системами со стадии прототипа, и нам даже приходилось монтировать электронные платы на картонных коробках.

Известные инструменты тестирования нашей системе не подходили. Chrome OS работает с открытым кодом и находится за рамками обычной системы разработки Google. Нам пришлось заново изобретать колесо (причем почти буквально) во многих тестовых инструментах, менять процессы с учетом особенностей новых инструментов и предоставлять эти инструменты внешним разработчикам. Мы выпускаем эту ОС для пяти разных платформ на трех каналах (разработчиков, бета, стабильном) с шестинедельным графиком. Если бы я не был австралийцем, я бы сошел с ума!

Итак, нам пришлось творчески решать задачи. Где мы можем переложить создание инструментов на разработчиков? Какой объем тестирования можно требовать от партнеров и производителей? Как обучить нашу команду эффективно тестировать оборудование? Что можно придумать, чтобы снизить нагрузку на ручное тестирование? И как это будет соотноситься с запуском на реальных устройствах?

– То, что ты начал отвечать вопросами, говорит о том, что нам придется ждать выхода твоей книги для получения ответов!

Джоэл:Да, придется ждать, потому что даже у меня нет всех ответов, и это моя работа – найти их. Мы в самом начале пути, нам еще нужно найти подход, гармонично сочетающий ручное тестирование с автоматизацией. Мы переработали Autotest [69]69
  Про Autotest можно почитать по адресу http://autotest.kernel.org/


[Закрыть](опенсорс-инструмент для тестирования ядра Linux) для управления большим набором автоматизированных тестов оборудования Chrome OS. Команда, работающая над этим, значительно расширила программу с учетом особенностей нашей платформы и внесла много изменений, причем все это в условиях открытого кода. В итоге Autotest выполняет наш цикл предстартовых тестов, смоук-пакет, а также тесты проверки сборки на реальном оборудовании и на виртуальных машинах. Конечно, мы не забываем PyAuto и с его помощью управляем автоматизацией тестирования браузера Chrome, работающего в Chrome OS.

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

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

Конечно, это шутка, но я действительно ревностно отношусь к тестированию и поэтому готов нанимать только правильных кандидатов на роли инженеров Google. Например, найти людей для Chrome было непросто из-за тенденции бросать все силы на решение проблемы. Возникли неполадки с проверкой CR-48, Samsung Chromebook и новых экспериментальных платформ по трем каналам за неделю? Бросаем тридцать специалистов, пускай разбираются! Нужно проверить стабильную сборку Chrome S за двадцать четыре часа? С восемнадцатью ручными тестировщиками это будет легче легкого!

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

– И последний вопрос: зачем выбирать карьеру в области тестирования?

Джоэл:Тестирование – это последний рубеж проекта. Как сделать разработку эффективной – уже более-менее понятно, но есть непочатый край работы по решению проблем тестирования: от организации всей технической работы до создания быстрой и эффективной автоматизации. И все это с нужной гибкостью. Сегодня это самая интересная область разработки с потрясающими возможностями карьерного роста. Вам уже не придется возиться с кусочком кода, вы летаете выше: проверяете аппаратное ускорение своего сайта на HTML5, убеждаетесь в том, что ваша оптимизация ядер процессора обеспечивает максимальную производительность и что ваша песочница [70]70
  Песочница (от англ. sandbox) – отдельное пространство для тестирования программ или приложений. Любые игры в ней не повредят ОС, так как песочница изолирована от системы.


[Закрыть]действительно безопасна. Меня такие вещи интересуют и воодушевляют, поэтому я доволен тем, что работаю над организацией тестирования в Google, более того, над одним из самых сложных проектов, которые у нас есть.