Как закрыть ошибку, которая больше не актуальна

21

В настоящее время я работаю в средней команде веб-разработчиков. Мы используем jira для отслеживания ошибок.

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

  • Чем нам его закрыть?
    Что я имею в виду, как мы должны относиться к этим вопросам? Несмотря на то, что Jira - это программное обеспечение для отслеживания ошибок, которое мы используем, меня больше интересует, как в целом решать подобные проблемы.
  • Имеет ли это значение? (Мы можем вернуться к макету позже, но это очень маловероятно)
Бенджамин Грюнбаум
источник
8
Слишком локализовано;)
Яннис
4
не согласен, что это слишком локализовано, это может быть лучше подходит для SO, хотя, как это возможно для конкретного инструмента
jk.
6
@jk. Хех, я имел в виду «слишком локализованный» как предложение / ответ на вопрос, а не то, что сам вопрос «слишком локализован». Если бы я думал о последнем, я бы просто закрыл его.
Яннис
2
@YannisRizos дох! возможно, это должен был быть ответ;)
JK.
6
@jk. Я думаю, что второй вопрос более интересен (имеет ли это значение?), Но у меня сейчас нет времени, чтобы ответить на него (и я не совсем уверен, что ответ, который формируется в моей голове, является хорошим). Что касается первого вопроса, если этот поток становится «предложением слова / фразы», ​​он может быть закрыт как «неконструктивный». Итак, ответчики, не игнорируйте второй вопрос, пожалуйста, это тематический и интересный вопрос.
Яннис

Ответы:

26

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

Эта ситуация становится гораздо менее запутанной, если вы посмотрите на нее с точки зрения тестировщика. Если в вашей команде нет тестера, представьте себе его (или еще лучше, нанять 1 , 2 , 3 ).

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

Теперь вы говорите: «компоновка уже изменилась, и она больше не актуальна» - бровь больше не актуальна и превращает ум тестера в гораздо более простое утверждение: проблема исчезла .

  • Здесь важно отметить, что профессиональному тестировщику должно быть удобно думать о системе как о чёрном ящике . С этой точки зрения, не имеет большого значения, как именно это случилось, когда проблема исчезла, это может быть изменение макета, черная магия или полная переработка или конкретное изменение кода, что угодно.

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

Профессиональный тестировщик возьмет ваш старый выпуск, посмотрит, как проблема там, затем возьмет более новый выпуск и проверит, исчезла или нет.


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

Одна из настроенных JIRA, с которыми я работал в прошлом проекте, имела разрешение «Fixed By Design», чтобы сообщать о довольно глубоких изменениях, имеющих множество последствий, некоторые намеренные, некоторые нет. В случае, подобном описанному вами, это также можно рассматривать вместо простого «Исправлено», поскольку оно подсказывает читателю билетов, что это скорее побочный эффект, чем преднамеренное изменение кода.

комар
источник
2
Fixed by Design будет означать для меня полную противоположность этому. На мой взгляд, под дизайном подразумевается «преднамеренный» (это противоположность «по ошибке»).
TRiG
Я согласен, что "исправлено" достаточно. Неважно, было ли это преднамеренным или побочным эффектом других изменений. Однако я также согласен с @TRiG, ​​что «Fixed by Design» сбивает с толку.
1
@TRiG хорошо, поэтому я указал, что лучше объяснить точные детали в комментариях. Fixed By Design немного широка; в проекте, который я видел, он использовался для передачи довольно глубоких изменений, имеющих много последствий, некоторые умышленные, а некоторые нет - таким образом, охватывая подобные случаи. Заметьте также, что ни текст вопроса, ни мой ответ не подразумевают «исправить по ошибке» (какая ошибка?) - здесь «непреднамеренное» гораздо лучше подходит
gnat
1
Все ответы хороши, но этот, кажется, прибивает это. Спасибо всем.
Бенджамин Грюнбаум
6
Как насчет "Исправлено редизайном"?
13
47

Мы решаем такие вопросы как «Устаревшие». Это не вариант разрешения по умолчанию в JIRA, но его достаточно легко добавить.

Kris
источник
+1, если вы не можете добавить его, по крайней мере, выберите, так как это не ошибка, и прокомментируйте, почему
tgkprog
9

JIRA (и я уверен, что другие средства отслеживания ошибок) позволяет вам задавать собственные разрешения, чтобы вы могли иметь возможность устанавливать разрешение «Перегружено событиями» или «Неправильно», или подобное, чтобы позволить вам выразить закрытие так, как вы хотите

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

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

JK.
источник
1
«Over Taken By Events» слишком длинное (imho), я бы выбрал одно слово (неактуальное / устаревшее) только потому, что его легче искать и он занимает меньше места (в отчетах и ​​т. Д.). Единственный случай, когда было полезно узнать количество наших устаревших ошибок, когда они появлялись в большом количестве, и это указывало на проблему со связью. Наши тестеры не были в курсе того, над чем работали наши разработчики, они пропустили заметку о том, что в течение недели или около того все будет плохо, и шумели (бесполезно). Итак, оглядываясь на наших наблюдателей. ошибки помогли нам найти и исправить дыру в наших коммуникационных процессах.
Яннис
3
на самом деле мы используем аббревиатуру OBE, но я думаю, что используемое слово - наименее интересный момент, смысл в том, чтобы выбрать то, что вам подходит
jk.
3
@YannisRizos: исправление мета-ошибок с помощью ошибок. Как это круто!
Jörg W Mittag
Поиск @YannisRizos не является большой проблемой, так как действительные разрешения в любом случае выбираются из выпадающего списка (в JIRA)
jk.
2
@Yannis. Я бы потерял сон из-за этого: обгонять должно быть одно слово.
TRiG
5

Мы используем FogBugz, но я уверен, что то же самое (или подобное) применимо здесь:

Мы просто используем «Resolved (Fixed)» и комментируем в разрешении редактировать что-то вроде «Fixed by case 12345».

FogBugz соответствует «case \ d +» и связывает их вместе в связанных случаях, но если Jira не делает этого, просто добавить ссылку.

Это IMO лучше, чем вариант «Слишком локализованный», потому что это была настоящая ошибка, и лучше, чем просто «Устаревший», потому что он был исправлен, эта функция не была просто удалена.

Izkata
источник
3
Исправлено путем вытрезвления и повторной проверки <- правдивая история.
Яннис
1
Джира также допускает такой подход. Просто укажите номер проблемы в комментариях к решению, и Джира превратит его в гиперссылку.
Марьян Венема