Здравствуйте 1) В случае трудновоспроизводлимых багов всегда старайтесь записать видео действий с помошью записи экрана. Это уже доказательство проблемы для программиста 2) Перед начало очистите кеш или откройте сайт в инкогнито, Исключим этот фактор 3) Далее нужно воспроизвести шаги которые привели к багу, Можно с уверенностью сказать что это баг а не проблемы со средой если он воспроизвелся 2 или более раз В контексте уровня 4 возможно это просто невидимая кликабельаня зона в меню?

Видео ответ https://screencast.com/t/ZJ80uhxCC

Все действия пользователя должны создавать запросы. Все запросы сайта можно трекать в network инспектора

1. Меня интересует, нужно ли мне самой же и пройти этот тест кейс, т.е. заполнить столбец "фактический результат" просто вы написали, что бонусом будет указать какие поля формы считаю не уместными или баги какие замечу, где мне это указать? Ответ: как я говорил вчера на вебинаре, тест-кейс всегда неотрывный от функционала. Нельзя писать тест кейс и не проходить его. По этому все графы ОР и ФР являются обязательными и проходить его НУЖНО. 2. Кстати в реальной жизни такие вещи замечают и фиксируют уже на стадии составления тест кейса, те кто его пишут или потом, те кто - выполняют?  Ответ: часто баги находятся при составлении, потому что глубокий анализ позволяет выявить пробелы допущенные при приемочном тестировании. 3. вообще тест кейс пишут по уже готовым частям сайта, которые уже можно увидеть и покликать, так я поняла? а до этого момента просто пишут просто баг репорты (например на ошибки в спецификации)  Ответ: обычно пишут тест-кейсы по функционалу готовому для тестирования (Ready for QA). Заранее только составляют чек листы которые входят в тест план. Они более общие и абстрактные чем тест кейсы так как конкретные проверки на одной только документации построить нельзя. 4. В принципе пишут и так и так, а лучше написать ввести имя в 1 символ, например А.