Должны ли мы отслеживать дефекты не в коде?

Да, отслеживайте их все.

Документация, проектная документация, требования и т. д.

Я также удивляюсь, как и вы, когда слышу «аргументы» против этого. По крайней мере, система отслеживания должна быть способна определить, где был обнаружен дефект и в какую часть процесса он был внедрен.

Определенно да. Артефакты, окружающие ваш код - модели, спецификации, документация, информация о требованиях, варианты использования и т. д. - могут содержать ошибки, которые влияют на сам код.

Обычно системы отслеживания ошибок предполагают, что они представляют собой список вещей, которые необходимо исправить или реализовать. Отслеживание ошибок в требованиях или другой документации (например, списках задач) не похоже на одно и то же. Это больше вопрос ведения записей, чтобы вы могли отслеживать проблемы и оценивать, делаете ли вы их меньше.

Я отслеживаю их, но вне нашей системы отслеживания ошибок.

Ну да ... все, что можно улучшить, делайте все, что можно, чтобы улучшить!

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

Обычно я отслеживал источник всех дефектов. Они могут быть исправлены в коде, но не обязательно вызваны этим.

Неправильное требование, неправильно интерпретированное требование, плохой дизайн, мозг разработчика, плохая документация, неправильный тест, отсутствующий тест, устаревший тест, код, который не выполняет то, что делает разработчик, ошибка инструмента / компилятора (на мой взгляд, очень редко) , проблема сборки системы ....

На мой взгляд, все они «система не делает то, что хочет клиент», и все указывают на то, что что-то нужно изменить, чтобы заставить ее делать то, что хочет клиент. Споры о том, является ли это дефектом или функцией, ошибкой исходного кода или какой-либо другой проблемой, отвлекают от обращения ко мне.

Абсолютно. Просто посмотрите на Ошибка Ubuntu №1.

Одна важная вещь, о которой, кажется, никто не упомянул, - это создание базы данных неприятных запахов и ловушек для использования при проведении экспертных обзоров.

Это бесценный ресурс для коллег, фактически выполняющих обзор.

Это определенно окупается в долгосрочной перспективе. Это также должен быть активный документ, база данных и т. д., Которые добавляются как:

• ошибки исправлены
• когда коллеги проводят обзоры, и
• по мере поступления новой крови, чтобы присоединиться к команде (ам), принося с собой новые знания и опыт.

HTH.

ваше здоровье,

Роб

абсолютно. если ваш процесс достаточно хорош, чтобы отследить источник дефекта, чтобы начать отлично. это помогает клиентам и дизайнерам определить ограничения, в которых они работают.

Заказчик: разработать робота для стрижки травы, при этом все стебли травы должны быть срезаны до одинаковой длины.

дизайнер: мы будем использовать детские садовые ножницы для левой руки, установленные перпендикулярно земле, чтобы обеспечить четкие / точные разрезы

QA: разрезы точны.

Заказчик: почему роботу требуется 6 дней, чтобы косить траву. нам нужно 30 минут или меньше!

четкое отслеживание источника дефекта производительности может помочь в формировании разговоров и улучшении процесса в будущем.

Мы отслеживаем ошибки в программном обеспечении, ошибки в документах, ошибки в чертежах и запросы на новые функции, используя один и тот же инструмент отслеживания.