Почему не рекомендуется размещать несколько дефектов в одном выпуске / билете?

Я не уверен, что это место, где можно задать следующий концептуальный вопрос (Stackoverflow определенно нет).

Я видел этот вопрос на экзамене с несколькими вариантами ответов (один ответ), похожем на экзамены ISTQB :

Почему не рекомендуется сообщать о нескольких дефектах в одной и той же проблеме / тикете?

а. Чтобы отчет был кратким и понятным.

б. Потому что разработчики могут исправить только одну ошибку.

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

д. Системы управления ошибками не поддерживают эту функцию множественных ошибок.

Мое единственное мнение, что aэто правильный ответ.

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

d - Плагины Redmine / Trac поддерживают несколько полей.

Ответ в соответствии с листом ответов b.

Может кто-нибудь объяснить, почему? Комментарии с мнением об ответах приветствуются.

Представьте, что у Stack Overflow есть руководящие указания: вместо того, чтобы задавать один вопрос, вы приходите и спрашиваете в том же вопросе все, что вам приходит в голову, все ваши проблемы, которые у вас были за последние две недели. Что будет означать повышение и понижение? Каковы будут названия вопросов? Как принять лучший ответ? Как отметить вопрос?

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

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

2. Подтверждая, что действительно, ошибка существует и является ошибкой, а не чем-то разработанным,

3. Утверждая, что ошибка теперь решена,

4. Подтверждая, что ошибка была устранена.

В очень упрощенной модели 1 и 4 будут выполнены заказчиком, а 2 и 3 - разработчиком.

Представьте себе следующий журнал:

• День 1 [Клиент] При нажатии на кнопку «Удалить» в окне «Сведения о продукте» приложение зависает. Перезапуск приложения показывает, что продукт не был удален. Ожидаемое поведение - удалить продукт.

• День 4 [Разработчик] <Выпуск воспроизведен>

• День 5 [Разработчик] <Проблема решена в ревизии 5031>

• День 12 [Заказчик] <Билет закрыт: проблема решена>

Журнал прост и понятен . Вы можете легко отслеживать, что было сделано и когда , какая ревизия решила какую ошибку и т. Д. Например, если система отслеживания ошибок интегрирована с контролем версий, когда вы просматриваете конкретную ревизию, вы можете проверить, какие ошибки были устранены в ней.

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

Легко переназначить тикет или изначально определить, кто именно должен отвечать за ошибку.

Теперь представьте следующий журнал:

• День 1 [Клиент] Приложение зависает, когда я нажимаю кнопку «Удалить» в окне «Сведения о продукте». Кроме того, цвет фона левой панели темно-синий, в то время как он должен быть фиолетовым. Я также отметил, что текст окна «Сведения о продукте» плохо переведен на немецкий язык; это ожидается? Когда будет доступен окончательный перевод? Кстати, вы получили новый значок, который я отправил для действия «Опубликовать продукт»? Я не вижу его в окне «Синхронизация данных».

• День 6 [Разработчик] Я изменил цвет на фиолетовый.

• День 7 [Разработчик] Да, это нормально, что перевод на немецкий язык является неполным.

• День 8 [Заказчик] Хорошо для немецкого языка. Как насчет итальянского? Люсия отправила вам файл XML два дня назад.

• День 9 [Разработчик] Теперь все в порядке.

• День 10 [Клиент] Хорошо для кнопки «Удалить»? Странно, на моем компьютере он все еще зависает.

• День 11 [Разработчик] Нет, я хотел сказать, что это нормально для итальянского перевода.

• День 12 [Заказчик] Понятно. Спасибо. Но есть проблема с цветом. Вы изменили его на темно-фиолетовый, но он должен быть светло-фиолетовым, как верхняя панель в главном окне.

• День 13 [Разработчик] Я обновил иконку.

• День 14 [Клиент] Иконка? Какой значок?

• День 15 [Разработчик] Значок, который вы попросили меня обновить.

• День 16 [Клиент] Я никогда не просил вас обновить какой-либо значок.

• День 17 [Разработчик] Конечно, вы спросили. Смотрите этот билет. Вы написали, что значок публикации продукта должен быть обновлен. Я сделал это.

  ⁞

• День 100 [Клиент] Итак, что насчет записей в журнале?

• День 101 [Разработчик] Понятия не имею, о чем ты говоришь. Это даже не в этом билете, а в 6199. Я закрываю этот как решено. <Билет закрыт: проблема решена>

• День 102 [Клиент] Извините, что снова открыл его, но проблема не решена. Я говорю о записях в журнале: я говорил вам на прошлой неделе, что текст иногда недействителен, если он содержит символы Юникода. Ты помнишь? <Билет возобновлен>

• День 103 [Разработчик] Я смутно помню что-то подобное, но после поиска на последних трех страницах этого билета я не могу найти никаких следов. Вы можете написать еще раз, в чем была проблема?

  ⁞

