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

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

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

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

Интервью с инженером по тестированию YouTube Эппл Чоу

Эппл Чоу – инженер по тестированию Google Offers. До этого проекта она руководила тестированием YouTube в офисе Google в Сан-Франциско. Эппл любит сложные задачи и всегда стремится применить к ним новейшие инструменты и методы тестирования.

Недавно мы побеседовали с Эппл и попросили ее рассказать о тестировании YouTube.

– Эппл, что привело тебя в Google? Такое имя наверняка наводило на мысли о работе в другой компании?

Эппл:Ха! Адрес [email protected]выглядит очень аппетитно! Но я выбрала Google из-за разнообразия продуктов и возможности поработать с исключительными специалистами. Мне нравится менять проекты и работать на разных флангах, поэтому я решила, что Google – подходящее для меня место. Я могу влиять на работу миллионов пользователей в самых разных областях. Каждый день ставит новые задачи, и мне никогда не бывает скучно. Конечно, бесплатный массаж – тоже плюс.

– Расскажи о процессе собеседования на роли тестировщика и разработчика в тестировании.

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

– Ты работала во многих технологических компаниях. Что оказалось самым неожиданным в организации тестирования в Google?

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

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

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

Есть еще один важный момент: культура «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования, и в этом мы можем легко положиться на разработчиков. Мы все в Google играем на стороне качества продукта, и любой инженер может протестировать любой код с любого компьютера. Поэтому вся работа идет быстро.

– Отличия понятны, а чем тестирование в Google схоже с тестированием в других компаниях?

Эппл:Функциональность приложения, которую трудно автоматизировать, создает нам столько же проблем с тестированием, сколько и любой другой компании. Когда мы в спешке доделываем новые фичи для очередного выпуска, мы тестируем код не так тщательно, как хотелось бы. Идеальных компаний и совершенных продуктов не бывает.

– За какие функциональные области ты отвечала, работая инженером по тестированию для YouTube?

Эппл:Я работала с разными командами и участвовала в выпуске многих новых фич YouTube. Предмет моей особой гордости – запуск новой страницы просмотра роликов, которую мы полностью переработали. Это одна из самых часто просматриваемых страниц в интернете! Другой запоминающийся проект – наше партнерство с Vevo, новым порталом музыкального контента, для которого YouTube обеспечивает видеохостинг и стриминг. Этот проект – совместное творение Sony Music Entertainment и Universal Music Group. В день запуска на нем уже было 14 000 видеороликов. За три месяца после запуска видеоролики Vevo на YouTube собрали больше 14 миллионов просмотров. Еще я координировала работу по тестированию переписанной версии видеопроигрывателя YouTube на базе Flash, когда мы переходили с ActionScript 2 на ActionScript 3, и запуск новых страниц Channel и Branded Partner.

– Каково это – рулить тестированием в Google?

Эппл:Это значит координировать работу не только в своей команде и проекте, но и не забывать присматривать за всеми продуктами, на которые может повлиять наша работа. Например, в проекте Vevo мы постоянно держали в голове проигрыватель YouTube, брендированный компонент просмотра, иерархию каналов, распределение трафика и т.д. Нужно уметь видеть лес за деревьями.

– Как ты адаптировала исследовательское тестирование для YouTube?

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

– Как тестировщики YouTube восприняли идею исследовательского тестирования?

Эппл:О, она здорово их взбодрила! Все-таки тестировщикам нравится искать баги. В исследовательском тестировании ребятам нужно немного побыть пользователем и его глазами пройти весь тур, его руками попытаться сломать продукт. Поэтому к написанию новых тестов надо подходить творчески, – работа становится интереснее, удается найти такие баги, которые обычно или пропускают, или тестируют долго и нудно, пока не наткнутся на них.

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

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

– Какие именно работали? Можешь назвать?

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

– Насколько мы знаем, вы много тестируете YouTube с помощью Selenium. Что тебе нравится и не нравится в автоматизации с использованием Selenium?

Эппл:Нравится простота API, то, что можно писать код тестов на любимом языке программирования, будь то Python, Java или Ruby, возможность прямого вызова кода JavaScript из приложения – потрясающая, суперполезная функция.

