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


26

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

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

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

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

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

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

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

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

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

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

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

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


Если это не подходящее место, чтобы спросить, пожалуйста, проголосуйте, чтобы закрыть / сообщить мне, я закрою.
Ofiris

3
Я согласен с вами, что a, по-видимому, правильный ответ - я думаю, что b является побочным эффектом a. Поскольку заявка не является четкой и краткой, разработчики могут не полностью понять и устранить все обнаруженные дефекты. Тем не менее, этот вопрос также игнорирует метрики, полученные из дефектных билетов.
Томас Оуэнс

25
ИМХО правильный ответ таков: «потому что жизненный цикл или отслеживание каждой проблемы могут быть разными, и с ними трудно справиться, если смешать несколько дефектов в одной проблеме». И краткая форма этого «разработчики могут исправить только одну ошибку».
Док Браун

Если вы допускаете два дефекта в одном билете, почему бы не три, десять, сто? Какой будет предел? В конце концов, в чем смысл отслеживания проблем?
Mouviciel

1
Я просто хотел бы добавить, re: множественный выбор: Ответ A звучит правильно, потому что очевидно, что билет с одним выпуском яснее и короче, чем билет с двумя ошибками. Но B более критичен, потому что билет с двумя ошибками полностью уничтожает процедуру «fix-feedback-resolved-closed», разбивая ее на несвязанные ветви, как демонстрирует MainMa. «Dev может исправить только одну ошибку» - небольшая часть проблемы, возникающей из-за «попытки отследить множество проблем, смешанных вместе». (Плюс, re: A, билет с одной ошибкой может все еще быть ужасно длинным и неясным ...)
Отступление

Ответы:


73

Представьте, что у 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 разработчикам. В чем дело? Как искать конкретную проблему? Это фактически назначено Ванессе, но ее пять коллег обеспокоены также семью из одиннадцати проблем в этом билете. Когда билет должен быть закрыт? Это когда половина вопросов решена? Или, может быть, десять из одиннадцати?

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


Спасибо за длинный ответ, я согласен с вашими соображениями о важности системы отслеживания.
Ofiris

Какой ответ вы бы выбрали?
Ofiris

3
@Ofiris: А и Б.
Арсений Мурзенко

Я утверждаю, что настоящая проблема, стоящая за такими журналами, заключается в том, что пользователи относятся к этому так: «На самом деле, я привлек внимание разработчика, и я заставлю их исправить все, что нам нужно!» Что является признаком бизнеса, который обесценивает ценность приоритизации внутренних потребностей.
Btilly

1
@btilly: я думаю, что это не такое отношение, а скорее факт плохой организации и, кроме того, наличия плохо спроектированной системы отслеживания ошибок (я говорю о UX-дизайне). Если для создания дополнительного билета требуется десять кликов, неудивительно, что большинство клиентов пытаются избежать этого любой ценой, добавив несколько проблем в один и тот же тикет.
Арсений Мурзенко

12

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

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

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

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

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

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


2
И эти две проблемы вполне могут быть решены двумя разными инженерами - в этом примере: тот, кто обрабатывает логику HTML-формы, и тот, кто обрабатывает таблицы стилей CSS. Если есть две ошибки, то каждый инженер получает свою роль, но многие системы отслеживания ошибок не могут справиться с назначением одной ошибки двум разным людям.
Алан

6

Объем:

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

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


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

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

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

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

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

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

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


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

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

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

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

4

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

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

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


Спасибо, ты бы выбрал Bтогда?
Ofiris

@Ofiris: Да, я бы.
Мейсон Уилер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.