Принятие Вас вовлечено в оценку ошибок в Вашей организации, как Вы определяете разные уровни серьезности тех ошибок?
Более конкретно - каковы различные значения, которые Вы используете для "Серьезности"? Каковы критерии, которые Вы используете для присвоения значений ошибкам?
Разъяснение: я только говорю о признаках здесь. Давайте отложим другие вещи, которые влияют на установление приоритетов как: сколько времени это взяло бы для исправления ошибки, что другие задачи находятся на программе команды и т.д.
если говорить о деньгах, это критично.
Тогда это зависит от того, сколько раз это зависит от многих вещей:
время решать
как это влияет на производительность других сотрудников
контракт (если ошибка нарушает контракт, это критично)
если неверные данные введены / выбраны в базе данных, это может иметь критическое значение
Это также зависит от вашего бизнеса.
Для этого в основном нужны две вещи:
Если вы примете эти два во внимание, то получите хороший список того, что исправить в первую очередь.
Например, ошибка с низким уровнем серьезности может иметь высокий приоритет.
Все компании разные. У нас есть 5 различных уровней
По большей части наши бизнес-тестеры определяют серьезность проблемы. По мере того, как они проводят тестирование и обнаруживают ошибку, они определяют, как это повлияет на клиента и потенциальный выпуск, и соответственно назначают приоритет. Мы проверяем наиболее серьезные вопросы и выясняем, действительно ли они настолько серьезны, какими их считает компания. Несколько раз бизнес-тестировщики сообщали об ошибках «Блокировщика», но когда мы копаемся в них, мы обнаруживаем, что это действительно не так критично.
Подводя итог, можно сказать, что ошибки Blocker - это ошибки, которые мы должны исправить немедленно. Это ошибки, которые не позволят продукту работать, если он был выпущен в таком состоянии.
Критические ошибки по-прежнему остаются ошибками, но обычно существует обходной путь или быстрое исправление, которое можно применить после выпуска.
У серьезных ошибок есть обходной путь, и их можно отложить, не влияя на функциональность приложения.
Незначительные и тривиальные проблемы обычно зарезервированы для улучшений или «желательно иметь».
Надеюсь, это поможет прояснить ситуацию.