Как тестируют в Google - Уиттакер .

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

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

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

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

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

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

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

— Насколько я понимаю, поездка увенчалась успехом.

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

— С первым пользователем всегда сложнее всего. Как ты справился с необходимостью разрабатывать WebDriver и одновременно адаптировать его для Wave?

Саймон: Я пользовался процессом DDD (Defect-Driven Development — разработка через дефекты). Я объявлял WebDriver бездефектным, а когда пользователь находил баг, я его исправлял и снова объявлял продукт бездефектным. Так я исправлял только по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.

— Ты так и остаешься единственным разработчиком WebDriver?

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

— Итак, после Wave вы набрали скорость. Именно в этот момент WebDriver стал отделяться от старой инфраструктуры Selenium? Мы имеем в виду в контексте пользователей.

Саймон: Думаю, да. Многие разработчики Selenium переключились на другие проекты, а у меня успех WebDriver с Wave вызвал приток энергии. Люди, которых я не знал лично, например Майкл Там из Германии, начали делать важную работу для WebDriver, и я старался бережно поддерживать эти отношения. Майкл стал первым человеком, не знакомым мне лично, который получил право заливать код в репозиторий проекта.

Но я не так уж пристально следил за распространением WebDriver. Понятно, что чем ближе команда находится ко мне физически, тем больше вероятность их перехода на WebDriver. Думаю, моими первыми пользователями еще до Wave стала команда Picasa Web Albums, а потом WebDriver подхватила команда Ads. По части использования веб-автоматизации в Google нет единства. Chrome использует PyAuto, Search использует Puppet (у которого есть версия с открытым кодом — Web Puppeteer), Ads использует WebDriver и т.д.

— Как насчет будущего WebDriver? К чему стремится ваша команда?

Саймон: Сейчас на поле вышло много игроков. Всего пару лет назад у нас был рынок с одним доминирующим браузером. Это в прошлом. Internet Explorer, Firefox, Chrome, Safari, Opera — далеко не все примеры, и это только десктоп. Браузеры на базе WebKit для мобильных устройств плодятся бешеными темпами. Коммерческие инструменты игнорируют все, кроме IE. Это кажется безумием, ведь 2008 год давно прошел. Следующим логичным шагом станет стандартизация WebDriver, чтобы мы могли гарантировать работу веб-приложений в разных браузерах. Конечно, было бы полезно сотрудничать с разработчиками браузеров, чтобы мы могли обеспечивать совместимость с WebDriver API.

— Похоже, это задача для комитета по стандартизации. Есть прогресс в этом направлении?

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

— Чего ты ожидаешь в будущем? Как средства автоматизации браузеров будут развиваться дальше?

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

13 Заметим, что даже для клиентских продуктов Google старается делать частые и надежные обновления с помощью автообновления, встроенного во все клиентские приложения.

14 Речь идет о Ларри Пейдже и Сергее Брине — основателях Google.

15 О том, как появилась роль разработчика в тестировании, Патрик Коупленд рассказывает в предисловии.

16 В Google есть официальная система распределения графика, благодаря которой любой сотрудник может тратить 20% своего рабочего времени на любой другой проект Google. Иными словами, четыре дня в неделю вы занимаетесь своей основной работой, а один день экспериментируете и изобретаете. Необязательно именно так распределять свое время, многие бывшие сотрудники Google вообще считали такой рабочий график мифическим. Однако каждый из авторов этой книги участвовал в «двадцатипроцентных проектах», значит, они — реальность. Более того, многие инструменты, описанные в книге, — результат «двадцатипроцентной» работы, которая со временем воплотилась в полноценные финансируемые проекты. Правда, многие сотрудники Google в свое «двадцатипроцентное время» просто работают с другими проектами, а не занимаются экспериментами, поэтому от такой концепции рабочего времени выигрывают многие. (К моменту издания книги на русском языке Google официально отменил эту систему. — Примеч. перев.)

17 Самым распространенным механизмом такого поощрения в Google является премия «от коллег». Любой инженер, которому помогла работа другого инженера, может назначить ему премию в благодарность. У руководителей тоже есть свои способы поощрения сотрудника. Смысл в том, что работу на благо сообщества нужно подпитывать! Конечно, не стоит забывать, что есть и неформальный способ поблагодарить коллегу — «услуга за услугу».

18 Это правило в Google нарушено только в лабораториях локального тестирования Android и Chrome OS, где для проверки новых сборок нужно иметь широкий спектр оборудования.

19 Protocol Buffer Google имеет открытую спецификацию, которая представлена тут: http://code.google.com/apis/protocolbuffers/

20 Версия Mondrian с открытым кодом на базе App Engine доступна по адресу: http://code.google.com/p/rietveld/

21 Руководство Google по стилю для C++ доступно по адресу: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

22 http://labs.google.com/papers/bigtable.html

23 http://labs.google.com/papers/gfs.html

24 http://code.google.com/apis/protocolbuffers/docs/overview.html

25 «Тестирование в туалете» (Testing on The Toilet) упоминалось ранее в этой книге. О нем часто пишут в блоге Google Testing по адресу googletesting.blogspot.com

26 «Починялки» (fixits) — еще один элемент культуры Google: это мероприятие собирает людей для починки чего-то сломанного или работающего неправильно. Например, группа может устроить «починялки» для сокращения количества ошибок. Или для тестирования безопасности. Или для расширения использования #include в коде C или рефакторинга. Цель встречи не ограничивается технической областью, и «починялки» могут проводиться для улучшения качества блюд в кафе или схемы проведения собраний. По сути, это любое мероприятие, на котором люди собираются для решения общей проблемы.