Answer.

Background:

A bug report is the main artifact of a tester. For decades, the quality of bug reports has determined the speed of communication between QA and DEV departments, either shortening or lengthening the time it takes to fix bugs.

Problem:

Poorly formatted bug reports (lack of clear steps, vague descriptions, absence of expected behavior) lead to misinterpretation of tasks and incorrect fixes, wasting time on additional clarifications. This is the main cause of conflicts between teams.

Solution:

Adhere to the structure: title, priority/severity, environment, steps to reproduce, actual result, expected result, screenshots/videos/logs.
Use a maximum structured and unambiguous language without unnecessary emotions and subjective assessments.
Check the report before submission — attempt to reproduce it by another employee based on the recorded steps.
Fill in the fields according to the template accepted in the company (Jira, DevOps, YouTrack, etc.).

Key features:

Clear structure and reproducibility.
Relevant linking of bugs to the environment and application version.
Support bugs with facts, artifacts, rather than subjective evaluation.

Tricky Questions.

Is it possible to combine several similar bugs (for example, for different interface elements) into one bug report?

No. Each bug is a separate error, as fixing one may not resolve the others. The exception is mass bugs of a single nature (for example, global loss of styles).

Is "Not working"/"Not opening" a good enough title for a bug?

No. The title should be specific (for example, "[Profile] Save button inactive after entering valid data").

Should I specify steps only in minimal form if the bug is obvious?

No. Even obvious bugs need to be described clearly — to avoid misunderstandings and for product history.

Common Mistakes and Anti-patterns

Absence of expected results.
General phrases without details.
Inclusion of personal assessments or emotions ("horrible bug", "it needs to be fixed urgently").

Example from Life

Negative Case

A tester submitted a bug report with the following text:

Button is not working.

and without indicating the step, environment, and expected result. The developer could not reproduce the bug, and the report was closed as "Unreproducible".

Pros:

Quickly drafted.

Cons:

Bug lost, misunderstandings occurred in the team.

Positive Case

A tester detailed:

In which browser and version the bug occurs
Detailed list of steps
Expected and actual behavior
Attached screenshots and logs
Clearly indicated a link to the user story