Answer.

Background:

Since the emergence of bug tracking systems, testers have faced the challenge of how to report bugs so that developers can reproduce and fix them without unnecessary questions. This is where the culture of clearly documenting steps, environment, conditions of occurrence, and actual results originated.

Problem:

A poorly drafted bug report causes prolonged disputes and misunderstandings within the team. Often, a bug gets lost, cannot be reproduced, and is closed as "not reproducible," allowing the defect to persist in the system.

Solution:

Strictly adhere to the structure of the report: reproduction steps, expected and actual results, environment, severity, and if necessary, include screenshots or logs.
Test bugs "with clean hands": with a new user, empty cache, clean browser.
Use bug report templates and checklists for self-testing.

Key features:

The need for clarity in steps (historically — so that anyone can reproduce the bug).
Indication of the minimal set of information: environment (software version, browser, OS).
Illustration of bugs (screenshots, logs, videos).

Tricky Questions.

Can a bug be reported only verbally if everyone on the team "understood it"?

No. Even in established teams, it is always important to formally document a bug: history of changes, team turnover, and memory of the bug are not infinite.

Is it necessary to write each bug from a "blank" state (login/logout/etc.)?

If the steps to reproduce the bug are trivial (standard login) — they can be omitted, but if the session, profiling, or settings are specific — full reproduction is critical.

Do all bugs need to be supported by screenshots/videos?

Not always. If the bug is evident from the description (spelling mistake), a screenshot is useful but not mandatory. However, if the bug relates to visual display/layout, visual evidence is essential.

Common Mistakes and Anti-Patterns

Vague or incomplete bug descriptions (“something doesn’t work”)
Lack of information about the environment
Absence of reproduction steps

Real-life Example

Negative Case

A tester creates a bug "Button does not work" without steps or environment. The developer cannot reproduce the error.

Pros:

Time saved on creating the ticket.

Cons:

The bug remains unresolved or returns to the tester, damaging communication.

Positive Case

A tester formalizes the bug: specifies steps, version of the application, browser, adds a screenshot and system log.