Изменение статусов Severity и Priority дефекта в процессе тестирования может произойти по нескольким причинам:
- Изменение понимания влияния дефекта на продукт: Изначально влияние могло быть недооценено (например, считалось проблемой UI, а оказалось, что затрагивает критическую бизнес-логику) или переоценено.
- Изменение бизнес-требований или приоритетов: Если дефект затрагивает функциональность, которая стала более или менее важной для бизнеса, его приоритет может быть скорректирован.
- Обнаружение обходного пути (workaround): Если найден простой способ обойти дефект без существенных потерь для пользователя, его
Priority может быть понижен. Severity, как правило, остается прежней, так как обходной путь не устраняет саму проблему.
- Зависимость от других дефектов: Исправление одного дефекта может либо усугубить, либо нивелировать влияние другого, что может потребовать пересмотра их статусов.
- Изменение количества затронутых пользователей: Если дефект, который казался малозначительным, обнаруживается у большого числа пользователей, его
Priority может быть увеличен.
- Некорректная первоначальная оценка: Тестировщик мог ошибочно определить
Severity или Priority из-за недостаточного понимания контекста, функциональности или бизнес-процессов.
- Смена стадии разработки/тестирования: На разных этапах (например, unit-тестирование, интеграционное, системное, приемочное) влияние одного и того же дефекта может восприниматься по-разному.
- Решение команды или менеджера: Окончательное решение по
Severity и Priority часто принимается коллегиально с участием тимлида, менеджера проекта или Product Owner, особенно для спорных случаев.
- Обнаружение новых сценариев использования, затрагиваемых дефектом: Если дефект проявляется в большем количестве сценариев, чем предполагалось изначально, его
Severity или Priority могут быть увеличены.
Изменения статусов всегда должны быть обоснованы и документированы в системе отслеживания дефектов.