Почему системы отслеживания выпуска обычно имеют разные статусы «Открыто» и «Открыто»?
Проблемы, которые являются открытыми, как правило, являются первым появлением любой проблемы.
Повторно открытые проблемы: 1) повторяющиеся и / или 2) неправильно исправленные. Причин для этого может быть несколько - ключевая часто может быть связана с исходным описанием проблемы для конечного пользователя.
Я не думаю, что какой-либо разумный магазин будет использовать его в качестве показателя для оценки технического персонала [в одиночку], но он полезен в качестве меры для определения эффективности ответных мер, а также может указывать на основные проблемы, которые необходимо решить.
Моя старая компания использовала эти статусы, чтобы отследить, сколько раз ваша проблема доходила до «Открыта», чтобы увидеть, насколько «плохим» для вас был разработчик. Они думали, что существует корреляция между количеством повторных открытий рабочего элемента и вашей ценностью программиста.
Я там больше не работаю.
Время жизни ошибки часто:
то есть.
Кто-то находит ошибку и открывает ее в трекере. Разработчик исправляет это как можно лучше, понимая проблему. Тестер повторно тестирует, чтобы убедиться, что исправление сработало, и повторно открывает, если они могут убедиться, что оно не сработало. Если исправление подтверждено, то ошибка закрыта.
Другой сценарий заключается в том, что исправление в другом месте вызвало регрессию, и ошибка должна быть исправлена повторно. Таким образом, он вновь открыт.
источник
Может также оказаться более очевидным, что проблема требует более пристального внимания или более быстрого внимания, потому что она продолжает оставаться проблемой после того, как считается, что проблема была решена.
источник
Открыто означает, что это новый вопрос. Вновь открытое время было проблемой, которая была открыта-> закрыта, а затем снова открыта.
Почему это было открыто снова? Возможно, разработчик и тестировщик думали, что проблема была исправлена, но на самом деле она не была устранена. Или, возможно, проблема была действительно исправлена, но некоторые другие последующие изменения кода вызвали ее повторение. Неважно, как, но вновь открывшаяся проблема является плохим признаком, и, следовательно, она классифицируется по-разному.
источник
Как мы используем это здесь:
Новая задача: Создана в начале проекта, чтобы показать всю работу, которая должна быть выполнена. Это открыто, пока кто-то не кодирует это, тогда это решено. Он открывается только в том случае, если что-то не было реализовано, или если функциональность изменилась, и разработчик должен вернуться и потратить немало времени, работая над этим.
Ошибка / Дефект: Открыто кем-то из QA или другим разработчиком, проверяющим общий рабочий продукт. Если вам назначена ошибка, вы исправляете ее, а затем исправляете, и она возвращается к тестированию. Если QA чувствует, что оно не было исправлено, они снова откроют его и приложат к нему любую другую информацию. Цикл Resolved / Reopened может продолжаться до тех пор, пока QA не убедится, что ошибка исправлена, и затем закроет тикет.
Итак, в основном вы используете Reopen, чтобы сказать, что билет уже был просмотрен, и кто-то проделал работу над ним, что, по его мнению, решило его, но это не так.
источник
Это в основном тип согласованности: ошибка (или проблема в целом) является «открытой», если она была создана с нуля. Он «открывается», если он был создан после предыдущей обработки.
Для разработчика (или любого, кто занимается проблемой) это не должно иметь никакого значения. Вопрос был поднят и теперь должен быть обработан.
Однако отдельный статус «вновь открывать» все еще может быть полезен для ряда сценариев:
Во-первых, его можно использовать для отслеживания того, работает ли ваш процесс обеспечения качества. Если QA все сделал правильно, ошибка не должна возникать после ее исправления. Таким образом, вы можете сказать, сколько раз ошибка была установлена в состояние «вновь открыт» - это количество раз, когда QA не совсем выполнил свою работу должным образом. Это, конечно, подразумевает, что существует хороший процесс обеспечения качества и пользователи активно участвуют в процессе и знают, когда «открывать», а когда «вновь открывать» проблему.
Другое использование состоит в том, что, когда ошибка повторяется, вам не нужно поднимать еще одну проблему, но вы можете добавить информацию о уже существующей проблеме (и, следовательно, сохранить важную информацию, такую как история ошибок, дополнительные файлы, которые были загружены, предыдущие комментарии и и так далее) но все же укажите "эй, это случилось снова ).
источник
Одна из основных причин отслеживания «повторного открытия» заключается в том, что он может дать вам представление о проблемах с глубокой маршрутизацией, а не о простых промахах и недосмотре деталей. Если конкретный модуль или элемент функциональности имеет множество «повторных открытий», это указывает на слабость, которая требует устранения. Большое количество одиночных открытий указывает на срочную работу и / или небрежную практику.
источник