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

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

Рис. 3.49. Сквозной процесс бесплатного тестирования

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

Когда Джеймс Уиттакер пришел в Google, первым делом он организовал внутреннюю встречу технических специалистов и рассказал, каким он видит будущее тестирования. В его понимании тестирование должно напоминать видеоигры: как и в шутерах от первого лица, на тестируемое приложение должна накладываться полная контекстная информация. Мало кто мог представить, что его доклад на конференции GTAC [61] Презентация Джеймса Уиттакера на конференции GTAC, посвященная будущему тестирования, доступна на YouTube по адресу http://www.youtube.com/watch?v=Pug_5Tl2UxQ задаст тон работе на несколько лет вперед. Конечно, на слайдах его идеи смотрелись хорошо, но построение общего решения для всех клиентских приложений казалось делом очень дорогим и сложным.

Я скептически относился к смелым идеям Джеймса, пока вдруг не осо­знал, что уже могу почти моментально реализовать их в браузере для веб-приложений с помощью API новых расширений Chrome. Идея захватила меня настолько, что всю следующую неделю я провел в работе над прототипом. Я даже приостановил свою текущую работу и провел выходные в Starbucks, неистово программируя. Сотрудники кофейни интересовались у меня, не ищу ли я работу в интернете, и мне оставалось только постучать по дереву.

Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine [62] App Engine — облачный сервис Google для размещения сайтов и сервисов. Тестировщики часто используют App Engine для инструментов и инфраструктуры, так как App Engine может очень быстро наладить работу приложения и дать возможность пользоваться Google Scale бесплатно. Можно посмотреть на http://appengine.google.com. В настоящее время поддерживаются языки Java, Python и Go. и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов:

— наложение информации о багах на страницу и даже на ее конкретные элементы;

— наложение тест-кейсов на тестируемую страницу с одной кнопкой для результата теста (рис. 3.50);

— тепловую карту, на которой было видно, чем раньше занимались другие тестировщики и какие значения использовали (рис. 3.51).

Рис. 3.50. Пользовательский интерфейс тестовых примеров

Рис. 3.51. Тепловая карта тестового покрытия

Технология заработала на google.com, и я начал пробовать ее на нескольких других сайтах, чтобы убедиться в ее работоспособности. Я назначил короткую неформальную встречу с Джеймсом, чтобы показать результаты своей работы и узнать, что он о них думает. Мы исписали всю доску тем, что потом стало планом для экспериментов, описанных в этой книге. Я отправил Пату Коупленду и Джеймсу письма, в которых сообщил, что теперь буду заниматься этой работой и отчитываться перед Джеймсом. Никаких вопросов не было — изменения были согласованы по почте.

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

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

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

Хорошим примером такой работы служит Chrome OS. Мы с самого начала поняли, что сетевые подключения Wi-Fi и 3G — очень рискованная область, потому что она зависит от производителя устройства. Облачное устройство без связи с интернетом теряет свой смысл как продукт. Более того, все обновления безопасности и версий программных продуктов тоже происходят по Сети, и если возникают проблемы с передачей данных по 3G, наша работа обесценивается. Это не та вещь, которую можно оставить на откуп неспециалистам, пусть и с благими намерениями.

Когда мы только начинали работать с устройствами, своих специалистов с нужным тестовым оборудованием у нас еще не было. Впрочем, даже если бы оно было, правильно его использовать все равно никто не умел. Поэтому тестирование проводили внешние специалисты, которые вручную переключались между 20 современными роутерами Wi-Fi. За пару недель эти ребята сообщили нам о многочисленных проблемах при переключении роутеров и о снижении скорости передачи, если квартира пользователя находится в зоне действия нескольких роутеров. [63] Спасибо Райану Хоупсу и Томасу Флинну из Allion Test Labs за помощь с тестированием и сертификацией оборудования и сетевой поддержки. Конечно, были и другие проблемы, обнаруженные тестированием, но не такие важные. Мы получили графики, которые свидетельствовали о серьезном падении скорости передачи (примерно как на рис. 3.52 и 3.53).