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