Явное тоже не стоит приписывать.

а зачем тут шаги расписывать? Разработчики явно их читать даже не будут

В джире вообще шаги редко ведь расписывают

Мне казалось, достаточно было внимательно прочитать. Но возможно, я недостаточно ясно выразился.
Баг-репорт -- это инструкция про то, как увидеть расхождение между ожидаемым и фактическим результатом. Минимально необходимое количество параметров, соответственно: шаги, что я хотел увидеть, что я получил взамен.
Когда Вы звоните в автомастерскую с криком "я вставила ключ в замок зажигания и у меня колёса отвалились" -- это тоже баг-репорт. И заголовка у него нет. Ожидаемый результат есть всегда. В данном случае, он подразумевается ("колёса на месте"). Вот на таком случае спор и завязался. Зачем писать ожидаемый результат, если он прям всем очевиден.

Все дополнительные поля (versions, preconditions, user impact, requirements, tested by, additional notes, versions affected, reproduced on prod build, workaround -- да кучу всего можно придумать) -- это расширение. По договорённости. Да, если Вы договаривались, но что-то не указали, Ваш лид, менеджер, или разработчик могут иметь право сказать Вам, что, мол, "это не баг-репорт, переделывай", имея в виду "мы с тобой договаривались о том, что ты будешь... А ты не... Пожалуйста, исправь".
Так понятнее?

Иногда нужно, чтобы воспроизвести какую-то ошибку в точности так же, как воспроизводилось у тестировщика.
Или ссылку на страницу - мегаудобно, прямо из багрепорта переходишь в нужное место.

"после нажатия на кнопку"? ) Т.е. кнопка нажалась и даже сообщение есть "заявка отправлена" и даже редирект есть, например... А заявка не отправилась )

шаги стоит писать как минимум для того, что бы пока ты в отпуске-болеешь, твой тикет могли закрыть без лишних вопросов

Тогда "Заявка не поступает "куда-то там", куда должна была прилететь. Надо ведь в заголовке указывать конкретные вещи.

Так, подождите. Если сообщение есть, что заявка отправлена, То каким образом тестировщик увидел, что она не отправилась?

мы же говорим о тестировании сайта, без базы данных

Вот-вот. Выше написала, что это уже другая проверка и другая ошибка.

Тогда этого не видно и такого баг-репорта не заведется.

Кмк, изначальный спор как раз упёрся в вопрос "а насколько явно я определяю явное".)
На примере Keane -- 500 ошибка -- пришёл новый разработчик и исправил 500 на 418. Формально, он прав (хоть и говнюк, с т.з. тестировщика), тестировщик -- нет. Разработчик не должен быть телепатом. И зачастую, разработчик не должен сам придумывать ожидаемый результат.

+9000.

И к этому могу добавить, что иногда баги фиксят спустя 5 лет. Без STR сложно даже самому иногда это воспроизвести.

Ну, она, например, не пришла куда надо. Или в базе не прописалась. Или статус не поменялся.

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

Ожидаемый результат и фактический - в описании. В заголовке только сама суть, кратко и емко.

Не видел таких случаев

Или будут? Или другие тестировщики будут? Или мы тут в предсказателей и телепатов играем? )

А как же воспроизведение багов по фотографии монитора?)))