Describe the bug - Part 1

Today, let's discuss bugs, or more precisely, their description as tasks in the tracker

It often happens that the frontend developer is on the front line when dealing with a bug. A common scenario is receiving a bug report with just a screenshot and no additional information

In larger projects, recalling the specific page, user context, etc., can become a time-consuming task. Alternatively, one might need to ask clarifying questions to the person who reported the bug

While this is not a major issue, much time can be saved by agreeing on a bug description format

Read the part 2

#FrontendBeer #bug #qa #describebug (c) Frontend Beer

Describe the bug - Part 2

Read the part 1

To gather maximum information upfront, you can adhere to the following structure:

1. Description of the chain of events leading to the bug

2. Link to the page where the error occurred

3. Screenshots of the page and developer console for that page

4. Check if the API Server is functioning correctly (if not, provide screenshots).
   - Open developer tools in the browser.
   - Navigate to the Network tab.
   - Inspect all requests to API_DOMAIN/...
   - Check if the backend server returns correct data or if there are errors or an empty response body.

5. If possible, provide credentials for a test user (login/password)

Perhaps adding some steps could reveal that the error is not on the frontend side of the application, allowing redirection to another developer

What would you add to this list to make it more convenient?

#FrontendBeer #bug #qa #describebug (c) Frontend Beer