Баг или недосказанность в постановке: как разбирать спорные дефекты

Спорный дефект — это расхождение, про которое нельзя сказать, нарушает ли оно требование. Спорят о нём тестировщик и разработчик, но предмет спора не код, а постановка. Поэтому и разбирать его должен тот, кто за постановку отвечает.

В русской речи всё это называют «багом», и в этом половина проблемы. Английская практика различает ошибку кода и дефект — расхождение с требованием. Пока слово одно, задача по умолчанию уходит в разработку, и вопрос «а что было написано» никто не задаёт.

Первый вопрос разбора: что написано

До любых обсуждений откройте постановку и найдите строку, которую нарушает поведение. Результат бывает только одного из двух видов: цитата или фраза «в постановке не описано».

Это кажется очевидным, но большая часть споров идёт без этого шага: каждая сторона пересказывает постановку по памяти, и пересказы не совпадают. Как только строка найдена или найдено её отсутствие, спор обычно заканчивается сам.

Правило для текста дефекта. В описании спорного дефекта должна быть ссылка на требование или явная пометка, что требования нет. Дефект без этой строки не разбирается, а возвращается автору. Это не бюрократия: без неё непонятно, с чем сравнивать.

Четыре вида расхождений

Когда ответ на первый вопрос получен, расхождение попадает в один из четырёх видов. От вида зависит, кто им занимается дальше.

Противоречие — прямое следствие того, что требование живёт в двух местах; этот разрыв описан в разборе трассировки. Ожидание — изменение требования, пришедшее через баг-трекер; с ним поступают так же, как с любым изменением по ходу.

Недосказанность: чья она

Самый частый вид и самый неудобный. Постановка молчит, значит, каждый прав по-своему: разработчик реализовал разумный вариант, тестировщик ожидал другого разумного варианта.

Недосказанности почти всегда живут на границах: повтор, ноль, пустое значение, одновременность, действие после истечения срока. Это краевые случаи, которые на постановке не перебрали. В примере с подпиской пропущен один: что делать, если пользователь платит, пока текущий период ещё не кончился.

Выбор между «продлить от даты оплаты» и «продлить от даты окончания» — не технический. Это бизнес-правило: от него зависит, сколько дней пользователь получит за свои деньги. Решать его не тестировщику и не разработчику.

Разработчик, выбравший вариант сам, не ошибся. Он принял решение, которое должен был принять кто-то другой. Даже если решение хорошее, пока оно не записано, это допущение, а не требование. Через месяц его перепишет следующая задача, и никто не заметит.

Как закрыть спорный дефект

Разбор заканчивается не исправлением кода, а записью. Одна запись на дефект:

BUG-417    повторная оплата продлевает от даты оплаты
  вид        недосказанность
  постановка REQ-114: про повторную оплату не сказано
  решение    продлевать от даты окончания текущего периода
  решил      владелец продукта, 2026-09-22
  изменено   REQ-114 ред. 3, добавлен критерий приёмки
  дальше     TASK-2103
             test_REQ_114_renewal_extends_from_period_end

Главная строка здесь — «изменено». Недосказанность, закрытая без правки постановки, вернётся: следующий разработчик прочитает то же молчание и выберет вариант заново, возможно, другой.

Аргументы, которые ничего не решают

Некоторые доводы звучат в каждом споре и ни разу его не разрешают.

• «Так работало всегда». Если раньше работало иначе — это регрессия, и спорить не о чем. Если всегда работало так и никогда не было описано — это недосказанность, которая просто долго никому не мешала.
• «В другой системе так» или «у конкурентов так». Это ожидание. Оно может быть правильным, но становится требованием только после решения и записи.
• Высокий приоритет как аргумент. Критичность говорит о последствиях, а не о том, кто прав. Критичная недосказанность остаётся недосказанностью: её тоже сначала решают, потом чинят.

Спорный дефект — это вопрос к постановке, заданный слишком поздно.

Что показывает счёт

Если вести вид у каждого разобранного дефекта, через месяц появляется цифра, которую иначе не получить: доля недосказанностей. Она говорит не о тестировании, а о том, какие постановки уходят в работу.

Когда недосказанностей много, чинить нужно не процесс тестирования, а вход: готовность постановки. Список краевых случаев, которые у вас повторяются, — готовый пункт для Definition of Ready.

Проверка за пятнадцать минут

Возьмите десять последних закрытых дефектов и разложите по четырём видам. Отдельно посчитайте недосказанности, закрытые без правки постановки. Каждая из них — дефект, который вернётся.

Что дальше

Дефекты разобраны, постановка поправлена, код исправлен. Дальше релиз, и последняя проверка идёт уже не на стенде, а на реальных пользователях: что смотреть в первые сутки после выкладки.