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