Должны ли мы отслеживать дефекты в других вещах, кроме кода? - PullRequest
7 голосов
/ 15 декабря 2008

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

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

Кто-нибудь еще собирает информацию о дефектах, которых нет в исходном коде?

Ответы [ 9 ]

10 голосов
/ 15 декабря 2008

Да, отследить их всех.

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

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

2 голосов
/ 15 декабря 2008

Абсолютно. Просто посмотрите на Ubuntu Bug # 1 .

1 голос
/ 15 декабря 2008

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

0 голосов
/ 15 декабря 2008

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

0 голосов
/ 15 декабря 2008

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

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

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

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

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

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

0 голосов
/ 15 декабря 2008

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

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

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

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

НТН.

ура

Rob

0 голосов
/ 15 декабря 2008

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

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

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

0 голосов
/ 15 декабря 2008

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

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

0 голосов
/ 15 декабря 2008

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

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

...