Когда Джеймс Уиттакер пришел в Google, первым делом он организовал внутреннюю встречу технических специалистов и рассказал, каким он видит будущее тестирования. В его понимании тестирование должно напоминать видеоигры: как и в шутерах от первого лица, на тестируемое приложение должна накладываться полная контекстная информация. Мало кто мог представить, что его доклад на конференции GTAC[61] задаст тон работе на несколько лет вперед. Конечно, на слайдах его идеи смотрелись хорошо, но построение общего решения для всех клиентских приложений казалось делом очень дорогим и сложным.
Я скептически относился к смелым идеям Джеймса, пока вдруг не осознал, что уже могу почти моментально реализовать их в браузере для веб-приложений с помощью API новых расширений Chrome. Идея захватила меня настолько, что всю следующую неделю я провел в работе над прототипом. Я даже приостановил свою текущую работу и провел выходные в Starbucks, неистово программируя. Сотрудники кофейни интересовались у меня, не ищу ли я работу в интернете, и мне оставалось только постучать по дереву.
Вскоре у меня была рабочая демоверсия с расширением Chrome, которая работала с Python App Engine[62] и моделировала обращения к базе данных багов. Мне удалось продемонстрировать несколько интересных моментов:
— наложение информации о багах на страницу и даже на ее конкретные элементы;
— наложение тест-кейсов на тестируемую страницу с одной кнопкой для результата теста (рис. 3.50);
— тепловую карту, на которой было видно, чем раньше занимались другие тестировщики и какие значения использовали (рис. 3.51).
Рис. 3.50. Пользовательский интерфейс тестовых примеров
Рис. 3.51. Тепловая карта тестового покрытия
Технология заработала на google.com, и я начал пробовать ее на нескольких других сайтах, чтобы убедиться в ее работоспособности. Я назначил короткую неформальную встречу с Джеймсом, чтобы показать результаты своей работы и узнать, что он о них думает. Мы исписали всю доску тем, что потом стало планом для экспериментов, описанных в этой книге. Я отправил Пату Коупленду и Джеймсу письма, в которых сообщил, что теперь буду заниматься этой работой и отчитываться перед Джеймсом. Никаких вопросов не было — изменения были согласованы по почте.
Все следующие эксперименты проводились по той же схеме — каждый инженер отвечал за свое задание и, если хотел, привлекал других. Главная задача управления — добиться того, чтобы работа могла быть применима повторно, была гибкой и ею без проблем могли бы воспользоваться другие люди. Постоянно просите инженеров мыслить масштабно при любой работе!
Культура Google поощряет обмен идеями, поддерживает инициативу снизу, а организационная гибкость дает плодородную почву для экспериментов. Никогда не знаешь, чем это закончится, пока не попробуешь идею на реальных инженерных задачах. Мы понимаем это и даем инженерам возможность ставить любые эксперименты, с условием, что они знают, как оценить их успешность.
В Google работает много талантливых ребят, но мы отлично понимаем, что и наши возможности имеют пределы. Новые амбициозные проекты появляются без предупреждения, и им часто нужны узкоспециализированные профессионалы для тестирования. Мы не всегда можем быстро переквалифицировать наших людей или нанять новых, продукт нужно выпускать быстрее. Google разрабатывает продукты во многих областях: от гаджетов до корпоративного ПО, от операционных до платежных систем. Задач множество — пересобрать ядро операционной системы, изменить пользовательский интерфейс, проверить, работает ли устройство со всеми телевизорами на рынке, — и везде нужны специалисты. Мы понимаем, что иногда нам нужна помощь со стороны, поэтому обращаемся к внешним компаниям-подрядчикам.
Хорошим примером такой работы служит Chrome OS. Мы с самого начала поняли, что сетевые подключения Wi-Fi и 3G — очень рискованная область, потому что она зависит от производителя устройства. Облачное устройство без связи с интернетом теряет свой смысл как продукт. Более того, все обновления безопасности и версий программных продуктов тоже происходят по Сети, и если возникают проблемы с передачей данных по 3G, наша работа обесценивается. Это не та вещь, которую можно оставить на откуп неспециалистам, пусть и с благими намерениями.
Когда мы только начинали работать с устройствами, своих специалистов с нужным тестовым оборудованием у нас еще не было. Впрочем, даже если бы оно было, правильно его использовать все равно никто не умел. Поэтому тестирование проводили внешние специалисты, которые вручную переключались между 20 современными роутерами Wi-Fi. За пару недель эти ребята сообщили нам о многочисленных проблемах при переключении роутеров и о снижении скорости передачи, если квартира пользователя находится в зоне действия нескольких роутеров.[63] Конечно, были и другие проблемы, обнаруженные тестированием, но не такие важные. Мы получили графики, которые свидетельствовали о серьезном падении скорости передачи (примерно как на рис. 3.52 и 3.53).
Мы не ожидали резких скачков интенсивности сигнала, но, как видите на рисунке, они были. Разработчики использовали эти данные для решения проблем во время внутреннего тестирования.
Рис. 3.52. Ожидаемый график зависимости скорости передачи от диапазона
Рис. 3.53. График зависимости скорости передачи от диапазона в ранних прототипах Chrome OS
Кстати, даже инженеры начального уровня в Google могут привлечь к работе внешних специалистов. Такая способность быстро решать задачи помогает нам быстро выпускать версии наших продуктов. Сейчас у нас есть все необходимое для того, чтобы выполнить работу самим, продолжая то, что начали внешние ребята. Но все же именно то, что мы смогли быстро подключить их экспертизу, стало основной причиной стабильно работающего сетевого соединения в боевых условиях к моменту запуска Chrome OS.
Работа с внешними тестировщиками может не только обнаружить неожиданные дефекты продукта, но и принести столь же неожиданную выгоду. Например, мы попросили их проверить наш список тестов пригодности оборудования. Поставщики оборудования по нашей просьбе отрабатывают эти тесты у себя перед тем, как отправить устройства в Google для дальнейшего тестирования. Такая схема работы избавляет нас от лишних пересылок оборудования туда-сюда. Итак, наши внешние специалисты заметили, что некоторые важные части в тестах были упущены. Ребята здорово помогли нам и отшлифовали наши тест-кейсы в соответствии с принятыми стандартами в этой области. В результате наши первые тесты, переданные крупным производителям компьютеров, стали полными и читались легче. Получается, что выгодно быть скромным и не стесняться обратиться за помощью в тестировании к внешним специалистам.
Интервью с инженером по тестированию Google Docs Линдси Уэбстер
Линдси Уэбстер — инженер по тестированию проекта Google Docs в нью-йоркском офисе Google. В компании ее знают как инженера-практика, способного привести в порядок процедуру тестирования в любой команде разработчиков. Ее подход к работе и умение влиять на команду и качество продукта сделали ее символом инженеров по тестированию в Google.
Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.
— Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?
Линдси: Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.
Как только все документы просмотрены, я начинаю изучать состояние проекта, а конкретно — его состояние качества. Я смотрю на количество багов, как они сгруппированы. Смотрю на типы открытых багов: какие из них открыты дольше всего, какие созданы недавно — и пытаюсь определить соотношение числа найденных и исправленных багов.
— Число багов на разработчика или на всю команду?
Линдси: На всех! Если честно, чтобы достигнуть максимальных результатов, команду надо знать как свои пять пальцев.
Еще я изучаю код в репозитории: ищу подходящие юнит-тесты для каждого класса. Проходят ли эти тесты? Насколько эти тесты содержательны и полны? Есть ли интеграционные или сквозные тесты? А проходят ли они до сих пор? Насколько успешно они проходили раньше? Это самые простые, базовые сценарии или они покрывают и частные случаи? Какие ветки в репозитории меняются чаще всего? Какие из них давно не менялись? Обычно разработчики хорошо документируют все, что они делают по тестированию.
