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

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

Интервью с Джоэлом Хиноски, тест-менеджером 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] над которой работали и разработчики, и тестировщики.

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги