Должны ли мы отслеживать дефекты в других вещах, кроме кода? [закрыто]

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

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

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

15.12.2008 19:05:27
Для ясности: вы отслеживаете дефекты в вещах, кроме исходного кода?
Jim Blizard 15.12.2008 19:09:56
Вы могли бы отслеживать дефекты в ваших коллегах, но им это может не понравиться!
Steven A. Lowe 15.12.2008 19:23:10
9 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

10
15.12.2008 19:08:13

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

1
15.12.2008 19:08:28

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

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

0
15.12.2008 19:10:02
так вы защищаете две или более системы отслеживания? Это кажется нелогичным и пустой тратой времени и ресурсов.
Tim 15.12.2008 19:10:51
Вам все еще нужно исправить ошибку, даже если это ошибка в документации.
Stephen Wrighton 15.12.2008 19:14:27
аргумент для трекера с открытым исходным кодом. просто найдите и замените «ошибку» на «интересную ситуацию» ...
DarenW 15.12.2008 19:19:11
Я защищаю две системы отслеживания с очень разными свойствами. Это или отдельная система отслеживания, которую мы настраиваем лучше, чем наша существующая система отслеживания ошибок, которая не очень подходит для отслеживания таких вещей, как «руководитель проекта забыл обновить X в раздаточном материале для встречи Y».
edebill 15.12.2008 19:21:03

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

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

0
15.12.2008 19:10:08

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

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

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

0
15.12.2008 19:12:32

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

2
21.02.2012 02:42:32
Это ... 404. Вы пытаетесь быть ироничным?
Dan Esparza 15.12.2008 19:39:56

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

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

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

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

НТН.

веселит,

обкрадывать

0
15.12.2008 19:17:19

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

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

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

QA: сокращения точны.

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

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

0
15.12.2008 19:30:25

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

0
15.12.2008 19:37:23