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

Вместе с Buganizer мы получили новую гибкую n-уровневую иерархию компонентов взамен простой иерархии «проект компонент версия», которая была в BugDB (да и во всех остальных коммерческих багтрекинговых системах того времени). Стало проще учитывать и отслеживать баги, появился новый жизненный цикл рассмотрения и сопровождения багов. Упростилось отслеживание групп багов — теперь мы могли создавать и управлять целыми списками, строить диаграммы и отчеты. Разработчики реализовали полнотекстовый поиск, историю изменений, настройки «по умолчанию» при создании бага. В целом использовать новую систему стало намного удобнее, пользовательский интерфейс стал интуитивно понятным. Плюс с добавлением аутентификации повысилась безопасность.

Немного подробнее о Buganizer

Самый старый баг, зарегистрированный в Google, создан 18 мая 2001 года в 15:33 и существует до сих пор. Он называется «Test Bug», а его описание выглядит как «First Bug!». Смешно, что этот баг до сих пор случайно всплывает, когда разработчики привязывают исправленные баги к своим коммитам.

Самый старый из активных поныне багов был зафиксирован в марте 2009 года. В нем предлагается исследовать проблемы производительности для снижения задержки отображения рекламы с учетом локации пользователя. В последнем комментарии к этому багу написано, что вопрос может быть исследован, но это потребует архитектурной работы, а вообще — метрики задержки вполне допустимы. Это было в 2009 году.

Посмотрите на диаграммы багов в Google. Одни баги были заведены автоматически, другие вручную. Диаграмма показывает сводную информацию. Автоматизация явно лидирует, и хотя мы не выделяли данные по отдельным командам, эти диаграммы все равно довольно интересны.

Рис. 3.18. Распределение багов в Buganizer по приоритетам

На рис. 3.18 мы видим, что есть много багов с приоритетом P242, значительно меньше багов P1 и совсем мало багов P0. Корреляция необязательно подтверждает причину-следствие, но вполне может быть признаком того, что инженерная методология, описанная в этой книге, действительно работает. Конечно, можно подумать, что люди просто не заводят баги с высокими приоритетами, но в реальной жизни это не так. А вот баги P3 и P4 часто не заносятся в систему, так как на них редко обращают внимание.

Средний возраст багов на рис. 3.19 тоже показывает вполне ожидаемую картинку. Заметили аномалию в области багов P0? Все просто: на практике баги P0 часто трудно исправить, поскольку это серьезные просчеты в проектировании и развертывании, сложные для отладки и решения. Срок жизни остальных багов зависит от их приоритета: чем меньше важность бага, тем дольше его могут исправлять.

Рис. 3.19. Средний возраст багов в Buganizer

Диаграмма зависимости количества багов от времени (рис. 3.20) показывает постоянный небольшой рост. Мы не знаем точно, почему это происходит. Наверное, у нас становится больше кода. С другой стороны, количество багов растет не так быстро, как количество разработчиков и тестировщиков. Может быть, наш код и становится лучше из-за контроля качества, а может быть, мы просто их не находим.

График исправления багов на рис. 3.21 показывает нам, что команды обычно справляются с ростом багов. Многие команды просто перестают добавлять новые фичи, когда скорость появления багов начинает превышать пропускную способность команды по их исправлению. Мы рекомендуем всем перенять эту практику, а не фокусироваться только на фичах и поставленных датах завершения. Чтобы держать число багов под контролем, сосредоточьтесь на маленьких фрагментах тестируемого кода, тестируйте инкрементально и отдавайте продукт внутренним пользователям как можно раньше.

Рис. 3.20. Зависимость количества багов от времени

Как только продукты Google становятся открытыми (к примеру, Chrome и Chrome OS), нам уже не удается вести единую базу данных багов. В этих проектах используются базы данных багов, доступные извне, — Bugzilla для проблем WebKit и Issue Tracker для проблем chromium.org. Мы в Google подталкиваем наших сотрудников заводить баги из любых продуктов Google, независимо от того, работают ли они на этом проекте. Наша главная цель — сделать интернет лучше.

Issue Tracker — основной репозиторий для всех багов Chrome и Chrome OS. Эта багтрекинговая система открыта публично: информацию об исправлении багов может получить любой желающий, даже пресса. Мы иногда скрываем баги безо­пасности до их исправления, чтобы не раззадоривать хакеров, но в остальном доступ к базе данных открыт. Внешние пользователи могут свободно заводить баги, и для нас это ценный источник информации. На рис. 3.22 и 3.23 показан процесс и результат поиска бага, связанного с логотипом Chrome в окне About.