• День 460 [Разработчик] Я потратил два часа на поиск следов того, что вы сказали о файлах, отправленных в зашифрованном виде по сети. Я не уверен, что смогу найти точный запрос.

• День 460 [Клиент] Вы, ребята, действительно должны быть более организованными. Я уведомил вас четыре раза об этой проблеме за последние две недели. Почему ты все забываешь?

  ⁞

О чем этот журнал? Это было решено 43 раза и вновь открыто 43 раза. Означает ли это, что разработчик настолько глуп, что не может решить эту проблему за 460 дней? Ах, нет, подождите, этот билет был назначен тем же 11 разработчикам. В чем дело? Как искать конкретную проблему? Это фактически назначено Ванессе, но ее пять коллег обеспокоены также семью из одиннадцати проблем в этом билете. Когда билет должен быть закрыт? Это когда половина вопросов решена? Или, может быть, десять из одиннадцати?

Примечание: вы можете поверить, что такие журналы не существуют. Поверьте мне, я видел их не один раз.

Просто чтобы прокомментировать ваше заявление:

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

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

1. Кнопка сброса формы фактически отправляет форму, а не очищает значения
2. Размер шрифта на кнопке составляет 110%, тогда как он должен быть 115%.

И то, и другое правильно для тестера, поскольку они оба являются ошибками в реализации. Но допустим, что владелец продукта решает, что первая подзадача является блокирующим для выпуска (то есть она должна быть исправлена ​​до того, как продукт может быть запущен), но вторая задача - это незначительная проблема (то есть она может быть исправлена ​​в v1. 1 выпуск).

В этом случае у нас нет другого выбора, кроме как разделить # 2 на свой собственный билет (или рискнуть забыть об этом). Если мы можем сделать это, это означает, что они могут быть реализованы, протестированы и развернуты независимо друг от друга, и в этом случае имеет смысл иметь отдельные проблемы с самого начала.

Объем:

Этот ответ (и вопрос) кажется применимым только для отслеживания дефектов кода, когда исходный код не работает в соответствии со спецификацией или намерениями программистов.

Напротив, для заявок на дефекты GUI характерно наличие нескольких спецификаций, потому что каждая заявка GUI фактически представляет собой «редизайн» (дефект дизайна), «пересмотренную спецификацию» или «запрос функции» (отсутствует функциональность).

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

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

Целью системы отслеживания дефектов кода является:

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

При этом следует максимально увеличить следующие желательные качества:

• Масштабируйте эффективно, поскольку количество дефектов увеличивается с течением времени.
• Предотвратить синдром движущейся цели.

Отказ от ответственности: это перефразирование из моего личного опыта. Это может быть недостаточно или неправильно для целей сертификационного экзамена.

Независимое и однозначное отслеживание означает, что:

1. Каждый допустимый дефект может быть разрешен или не устранен , без двусмысленности.

   • Причина 1: упростить управление,
     • Пример: он позволяет использовать «количество неразрешенных заявок» в качестве показателя.
   • Причина 2: перевести в предмет действия
     • Пример: если это не решено, ответственность лежит на назначенном программисте. Если оно разрешено, но не закрыто, ответственность лежит на назначенном тестере (верификаторе).
   • Следствие: в этой методологии частично устраненный дефект заслуживает разложения на несколько зависимых дефектов.

2. Независимо воспроизводимые дефекты должны отслеживаться независимо.

   • «Независимо воспроизводимый» означает, что они могут иметь разные состояния. Один может казаться исправленным, в то время как другой остается сломанным.
   • Причина: минимизировать несоответствие между отслеживанием дефектов и анализом основных причин.
     • Считается, что каждая первопричина, которая может быть связана с дефектом кода, требует как минимум одного изменения кода.
     • Если два дефекта воспроизводимы независимо друг от друга, потребуется несколько изменений кода.
     • Если два дефекта воспроизводимы независимо, они оба должны быть проверены (проверены), потому что прохождение одного теста не означает, что другой тест пройдёт.
   • Пример 2: если первоначально считалось, что два симптома имеют одну и ту же основную причину и, таким образом, классифицируются в одном и том же билете, и позже было показано, что они воспроизводимы независимо, то их следует разделить на два билета.

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

Ничего, вообще-то. Оказывается, что-то не так с человеком, отправляющим сообщение об ошибке. Они представили две ошибки в одном билете. Один был легко исправить, и быстро починили, а другой нет. Даже если вы используете что-то вроде fix-feedback-resolved-closed, это может быть не совсем понятно, что происходит, особенно для стороннего наблюдателя.

Гораздо лучше дать каждой ошибке свой билет, и если у вас есть несколько ошибок, которые связаны, но явно различаются, большинство систем отслеживания ошибок имеют функцию, которая позволяет связывать одну ошибку с другой. (А если нет, вы можете просто добавить его в отчет. «См. Также ошибка # 12345.»)