Не нравится то, что технология так и осталась браузерным тестированием. Она медленно работает, нужно встраивать точки входа в API, а тесты работают далеко от тестируемого кода. Selenium помогает при автоматизации сценариев, которые человеку особенно трудно проверять, например при вызовах к рекламной подсистеме. У нас есть тесты, которые запускают видеоролики и перехватывают вызовы Ad с помощью Banana Proxy (внутренняя программа проверки безопасности веб-приложений, которая логирует запросы и ответы HTTP). В двух словах: мы перехватываем запросы из браузера и направляем их на Banana Proxy, который их логирует и передает в Selenium. Так мы можем убедиться в том, что исходящие запросы содержат правильные URL-параметры, а содержимое входящих ответов соответствует ожиданиям. Тесты пользовательского интерфейса работают медленно, менее надежны и дороже в сопровождении. Мы пришли к выводу, что следует оставить несколько больших высокоуровневых смоук-тестов для проверки сквозных интеграционных сценариев, а остальные тесты должны быть как можно меньшего размера.

– Большая часть контента и пользовательский интерфейс YouTube работают на Flash. Как вы это тестируете? У вас есть волшебные приемы, позволяющие делать это через Selenium?

Эппл:Никакой магии, к сожалению. Если не считать огромное количество проделанной работы волшебством. Наши JavaScript API торчат наружу, и мы можем использовать Selenium для их тестирования. Еще есть программа определения различий pdiff, которая помогает в тестировании отображения превью, определения границ экрана и прочего. Мы делаем серьезную промежуточную обработку потока HTTP для прослушивания трафика, чтобы больше знать об изменениях на странице. Фреймворки As3Unit и FlexUnit помогают нам проверять различные состояния приложения и сравнивать графические изображения. Я бы хотела назвать это магией, но чтобы все это стало реальным, написано очень много кода.

– Какой самый серьезный баг нашла и не пустила к пользователям твоя команда?

Эппл:Самые серьезные баги обычно не так интересны. Был забавный баг в CSS, из-за которого браузер IE вылетал. До этого мы еще никогда не видели, чтобы баги CSS приводили к аварийному завершению браузера.

Нам запомнился один коварный баг, который поймали во время запуска новой страницы просмотра в 2010 году. Когда пользователь в IE7 выводил курсор за пределы области воспроизведения, проигрыватель через какое-то время зависал. Это интересный случай, потому что пользователи столкнулись бы с этим, только если бы долго смотрели один видеоролик и двигали курсором. Тогда все постепенно начинало тормозить, пока проигрыватель не зависал окончательно. Оказалось, что проблемы возникали из-за обработчиков событий и ресурсов, которые не освобождались, многократно выполняя одни и те же вычисления. Если пользователь смотрел короткие ролики или сидел спокойно и не двигал мышкой, баг не проявлялся.

– Расскажи о самом успешным и самом неуспешном моментах тестирования YouTube.

Эппл:Самым успешным был инструмент для получения и проверки проблемных URL-адресов. Эти простые тесты очень сильно помогли нам быстро отлавливать критические баги. Мы добавили фичу, которая упрощала отладку тем, что выдавала данные трассировки стека. Разработчикам стало проще выявлять причины проблем и исправлять их. Этот инструмент стал нашим первым флангом защиты при развертывании и сэкономил тестировщикам очень много времени. После небольшой доработки мы настроили его для самых популярных URL-адресов из наших логов и для добавочного списка URL-адресов, отобранных вручную. Это принесло много пользы.

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

– Сайт YouTube управляется данными, а большая часть контента определяется алгоритмами. Как вы следите за тем, чтобы правильные видеоролики отображались вовремя и в нужном месте? Твоя команда проверяет качество видеоматериала? Если проверяет, то как вы это делаете?

Эппл:Мы анализируем, сколько раз и какие видеоролики просматриваются, их связи друг с другом и много других переменных. Мы изучаем, как справляется буфер с данными, ошибки кэша, и на основании полученных данных оптимизируем свою глобальную инфраструктуру.

У нас есть юнит-тесты для проверки качества видео. После моего прихода наша команда написала инструмент AS3 Player Helper для углубленного тестирования этого аспекта. Приложение распространяется с открытым кодом. [64]64
  Исходный код AS3 Player Helper доступен по адресу http://code.google.com/p/youtube-as3-player-helper/source/checkout


