Джеймс Уиттакер - Как тестируют в Google

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

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

На рис. 3.18 мы видим, что есть много багов с приоритетом P2, [42] Как и во многих багтрекинговых системах, для определения приоритета ошибки мы используем запись PX (где P — от слова priority, X — целое число). Ошибки P0 — самые сложные, ошибки P1 менее серьезны и т.д. значительно меньше багов 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.

Как бы там ни было, а Buganizer — это самый долгоживущий и широко используемый компонент инфраструктуры тестирования в Google. В целом это типичная багтрекинговая система, но она поддерживает наш жизненный цикл отслеживания проблем в наших продуктах, от обнаружения до разрешения и создания регрессионных тест-кейсов. Чтобы система Buganizer работала быстро с нашими объемами, мы используем новейшие технологии хранения данных Google.

Рис. 3.21. Зависимость количества исправленных багов от времени. График похож на график количества обнаруженных багов, и это хорошо!

Рис. 3.22. Поиск в Issue Tracker

Рис. 3.23. Открытый баг в Issue Tracker

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

— Назначен (Assigned to, Assignee)

[Не обязательно] LDAP-аккаунт сотрудника, который должен сделать следующий шаг в обработке этого запроса. Этот человек автоматически получит сообщение при создании проблемы и каждый раз, когда кто-то изменит значение любого поля. У каждого компонента есть ответственный по умолчанию.

— Поставить в копию (CC)

[Не обязательно] Любое количество (ноль или более) LDAP-аккаунтов сотрудников, которых нужно информировать о создании или изменении проблемы. Имена задают в формате LDAP или имен почтовых ящиков без @google, поэтому можно ввести только действующие аккаунты. Элементы списка разделяются запятыми. Не нужно включать имя из поля «Назначен» при регистрации проблемы, потому что этот человек и так получит письмо.

— Вложения (Attachments)

[Не обязательно] Документы, прикрепляемые при создании бага (ноль или более). Принимает любой тип файлов, их количество может быть любым, но размер всего приложения не должен превышать 100 Мбайт.

— Блокирует (Blocking)

[Не обязательно] ID багов, решению которых препятствует этот баг. Элементы списка разделяются запятыми. Обновление такого списка автоматически обновляет поле «Зависит от» перечисленных багов.

— Зависит от (Depends On)

[Не обязательно] ID багов, которые должны быть исправлены до исправления этого бага. Обновление списка приводит к автоматическому обновлению поля «Блокирует» перечисленных багов. Элементы этого списка тоже разделяются запятыми.

— Дата изменения (Changed)

[Только для чтения] Дата и время последнего ручного изменения любого из полей проблемы.

— Изменения (Changelists)

[Не обязательно] Ноль или более номеров коммитов кода, связанных с решением проблемы. Указываются только коммиты, которые уже залиты в репозиторий.