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

— Назначен (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).