Уиттакер . - Как тестируют в Google
Как только продукты 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)
[Не обязательно] Ноль или более номеров коммитов кода, связанных с решением проблемы. Указываются только коммиты, которые уже залиты в репозиторий.
— Компонент (Component)
[Обязательно] Компонент, содержащий баг или запрос на реализацию функциональности. Здесь нужно указывать полный путь к компоненту, причем длина пути не ограничена.
Дополнительные компоненты могут создавать только руководители проекта или разработки.
— Дата создания (Created)
[Только для чтения] Дата создания бага.
— Обнаружен в (Found In)
[Не обязательно] Используется для контроля версий; в поле указывается номер версии продукта, в которой была обнаружена проблема (например, 1.1).
— Последнее изменение (Last modified)
[Только для чтения] Дата последней автоматической модификации любого поля проблемы.
— Заметки (Notes)
[Не обязательно] Подробное описание проблемы и комментарии по ходу ее решения. При регистрации проблемы нужно описать шаги для воспроизведения бага или путь к экрану, который требует изменений. Чем больше информации вы здесь укажете, тем меньше вероятность того, что разработчикам, которые будут решать эту проблему, придется связываться с вами. Редактировать предыдущие записи в поле «Заметки» нельзя, даже если это вы сами их добавили; поле «Заметки» поддерживает только добавление новых значений.
— Приоритет (Priority)
[Обязательно] Определяет важность бага, где P0 — самый серьезный баг. Приоритет показывает, насколько срочно нужно исправить баг и сколько ресурсов выделить для его исправления. Например, опечатка в слове «Google» на логотипе страницы поиска будет некритичной, так как функциональность страницы от нее не страдает, но высокоприоритетной. Такие опечатки — это очень плохо. Заполнение обоих полей позволит команде исправления багов разумно распределять свое время. Обратите внимание на описание поля «Критичность» для закрепления темы.
— Кем создан (Reported by, Reporter)
[Только для чтения] Имя пользователя или сотрудника Google, первым сообщившего о баге. По умолчанию в поле заносится аккаунт человека, который завел проблему, но оно может быть изменено позднее для чествования фактического первооткрывателя.
— Резолюция (Resolution)
[Не обязательно] Последняя операция, выполняемая проверяющим. Может принимать значения «Нереально» (Not feasible), «Работает как предполагалось» (Works as intended), «Не воспроизводится» (Not repeatable), «Информация устарела» (Obsolete), «Дубликат» (Duplicate) и «Исправлено» (Fixed).
— Критичность (Severity)
[Обязательно] Критичность определяет, как сильно баг мешает использованию продукта. S0 — самые критичные баги. Мы выставляем и приоритет, и критичность каждой проблеме, чтобы разработчики могли приоритизировать важность багов при исправлении. Помните наш пример с опечаткой в слове «Google»? Ошибка высокого приоритета, но некритичная. Значения критичности можно объяснить как:
— S0 = Система непригодна к использованию
— S1 = Высокая
— S2 = Средняя
— S3 = Низкая
— S4 = Не влияет на систему
— Статус (Status)
[Обязательно] Текущее состояние бага. Посмотрите на жизненный цикл бага на рис. 3.24, чтобы понять, как меняется значение этого поля. «Статус» бага может быть несколько видов.
— Новая (New): проблема была создана, но ответственный за ней еще не закреплен.
— Назначена (Assigned): назначен ответственный.
— Принята (Accepted): ответственный принял проблему.
— Будет исправлена позднее (Fix later): ответственный решил, что проблема будет исправлена позднее.
— Не будет исправлена (Will not fix): ответственный решил, что проблема по какой-то причине не будет исправлена.
— Исправлена (Fixed): проблема исправлена, но исправление не проверено.
— Назначен проверяющий (Verifier assigned): проблеме назначен проверяющий.
— Проверена (Verified): исправление проверено проверяющим.
— Описание (Summary)
[Обязательно] Общее описание проблемы. Оно должно быть как можно более понятным и однозначным; когда кто-нибудь просматривает список проблем, именно этот текст поможет решить, нужно ли дальше исследовать проблему.
— Исправить в (Targeted To)
[Не обязательно] Используется для контроля версий; поле заполняется номером версии продукта, в которой проблема будет исправлена (например, 1.2).
— Тип (Type)
[Обязательно] Типом проблемы может быть:
— Баг (Bug): из-за проблемы программа работает не так, как ожидалось.
— Запрос на реализацию функциональности (Feature request): нечто, что бы вы хотели добавить в программу.
— Проблема клиента (Customer issue): возникла в ходе обучения или общего обсуждения.
— Внутренняя чистка (Internal cleanup): требует сопровождения.
— Процесс (Process): автоматически отслеживается через API.
— Исправлен в (Verified In)
[Не обязательно] Используется для контроля версий; поле заполняется номером версии продукта, в которой исправление проблемы прошло проверку (например, 1.2).
— Проверяющий (Verifier)
[Обязательно до разрешения проблемы] Каждой проблеме назначается один человек, который имеет право отметить ее как решенную. Этот человек должен быть назначен до того, как проблема будет готова к решению. Проверяющий — единственный человек, который может установить статус «Проверена» и закрыть баг. Проверяющий и ответственный могут быть одним человеком. Посмотрим на жизненный цикл бага.