[Закрыть]Оно построено на тестах FlexUnit, которые используют встроенный проигрыватель YouTube, воспроизводят им тестовые видеоролики и выдают информацию о состоянии проигрывателя и свойствах ролика. В тестовые ролики зашиты большие штрихкоды, они помечают кадры и отрезки времени. Их легко распознать даже после сжатия и потери качества. Еще один прием, чтобы оценить состояние видео, – это делать снимки видеокадров и анализировать их. Мы проверяем правильность пропорций и кадрирования, ищем деформации, искажения цвета, пустые кадры, белые экраны, проблемы синхронизации и т.д. Так эти проблемы оказываются в наших баг-репортах.

– Какой совет ты бы дала другим тестировщикам веб, приложений на базе Flash и веб-служб, управляемых данными?

Эппл:Работая с тестовыми фреймворками или тест-кейсами, делайте их простыми. Изменяйте архитектуру итеративно вместе с развитием проекта. Не пытайтесь сразу решить все проблемы. Смело выбрасывайте то, что вам не подходит. Если тесты или инструменты слишком сложны в сопровождении, выбросьте их и постройте более гибкие. Следите за тем, сколько вы тратите на сопровождение и диагностику тестов. Соблюдайте правило 70-20-10: 70% малых юнит-тестов, которые проверяют один класс или функцию, 20% средних тестов, которые проверяют интеграцию одного или нескольких модулей приложений, и 10% больших тестов (тех, что обычно называют системными или сквозными), работающих на верхнем уровне и проверяющих работу приложения в целом.

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

– Скажи честно, тестирование для YouTube – шикарная работа? Целый день смотреть видеоролики с котиками…

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

Глава 4. Тест-менеджер

Итак, мы выяснили, что в Google есть инженеры по тестированию и разработчики в тестировании, которые играют на стороне пользователей и разработчиков соответственно. А сейчас мы поговорим о третьей роли, которая связывает и координирует их работу. Речь идет о тест-менеджере. Это в первую очередь инженер, которые вносит технический вклад в проект. В то же время именно через него взаимодействуют все команды, от разработчиков и выпускающих менеджеров до менеджеров продукта и технических писателей. Плюс ко всему тест-менеджер обладает управленческими навыками и помогает своим подчиненным в профессиональном росте. Пожалуй, это самая сложная должность в Google.

Кто такой тест-менеджер

Работа по тестированию проектов в Google на самом деле не выглядит так идеально, как описанная в этой книге ситуация, где каждый инженер занят только своим делом. На помощь приходит менеджер, который координирует работу тестировщиков и разработчиков в тестировании, – тест-менеджер. Немного о его месте в иерархии Google: он подчиняется директору по тестированию, у которого может быть несколько таких подчиненных, [65]65
  Когда мы писали книгу, в Google было шесть директоров по тестированию, у каждого в подчинении находилась небольшая группа тест-менеджеров. Последние обычно руководят рядовыми сотрудниками, но ведущие инженеры часто подчиняются непосредственно своему директору. Такая иерархия должна упрощать совместную работу. Кроме того, многие директора Google (а может, и все) иногда выполняют задачи как рядовые участники проектов.


[Закрыть]а Патрик Коупленд руководит всеми директорами по тестированию.

На роль тест-менеджера мы редко нанимаем людей снаружи, чаще стараемся вырастить их внутри компании. Сотрудники, пришедшие извне, обычно (но не всегда) стартуют с позиции без подчиненных. Даже Джеймс Уиттакер, который был нанят на позицию директора, почти три месяца не имел подчиненных.

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

Итак, наш первый совет – знайте свой продукт. Тест-менеджер должен быть готов ответить на любые вопросы по использованию своего продукта. Допустим, вы – тест-менеджер Chrome. Если вас спросят, как установить расширение, сменить оформление браузера, настроить синхронизацию, изменить настройки прокси-сервера, просмотреть DOM, найти хранилище cookie, поставить новую версию, то ваши ответы должны отскакивать от зубов. Хороший руководитель знает о своем продукте все – от пользовательского интерфейса до внутренних подробностей работы дата-центров.

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

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

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

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

В тестировании программных продуктов в Google работает такая же схема. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности.

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

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