Приведи пример когда высокий приоритет, но низкая серьезность или наоборот

У компании Google на главной странице ошибка в слове “Gogle”. Приоритет будет “Высокий”, но степень серьезности низкая. Приоритет высокий, т. к. у компании с мировым именем ошибка в названии – это большие риски и кринж:D

Oct. 19, 2023, Источник

Ситуация, когда дефект имеет высокий приоритет, но низкую серьёзность, или наоборот, низкий приоритет, но высокую серьёзность, встречается в процессе тестирования ПО и управления ошибками. Различие между приоритетом и серьёзностью позволяет более гибко управлять процессом исправления дефектов, учитывая как их влияние на работу системы, так и важность для бизнес-процессов или пользовательского опыта. 

Высокий приоритет, но низкая серьёзность

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

  • Ошибки в ключевых текстах или логотипах на главной странице: Хотя это не влияет на функциональность, такая ошибка может негативно сказаться на репутации компании.
  • Незначительные ошибки в функционале, используемом во время демонстраций для важных клиентов: Например, ошибка в отображении логотипа компании-клиента в демо-версии продукта.

Низкий приоритет, но высокая серьёзность

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

  • Критические ошибки в редко используемых функциях: Например, сбой системы при выполнении специфической операции, которую используют единицы пользователей.
  • Серьёзные ошибки в функционале, планируемом к скорому удалению или переработке: Если известно, что данный функционал будет скоро заменён, может быть принято решение не тратить ресурсы на исправление серьёзной ошибки.

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

March 22, 2024, easyoffer