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

[Только для чтения] Имя пользователя или сотрудника 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)

[Обязательно до разрешения проблемы] Каждой проблеме назначается один человек, который имеет право отметить ее как решенную. Этот человек должен быть назначен до того, как проблема будет готова к решению. Проверяющий — единственный человек, который может установить статус «Проверена» и закрыть баг. Проверяющий и ответственный могут быть одним человеком. Посмотрим на жизненный цикл бага.

Чем отличается обработка багов в Google от такого же процесса в других компаниях?

— Мы открыты. База данных багов практически полностью открыта. Любой сотрудник Google может просмотреть любой баг любого проекта.

— Перед багом все равны. Сообщения о багах могут создавать все, включая технических директоров и старших вице-президентов. Сотрудники Google заносят в систему баги в продуктах, которые они используют, даже если они не являются частью команды этого продукта. Внутренние пользователи часто атакуют приложения просто для того, чтобы причинить им пользу.

— Свобода выбора. В Google нет предписанных сверху схем работы с багами. Процесс приоритизации[43] багов зависит от команды. Иногда это индивидуальная задача, иногда она решается между тестировщиками и разработчиками в неформальном разговоре. Приоритизация может быть частью еженедельной или ежедневной планерки. Нет формальных методов, электронных очередей или Большого Брата, контролирующего работу команд. Google оставляет команде право самой организовать работу с багами.

Рис. 3.24. Основной процесс устранения багов при работе с Buganizer