Джеймс Уиттакер - Как тестируют в Google

• Название: Как тестируют в Google
• Автор: Джеймс Уиттакер
• Издательство: Издательский дом "Питер"
• Жанр: Программирование
• Год: 2014
• ISBN: 978-5-496-00893-8

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

---

— Ты придумал и реализовал Buganizer,[30] багтрекинговую систему Google. Чего ты хотел добиться в первую очередь с помощью Buganizer и чем эта система была лучше старой BugDB?

Тед: Система BugsDB не только не поддерживала, а даже затрудняла наш процесс разработки. Честно говоря, на работу с ней уходило слишком много времени. Это была своего рода дань, которую она взимала с каждой команды. Она создавала проблемы по всем фронтам: пользовательский интерфейс тормозил, жизненный цикл бага был устроен ужасно, текстовые поля были плохо структурированы и требовали вводить данные особым образом. Проектируя Buganizer, мы позаботились о том, чтобы наша модель данных и пользовательский интерфейс отвечали реальным процессам разработки наших внутренних пользователей. Мы построили систему, которую можно было расширять в дальнейшем как саму по себе, так и с помощью интеграции.

— Итак, ты создал Buganizer. Правда, это лучшая багтрекинговая система, из всех, с которыми нам доводилось работать. А как ты начал заниматься автоматизацией веб-тестирования? Ты понял, что есть потребность, или тебя попросили решить проблему с выполнением тестов?

Тед: Занимаясь Buganizer, AdWords и другими продуктами Google, я постоянно наталкивался на то, что существующей инфраструктуры веб-тестирования не хватает для моей работы. Она никогда не была настолько быстрой, масштабируемой, надежной и полезной, насколько мне было нужно. Когда инструментальная команда объявила поиск рулевого для нового направления, я вызвался. Проект получил название Matrix, и я его возглавил.

— Сколько тестовых прогонов и команд поддерживает Matrix сегодня?

Тед: Зависит от того, как измерять количество прогонов и команд. Например, одна из наших метрик называется «сеанс браузера». Все новые сеансы одного конкретного браузера по умолчанию начинаются в одном состоянии, а значит, выполнение теста в браузере будет детерминировано так же, как сам тест, браузер и ОС. Matrix поддерживает больше миллиона сеансов браузера каждый день и используется почти всеми фронтенд-командами в Google.

— Сколько людей работало над этими двумя проектами: Buganizer и Matrix?

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

— Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?

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

— Что ты посоветуешь программистам, которые разрабатывают средства тестирования?

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

— Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?

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

Интервью с создателем WebDriver Саймоном Стюартом

Саймон Стюарт — создатель WebDriver и гуру браузерной автоматизации в Google. WebDriver — это опенсорс-инструмент для тестирования веб-приложений, который популярен как в Google, так и за его пределами. Исторически WebDriver — это одна из самых горячих тем на конференции Google Test Automation Conference.

Авторы встретились с Саймоном, чтобы узнать, что он думает об автоматизации тестирования веб-приложений и о будущем WebDriver.

— Мне кажется, многие люди не совсем понимают, в чем отличие Selenium от WebDriver. Ты можешь объяснить разницу?

Саймон: Джейсон Хаггинс начал проект Selenium, когда работал в ThoughtWorks.[31] Джейсон писал веб-приложение и ориентировался преимущественно на браузер IE, который занимал тогда больше 90% рынка. Но он постоянно получал сообщения о багах от пользователей, пересевших на Firefox, причем исправление ошибки для Firefox могло нарушить работу приложения в IE. Джейсон придумал Selenium как механизм, запускающий и тестирующий приложение в обоих браузерах.

Я начал разрабатывать WebDriver примерно через год после создания Selenium, но еще до того, как проект Джейсона вышел на стабильность. Я ориентировался на более общее тестирование веб-приложений, поэтому неудивительно, что мы выбрали разные способы реализации. Проект Selenium строился на запуске JavaScript-кода в браузере, а WebDriver сам интегрировался в браузер через API. У каждого подхода были свои достоинства и недостатки. Selenium почти сразу же мог работать с новыми браузерами, например с Chrome, но не умел загружать файлы и нормально обрабатывать действия пользователя. Все-таки возможности песочницы JS ограничены. Механизм WebDriver был встроен в браузер, поэтому он мог обходить эти ограничения, но добавлять другие браузеры было тяжело. Когда мы оба пришли в Google, мы решили объединить проекты.

— Но мы до сих пор слышим оба названия. Это все еще разные проекты?

Саймон: Selenium — это «зонтичный» проект, под которым мы выпускаем все инструменты браузерной автоматизации, среди которых есть и WebDriver. Официально он называется Selenium WebDriver.

— А как Google начал участвовать в этом?

Саймон: Когда открылся лондонский офис Google, туда пригласили работать нескольких бывших сотрудников ThoughtWorks. Они пригласили меня рассказать о WebDriver. Тот доклад у меня не удался — какой-то парень в первом ряду все время засыпал, и мне пришлось перекрикивать его храп в аудитории. Для полного счастья что-то произошло с аппаратурой, и мой доклад не записался. Несмотря на все злоключения, проектом заинтересовались, и меня пригласили провести презентацию уже без храпа на конференции GTAC. Вскоре я начал работать в Google. И теперь знаю все их страшные тайны.

— Ну конечно, все наши шкафы забиты скелетами. Вообще-то мы видели, как ты выступаешь, и не можем представить, чтобы кто-то заснул на твоем докладе. Мы его знаем?

Саймон: Нет. Он уже давно покинул Google. Будем считать, что у него выдалась тяжелая ночь.

— Пусть это будет уроком нашим читателям. Засыпать на докладе Саймона Стюарта вредно для вашей карьеры. WebDriver стал твоей основной работой, когда ты присоединился к Google?

Саймон: Нет, это был мой «двадцатипроцентный» проект. Хотя в основное время я был разработчиком в тестировании, мне удавалось двигать WebDriver вперед. Очень помогало участие разработчиков со стороны. На ранней стадии опенсорс-проекта людям приходится вкладываться в проект, потому что это единственный вариант его развития. Теперь многие пользователи WebDriver узнают о проекте от других и относятся к нему скорее как потребители, чем как участники. Но в те дни WebDriver развивался силами энтузиастов сообщества.

— Что ж, мы знаем, к чему это привело — WebDriver стал очень популярен в Google. С чего все началось? С одного пилотного проекта? Были фальстарты?

Саймон: Все началось с Wave — социального продукта, который был создан в нашем сиднейском филиале. С тех пор проект успели закрыть. Разработчики Wave попытались использовать Selenium в качестве тестовой инфраструктуры, но у них это не вышло. Wave оказался слишком сложным продуктом. Разработчики были достаточно упрямы, чтобы докопаться до WebDriver. Они начали задавать мне много вопросов. Хороших вопросов.

Работы стало больше, чем я мог выполнять в свои «20 процентов». Они переговорили с моим руководством и договорились о месячной командировке. Так я отправился в Сидней, чтобы помочь им построить тестовую инфраструктуру.