Шрифт:
— Будет исправлена позднее (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 оставляет команде право самой организовать работу с багами.
43
Процесс, по которому мы устанавливаем, в каком порядке рассматривать баги, и принимаем решения о том, кто и в каком порядке будет ими заниматься. Схож с процессом установления очередности оказания скорой медицинской помощи в больницах и даже обозначается тем же термином «triage».
Рис. 3.24. Основной процесс устранения багов при работе с Buganizer
Проекты Google обычно находятся в одном из двух состояний: новый проект с быстрой разработкой, где поток проблем непрерывен, или проект с устоявшейся инфраструктурой и постепенными выпусками. В последнем случае объем юнит-тестирования и меры предотвращения багов сводят количество ошибок к минимуму.
Мечта создать единую панель отслеживания багов преследовала нас в Google, как идея о создании философского камня — алхимиков. Каждый год кто-нибудь пытается построить общую информационную панель для багов всех проектов. Это имело бы смысл, если бы речь шла только о данных из Buganizer. Но разные команды имеют свои представления о том, какие метрики важны для выпуска и сопровождения проектов, поэтому эти начинания с треском проваливались. Может быть, эта идея могла бы сработать в более однородной компании, но в Google такие благие намерения разбиваются о великое разнообразие проектов и практик.
Команда Google Feedback [44] (http://www.google.com/tools/feedback/intl/en/index.html) запустила новый подход к регистрации багов в масштабе всего Google. С помощью Google Feedback конечные пользователи сообщают о багах в некоторых сервисах Google. Идея в том, что внешние пользователи не знают, какие баги уже были заведены или исправлены, но мы хотим быстро и легко получать обратную связь от них. Соответственно тестировщики и разработчики Google сделали так, чтобы сообщение о багах осуществлялось по простому принципу «навести и кликнуть». Инженеры команды очень постарались, чтобы пользователи при отправке сообщений о багах в Google могли скрыть те части страницы, где видна их конфиденциальная информация (пример на рис. 3.25).
44
Интервью с Брэдом Грином, техническим менеджером Google Feedback, можно прочитать в главе 4.
Команда Google Feedback здорово потрудилась над тем, чтобы наши базы данных не затопило бушующим потоком багов. Количество дубликатов могло бы просто застопорить процесс приоритизации. Они внедрили кластерные алгоритмы, чтобы автоматически группировать дубликаты и определять самые частые проблемы. За неделю после выпуска новой версии могли поступить десятки тысяч сообщений, которые в итоге сводились всего к десятку основных проблем. Это сэкономило уйму времени, и Google смог услышать своих пользователей без индивидуальной обработки каждого сообщения. Команда сейчас тестирует работу этой системы на нескольких продуктах, но собирается расширить ее на все ресурсы Google.