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

Самая приятная часть работы с ботами — сокращение времени между выкатыванием версии продукта и поимкой багов. Итак, если боты и тестировщики из сообщества могут работать круглосуточно, значит разработчики могут оперативно получать данные о последствиях своих изменений в коде. Так как сборка и установка происходят непрерывно, то легко определить, какая именно горстка изменений привнесла баг. К тому же все изменения еще свежи в голове разработчика, и процесс отладки прост и понятен.

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

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

Инновации и эксперименты в тестировании

Джеймс Арбон

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

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

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

Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine62 и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов:

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

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

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

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

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

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

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

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

Внешние тестировщики