Following are the elements of a bug report :

• TITLE - A good title is simple, concise, and provides a description of the bug to the developer. It should include the bug's categorization, the app component where the bug happened (e.g. Cart, UI, etc. ), and the activity or conditions in which the bug occurred. A clear title makes it easier for the developer to find the report and distinguishes duplicate reports, making problem triaging much easier.
• SEVERITY AND PRIORITY -  The severity of an issue is determined by its severity. The severity levels and definitions vary amongst programme developers, and even more so between developers, testers, and end-users who are unaware of these distinctions. The standard categorization is as follows:
  • Critical/Blocker: This category is reserved for faults that render the application useless or result in significant data loss.
  • High: When a bug affects a major feature and there is no workaround or the remedy that is provided is extremely complicated.
  • Medium: The bug affects a minor or significant feature, but there is a simple enough fix to AVOID major discomfort.
  • Low: This is for defects that have a modest impact on the user experience, such as minor visual bugs.
• DESCRIPTION -This is a concise summary of the bug, including how and when it occurred. This section should contain additional INFORMATION than the title, such as the frequency with which the bug happens if it is an intermittent error and the situations that appear to trigger it. It contains information about how the bug is impacting the application.
• ENVIRONMENT - Apps can behave in a variety of ways depending on their surroundings. This section should contain all of the information about the app's environment setup and settings.
• REPRO STEPS - This should include the bare essentials for reproducing the bug. The steps should ideally be short, easy, and accessible to ANYBODY. The goal is for the developer to be able to reproduce the error on their end in order to figure out what's wrong. A bug report without repro steps is useless and wastes time and effort that could be better spent resolving more complete reports; make sure to convey this to your testers and in a way that your end-users understand.
• ACTUAL RESULT -  This is what the tester or user saw as a result or output.
• EXPECTED RESULT - This is the anticipated or planned consequence or output.
• ATTACHMENTS - Attachments can assist the developer find the problem faster; a screenshot of the problem can explain a lot, especially when the problem is visual. Logs and other incredibly USEFUL attachments can at the very least PUT the developer in the proper direction.
• CONTACT DETAILS -  If any additional information regarding the issue is required, an e-mail address where you may contact the user who submitted the bug should be provided. Getting the user to react to emails might be difficult, so you should consider giving alternative communication routes that are less of a hassle for the user to enhance efficiency.