Уиттакер . - Как тестируют в 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.

Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.

— Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?

Линдси:Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.

Как только все документы просмотрены, я начинаю изучать состояние проекта, а конкретно — его состояние качества. Я смотрю на количество багов, как они сгруппированы. Смотрю на типы открытых багов: какие из них открыты дольше всего, какие созданы недавно — и пытаюсь определить соотношение числа найденных и исправленных багов.