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