Skip to main content

Bug Reports

Having in mind factors like the reporter’s experience, time constraints, issue criticality, or the need for urgent fixes, flexibility in reporting is acceptable and allowed. But a Quality Assurance engineer should understand that there is a universal standard for creating an effective bug report.

1. Title​

Make it clear, brief, and specific by describing the issue, affected area or feature, and conditions under which it occurs. Use a format like "Feature/Area - Issue - Condition" to ensure easy understanding. The second way is to use a more free format.

Examples:

  • Checkout page - Payment fails - Error after entering valid card details.
  • Payment fails and an error appears after entering valid card details on the checkout page.

2. Description​

Describe the situation using more details.

Example: An error with the text “ERROR ERROR” appears in the right bottom corner after entering valid card details and clicking on the “Done” button on the checkout page.

3. Reproducibility​

Indicates how often the issue can be observed, helping developers prioritize bugs.

Examples:

  • 3/5 time
  • 100% or 50%

4. Environment/Devices​

Clear device, browser, operating system, screen resolution, and network condition details in a bug report ensures developers can replicate the issue in the correct environment.

Examples:

  • Browser Details - include the browser name, version, and type (Brave Web/Mobile Browser, Version 1.71.118 Chromium: 130.0.6723.70 (Official Build) (arm64))
  • Operating System - mention the OS and its version (macOS Sequoia Version 15.1 (24B83)/Android 14 (if using a mobile browser))
  • Screen Resolution - important for layout/UI bugs (1920x1080px)
  • Network Conditions - note if the issue appeared under specific network conditions (3G/5G)

5. Preconditions​

Describing the necessary setup or state of the system before reproducing the issue.

Examples:

  • The user is logged in
  • The user is on the checkout page
  • The user is using a 3G network
  • Browser cache is cleared

6. Steps​

Steps ensure developers can reliably reproduce the issue. Try to separate each action into the steps.

Examples:

  • Enter valid card details
  • Click “Done” button

7. Expected results​

Helps developers understand what the correct behavior should be.

Example: The system should display a confirmation message: “Your payment has been processed successfully”

8. Actual results​

Helps developers understand what behavior/outcome you got.

Example: An error with the text “ERROR” appears in the bottom right corner.

9. Notes​

Provide all necessary information that can help with bug fixing.

Examples:

  • Not reproducible using Safari and Edge browsers.
  • See attached screenshots and logs.

10. Attachments​

Provide developers with visual or technical evidence, it can be video, screenshots, or logs.

Examples:

  • Console Logs - include any error logs from the browser’s developer console (see below how to get to the console log - click HERE
  • Video - record steps with actual results.
  • Screenshot - include visual confirmation of the actual result.

Priority - urgency of resolving the bug; can be P1 (Highest), P2 (High), P3 (Medium), P4 (Low) priority

Optional Severity - level of impact on the system or users; can be Critical, Major, Minor, Trivial

Optional Seniority - the seniority or complexity of the bug helps to determine who should handle it - junior or senior developers. 

Example of a bug report​

Title: “Login page crashes on invalid input"

Description:

The login page crashes by displaying “500 Internal Server Error" when invalid data is entered into the input fields on the Login page and the Submit button is clicked. 

Accepted valid data includes only letters and numbers, no special characters.

Precondition:

The user is located on the Login page

Steps to reproduce:

  1. The user enters invalid data in the input fields (e.g., username: test, password: 123).
  2. The user clicks on the Submit button.

Actual result:

The page crashes and shows a "500 Internal Server Error".

Expected result:

The system should display a validation message, such as: "Invalid username or password. Please try again.".

Environment:

Browser/OS Version: Chrome 130.0.6723.117, macOS Sonoma 14.5 Device: Desktop Testing Environment: Staging

Severity:

Major: Core functionality (login) is broken, but users can bypass the crash by entering valid input.

Priority:

P1: Needs immediate fix.

Attachments:

  1. Video recording of the steps to reproduce
  2. Screenshot of the occurring error - "500 Internal Server Error" page
  3. Logs file - optional

Assigned To:

Responsible developer/Project manager for the adequate Login/Signup functionality