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