Что делать при непонятно сформулированном дефекте на ретест, заведенном другим человеком

Что проверяют

Умеете ли вы работать с чужим артефактом: восстановить контекст, а не переспросить всё заново и не закрыть задачу словами «не воспроизводится». Заодно смотрят, понимаете ли вы, что ретест это проверка исправления, а не повторное заведение дефекта с нуля.

Как отвечать

Начать с того, что уже лежит в задаче: вложения, комментарии, связанная задача разработчика и сам коммит исправления. Часто описание правки объясняет суть дефекта лучше исходной формулировки и сразу подсказывает, что проверять. Оттуда же берутся окружение и версия, в которой проблему нашли.

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

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

Где спотыкаются

Закрывают дефект фразой «у меня не воспроизводится», не указав сборку, окружение и данные. Такая задача возвращается через неделю уже от пользователя, и доверие к отчётам о тестировании падает.

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

Третье: переписывают чужой дефект поверх оригинала. Исходные данные пропадают, история теряется, и если автор имел в виду другое, восстановить это уже нечем. Уточнения добавляются комментарием, а не заменой описания.