Рассмотрите включение поля «Исправить к дате» для установления приоритетов на основе критерия времени. Значения, помещаемые в это поле, могут браться на основе внутреннего графика выпуска проекта, например, здесь может быть указан определённый этап, бета-версия или кандидат на выпуск. Чтобы определиться с приоритетом, задайте себе вопросы: «эту проблему нужно решить к этапу 2 или бета-версии 1?», «Что, если мы выпустим продукт сейчас, а ошибку исправим в следующем выпуске?»
С течением цикла разработки следует назначать для каждой ошибки конкретный срок исправления. Поступая так, вы без труда получите текущий список неисправностей для любого выпуска, в том числе для следующего.
Проверяйте и исправляйте ошибки
Одна из главных задач, выполняемых при контроле качества, — проверка того, что ошибки на самом деле исправлены. На этом этапе мы убеждаемся в том, что разработчик действительно осознал проблему и провёл достаточное количество испытаний. Когда ошибка исправлена и соответствующие изменения внесены в исходный код, разработчик устанавливает значение поля «Контролю качества: подтвердить» на «Истина», а статус — на «Ожидается процедура контроля качества». После того, как система контроля качества проверила исправление ошибки, тестировщик устанавливает её статус «Закрыто». Проблема может быть закрыта только системой контроля качества после соответствующей проверки.
Используйте замечания по выпуску
Когда мы сталкивались с неполадкой, которую следует описать в замечаниях по выпуску или файле Read Me, мы изменяли её статус на «Release Notes», но оставляли её открытой. В примечаниях по выпуску описываются известные проблемы, способы их обойти и информация, появившаяся в последний момент и не попавшая в официальную документацию. Когда наступал момент выпуска бета-версии или окончательной версии, было очень просто составить список проблем, о которых следует указать в замечаниях по выпуску. И только после того, как проблему разрешили, мы окончательно её закрывали.
Используйте стандартные запросы
Чтобы осуществлять полноценный поиск по базе данных проекта, важно иметь набор стандартных запросов. Эти запросы должны использоваться совместно и быть доступны всем членам команды; важно, что у каждого будет одинаковая картина данных. Хотя частные запросы хороши для редких и особых требований, их не следует использовать для распределения заданий членам команды. Риск неправильного составления запроса или указания неиспользуемого более поля достаточно велик. В таблице представлены наиболее важные запросы.
Все открытые ошибки
Позволяет менеджеру проекта и руководству оценить проект в целом
Все открытые ошибки для конкретного этапа
Позволяет команде увидеть, какие ошибки остаются открытыми в проекте для заданного этапа.
Все открытые ошибки для конкретного человека
Позволяет каждому человеку просмотреть свой текущий список ошибок
Все открытые ошибки для конкретного этапа и человека
Позволяет каждому человеку просмотреть свой список ошибок для заданного этапа.
Все открытые ошибки тестировщиков с полем «Контролю качества: проверить» = «Истина»
Позволяет команде просмотреть свой план тестирования
Все открытые ошибки с полем «Предложения» = «Истина»
Позволяет менеджеру проекта и руководству пересмотреть текущие предложения по изменениям
Другие способы применения
Далее приведены другие важные способы использования информации, попадающей в базу данных проблем и неисправностей. Эта информация поможет менеджеру проекта и руководству оценить мероприятия по проекту на макроуровне, а также другие проблемы, съедающие значительную часть времени. В цикле разработки команда обрабатывает сотни, а может, и тысячи ошибок и проблем, и поэтому понимание того, что же всё-таки происходит с течением времени, может быть очень ценно.
Интенсивность возникновения и устранения ошибок
Интенсивность возникновения — это мера того, сколько новых ошибок или неисправностей было обнаружено за определённый период времени. Интенсивность возникновения взлетает вверх в начале проекта, но с течением времени снижается. Интенсивность устранения — это мера того, сколько ошибок или неисправностей закрыто за определённый период времени. Она снижается по мере устранения ошибок. Ниже показана интенсивность возникновения и устранения ошибок — для проекта эти данные могут быть весьма полезны (рис. 5-1 и 5-2).
Рис. 5-1. Интенсивность возникновения и устранения ошибок в начале проекта.
Рис. 5-2. Интенсивность возникновения и устранения ошибок в моменты, когда проект близится к завершению определённого этапа.
Как соотносятся интенсивность возникновения и устранения ошибок? В начале проекта вы столкнётесь с массой новых проблем, которые обнаруживаются (открываются) быстрее, чем устраняются (закрываются). По ходу работы интенсивность возникновения по отношению к интенсивности устранения перестанет расти и снизится, так как существующие проблемы будут закрываться быстрее, чем новые будут обнаруживаться. Особого внимания требуют резкие скачки, которые могут проявляться в определённый период. Рассмотрите проблему, зафиксированную в этот период, чтобы определить, не она ли породила ещё большее количество новых ошибок.
Обычно, когда близится завершение внутреннего этапа, выпуск бета-версии и кандидата на выпуск, интенсивность устранения выше интенсивности возникновения. Если это не так, то новых проблем появляется больше, чем решается, а это не то, что вы бы хотели видеть, приближаясь к периоду стабилизации или выпуску.
Интенсивность устранения поможет вам определить эффективность обнаружения причин возникновения неполадки, а также примерный срок устранения ошибок, которые могут появиться в будущем. Скажем, если интенсивность устранения в течение двух последних недель составляла 10 ошибок в день, это может быть большим успехом. Если у вас 100 открытых ошибок, то вполне закономерно ожидать, что все они будут устранены приблизительно в течение следующих 10 дней. Эта цифра конечно же не точна (для исправления какой-нибудь неполадки может потребоваться и неделя), но она позволяет понять, чего вам следует ожидать при наличии большого количества оставшихся ошибок.
Количество изменений
Количество изменений также может о многом поведать. Количество изменений показывает число обновлений информации о неполадке. Причина обновления не имеет значения. Большое число изменений — верный знак того, что не всё идёт так гладко. Так, оставшаяся неполадка может исследоваться многими людьми, и ни один из них не установит причину её возникновения. Возможно, её передавали из отдела технической поддержки к разработчикам, от тестировщиков — к разработчикам или между двумя разработчиками туда и обратно. Наблюдение за количеством изменений информации об ошибках поможет определить те, что требуют внимания со стороны ведущих специалистов и менеджера проекта.
Счётчик неудачных исправлений
Ещё один хороший способ оценки нестабильности проекта — счётчик неудачных исправлений для всех ошибок, которые считались исправленными, но на самом деле исправлены не были. При устранении неполадки от команды тестировщиков требуется подтверждение того, что ошибка действительно исправлена. Если проблема всё ещё существует или исправление не принято, ей возвращается статус открытой, а значение поля «Исправлено неудачно» устанавливается в 1. Если тестировщики снова не могут подтвердить устранения неполадки, значение счётчика увеличивается до 2 или 3. Это сигнализирует о серьёзности проблемы и говорит о необходимости вмешательства ведущих специалистов или менеджера проекта.
Дополнительные средства
Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в NuMega, мы регулярно использовали и другие инструменты.
Отладчики
Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.
