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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

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

НТН.

ура

Rob

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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