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

Если процесс отслеживания багов и связанный с ним объем работы — это такая большая часть работы инженеров, понятное дело, хочется такой процесс автоматизировать. Первой попыткой подобной автоматизации в Google была система под названием BugsDB: простая база данных из нескольких таблиц и запросов, где можно было хранить и получать информацию и даже считать какую-то статистику. Системой BugDB пользовались до 2005 года, пока два предприимчивых инженера, Тед Мао41 и Рави Гампала, не создали Buganizer.

Вместе с 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 показывает нам, что команды обычно справляются с ростом багов. Многие команды просто перестают добавлять новые фичи, когда скорость появления багов начинает превышать пропускную способность команды по их исправлению. Мы рекомендуем всем перенять эту практику, а не фокусироваться только на фичах и поставленных датах завершения. Чтобы держать число багов под контролем, сосредоточьтесь на маленьких фрагментах тестируемого кода, тестируйте инкрементально и отдавайте продукт внутренним пользователям как можно раньше.