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