Как тестируют в Google
Шрифт:
[Не обязательно] Документы, прикрепляемые при создании бага (ноль или более). Принимает любой тип файлов, их количество может быть любым, но размер всего приложения не должен превышать 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)