Можно ли просто запустить тест и посмотреть, на чем он падает

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

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

Как отвечать

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

Порядок разбора, который стоит проговорить:

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

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

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

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

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

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