Я не уверен, что это место, где можно задать следующий концептуальный вопрос (Stackoverflow определенно нет).
Я видел этот вопрос на экзамене с несколькими вариантами ответов (один ответ), похожем на экзамены ISTQB :
Почему не рекомендуется сообщать о нескольких дефектах в одной и той же проблеме / тикете?
а. Чтобы отчет был кратким и понятным.
б. Потому что разработчики могут исправить только одну ошибку.
с. Потому что тестировщики тестовой группы оцениваются по количеству найденных ошибок.
д. Системы управления ошибками не поддерживают эту функцию множественных ошибок.
Мое единственное мнение, что a
это правильный ответ.
b
- не может быть, так как исправление-обратная связь-решение-закрытое должно избежать этого случая.
c
- Очевидно, неправильно.
d
- Плагины Redmine / Trac поддерживают несколько полей.
Ответ в соответствии с листом ответов b
.
Может кто-нибудь объяснить, почему? Комментарии с мнением об ответах приветствуются.
Ответы:
Представьте, что у Stack Overflow есть руководящие указания: вместо того, чтобы задавать один вопрос, вы приходите и спрашиваете в том же вопросе все, что вам приходит в голову, все ваши проблемы, которые у вас были за последние две недели. Что будет означать повышение и понижение? Каковы будут названия вопросов? Как принять лучший ответ? Как отметить вопрос?
Система отслеживания ошибок сделана, чтобы ... отслеживать ошибки. Отслеживание ошибки означает:
Создание записи о том, что ошибка может существовать, с информацией о том, как ее воспроизвести,
Подтверждая, что действительно, ошибка существует и является ошибкой, а не чем-то разработанным,
Утверждая, что ошибка теперь решена,
Подтверждая, что ошибка была устранена.
В очень упрощенной модели 1 и 4 будут выполнены заказчиком, а 2 и 3 - разработчиком.
Представьте себе следующий журнал:
Журнал прост и понятен . Вы можете легко отслеживать, что было сделано и когда , какая ревизия решила какую ошибку и т. Д. Например, если система отслеживания ошибок интегрирована с контролем версий, когда вы просматриваете конкретную ревизию, вы можете проверить, какие ошибки были устранены в ней.
Это легко найти информацию . Легко увидеть его состояние (воспроизводится ли? Если билет был закрыт, почему?). Легко фильтровать тикеты (я хочу отображать тикеты, которые касаются только пользовательского интерфейса плагинов, учитывая, что я хочу только тикеты, которые открыты, старше одной недели и назначены мне нашим дизайнером взаимодействия и имеют средний или высокий приоритет).
Легко переназначить тикет или изначально определить, кто именно должен отвечать за ошибку.
Теперь представьте следующий журнал:
О чем этот журнал? Это было решено 43 раза и вновь открыто 43 раза. Означает ли это, что разработчик настолько глуп, что не может решить эту проблему за 460 дней? Ах, нет, подождите, этот билет был назначен тем же 11 разработчикам. В чем дело? Как искать конкретную проблему? Это фактически назначено Ванессе, но ее пять коллег обеспокоены также семью из одиннадцати проблем в этом билете. Когда билет должен быть закрыт? Это когда половина вопросов решена? Или, может быть, десять из одиннадцати?
Примечание: вы можете поверить, что такие журналы не существуют. Поверьте мне, я видел их не один раз.
источник
Просто чтобы прокомментировать ваше заявление:
Это предполагает, что все обнаруженные ошибки будут исправлены одновременно. Представьте себе сценарий, в котором поднят билет против v1 продукта с двумя проблемами:
И то, и другое правильно для тестера, поскольку они оба являются ошибками в реализации. Но допустим, что владелец продукта решает, что первая подзадача является блокирующим для выпуска (то есть она должна быть исправлена до того, как продукт может быть запущен), но вторая задача - это незначительная проблема (то есть она может быть исправлена в v1. 1 выпуск).
В этом случае у нас нет другого выбора, кроме как разделить # 2 на свой собственный билет (или рискнуть забыть об этом). Если мы можем сделать это, это означает, что они могут быть реализованы, протестированы и развернуты независимо друг от друга, и в этом случае имеет смысл иметь отдельные проблемы с самого начала.
источник
Объем:
Этот ответ (и вопрос) кажется применимым только для отслеживания дефектов кода, когда исходный код не работает в соответствии со спецификацией или намерениями программистов.
Напротив, для заявок на дефекты GUI характерно наличие нескольких спецификаций, потому что каждая заявка GUI фактически представляет собой «редизайн» (дефект дизайна), «пересмотренную спецификацию» или «запрос функции» (отсутствует функциональность).
Одной из важных целей отслеживания дефектов является взаимодействие и координация между несколькими ролями (программисты, тестировщики, клиенты и менеджеры).
В проектах, где качество кода имеет большое значение (например, по сравнению с удобством для пользователя), отслеживание дефектов может состоять из нескольких аспектов, один из которых будет сосредоточен на отслеживании дефектов кода , отдельно от отслеживания улучшений и запросов поддержки клиентов.
Целью системы отслеживания дефектов кода является:
При этом следует максимально увеличить следующие желательные качества:
Отказ от ответственности: это перефразирование из моего личного опыта. Это может быть недостаточно или неправильно для целей сертификационного экзамена.
Независимое и однозначное отслеживание означает, что:
Каждый допустимый дефект может быть разрешен или не устранен , без двусмысленности.
Независимо воспроизводимые дефекты должны отслеживаться независимо.
источник
Посмотрите на это с точки зрения кого-то еще, использующего систему, обнаружившегося несколько месяцев спустя. Они находят ошибку в программе. Они гуглят вокруг и видят, что есть билет поддержки, который соответствует их проблеме, которую они имеют. И эй, это закрыто! Потрясающе! Это было исправлено в последней версии! Итак, они обновляются ... и ошибка все еще там? Что не так с этими глупыми разработчиками?!?
Ничего, вообще-то. Оказывается, что-то не так с человеком, отправляющим сообщение об ошибке. Они представили две ошибки в одном билете. Один был легко исправить, и быстро починили, а другой нет. Даже если вы используете что-то вроде fix-feedback-resolved-closed, это может быть не совсем понятно, что происходит, особенно для стороннего наблюдателя.
Гораздо лучше дать каждой ошибке свой билет, и если у вас есть несколько ошибок, которые связаны, но явно различаются, большинство систем отслеживания ошибок имеют функцию, которая позволяет связывать одну ошибку с другой. (А если нет, вы можете просто добавить его в отчет. «См. Также ошибка # 12345.»)
источник
B
тогда?