На triage предлагают закрыть воспроизводимый дефект как «не исправлять». Как обосновать, что это принятое бизнесом ограничение, а не потерянный дефект?
Решение «не исправлять» обоснованно только тогда, когда дефект подтверждён, его риск оценён, а ответственная сторона явно приняла последствия. В карточке должны быть зафиксированы причина решения, затронутые пользователи или сценарии, оценка влияния, согласовавший решение и условия, при которых его нужно пересмотреть.
Если есть лишь устное решение, нет оценки риска или дефект закрыт для сокрытия невыполненной работы, это не принятое ограничение, а потеря информации о риске.
Жизненный цикл дефекта нужен для управления не только исправлениями, но и решениями по обнаруженным отклонениям. На практике не каждый подтверждённый дефект исправляют немедленно: исправление может быть слишком дорогим, рискованным или не соответствовать текущим целям релиза.
Поэтому в процессе тестирования появились состояния и резолюции, отделяющие факт обнаружения проблемы от решения о дальнейших действиях. Конкретные названия статусов зависят от команды, но необходимость прозрачной фиксации решения остаётся общей.
Воспроизводимый дефект означает, что наблюдаемое поведение не соответствует ожидаемому результату, требованию или согласованному пользовательскому сценарию. Само решение не исправлять его не устраняет риск: пользователи по-прежнему могут столкнуться с проблемой.
Если такой дефект просто закрыть, теряется информация о техническом долге и ограничениях продукта. Это может привести к повторному заведению дефекта, неожиданному инциденту после релиза или ошибочному выводу о качестве системы.
Сначала нужно подтвердить сам дефект: описать ожидаемое и фактическое поведение, условия воспроизведения, затронутую версию и доказательства. Затем следует исключить ошибочную трактовку требования, дубликат и уже исправленную проблему.
После подтверждения оценивают последствия: частоту возникновения, число и ценность затронутых пользователей, влияние на безопасность, данные, деньги, доступность и ключевые бизнес-сценарии. Отдельно рассматривают стоимость исправления и риск внесения изменений, особенно если исправление затрагивает стабильную часть продукта.
Резолюция «не исправлять» допустима, например, когда поведение сознательно принято как ограничение текущего релиза, сценарий крайне малозначим, исправление несоразмерно риску или требование изменено. Но такое решение должно быть явным: его принимает уполномоченный представитель бизнеса или продукта, а не только тестировщик и не только разработчик.
Карточка должна содержать основание решения, оценку риска, ссылку на требование или согласование, затронутые версии и условие пересмотра. Если проблема известна, но исправление отложено, часто точнее использовать статус вроде «отложен», чтобы не смешивать принятое окончательное ограничение с будущей работой.
Статус и резолюция не универсальны: в одной команде «не исправлять» может быть финальной резолюцией, а в другой — временным состоянием. Поэтому важнее не название, а однозначная семантика, правила переходов и сохранение аудита решения.
В интернет-магазине на очень старом браузере неправильно выравнивается второстепенная иконка, но оформление заказа и доступ к информации не нарушаются. Тестировщик предлагает исправление, однако изменение общего компонента перед релизом может затронуть актуальные браузеры.
Вариант «исправить немедленно» устраняет визуальную проблему, но создаёт риск регрессии в критичном сценарии. Вариант «молча закрыть» экономит время, однако скрывает известное ограничение и не позволяет объяснить его при обращении пользователя. Вариант «зафиксировать как принятое ограничение» сохраняет прозрачность, если поддержка старого браузера не является обязательным требованием.
Команда сверила матрицу поддержки, подтвердила отсутствие влияния на оформление заказа и получила согласование владельца продукта. Дефект закрыли с резолюцией «не исправлять», указали ограниченную область влияния и добавили условие пересмотра при изменении политики поддержки браузеров. Это сохранило управляемость риска без опасного изменения перед релизом.
1. Чем резолюция «не исправлять» отличается от «не дефект»?
«Не дефект» означает, что после проверки ожидаемое поведение признано корректным: например, оно соответствует требованию или утверждённому правилу. «Не исправлять» означает обратное: проблема подтверждена, но организация осознанно принимает решение оставить её в текущем виде.
Смешение этих резолюций искажает статистику качества. Подтверждённый риск нельзя выдавать за отсутствие дефекта только потому, что исправление не вошло в план.
2. Можно ли закрыть дефект как «не исправлять» без указания приоритета и серьёзности?
Технически инструмент может это позволить, но процессно такое решение ненадёжно. Серьёзность описывает влияние проблемы, а приоритет — срочность устранения с учётом целей продукта; без этих оценок трудно проверить, было ли решение пропорционально риску.
Оценки не обязаны быть математически точными, но их основание должно быть понятным. Если дефект затрагивает безопасность, потерю данных или обязательный бизнес-сценарий, простого согласования «не исправлять» обычно недостаточно: требуется отдельное принятие высокого риска на соответствующем уровне.
3. Что делать, если после закрытия дефекта пользователи начали массово сталкиваться с проблемой?
Нужно не просто открыть старую карточку без анализа, а пересмотреть исходное решение с учётом новых данных. Следует зафиксировать изменившуюся частоту или влияние, связать инциденты с дефектом, переоценить серьёзность и приоритет и определить ответственное исправление или временное обходное решение.
Сам факт ухудшения последствий не доказывает, что первоначальное решение было недобросовестным: на момент triage могла быть другая информация. Но отсутствие условий пересмотра и владельца риска показывает слабость процесса, которую нужно устранить.