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

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

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

• Чем нам его закрыть?
  Что я имею в виду, как мы должны относиться к этим вопросам? Несмотря на то, что Jira - это программное обеспечение для отслеживания ошибок, которое мы используем, меня больше интересует, как в целом решать подобные проблемы.
• Имеет ли это значение? (Мы можем вернуться к макету позже, но это очень маловероятно)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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