la-chariotte/.gitlab/issue_templates/default.md

3.4 KiB
Raw Blame History

title

Short and specific: a clear summary of the bug.

It should also be searchable, so developers can find it in a pinch.

Tips on writing great titles:

  1. Keep it simple, but descriptive.
  2. Dont abbreviate.
  3. Make it searchable.
  4. Focus on the technical problem.
  5. Highlight the specific feature/component you have issues with.

description

Small text to describe the bug with human words.

steps to reproduce

Describe how you found the bug, so the developer can try to reproduce it.

Tips on writing reproducible steps:

  1. Use a numbered list so its easy to follow.
  2. This is your chance to be comprehensive and (reasonably) verbose. Dont leave out any details!

expected vs. actual results

Take some time to explain what should happen vs. what actually happened.

If you just describe the bug, some people might think youre describing the expected behavior.

expected results

actual results

Tips for writing expected vs. actual results:

  1. Use a direct comparison format. For example, "The button should turn green" vs. "The button is turning blue".
  2. Be precise. Simply stating "it went wrong" instead of "the page loads indefinitely" means you are leaving out very valuable information!

visual proof/screenshot

Screenshots and annotations help developers visualize the bug, and pinpoint its location on the page.

Tips on taking great screenshots:

  1. Annotations go a long way towards driving your point across.
  2. Highlight the problematic element. Dont be ambiguous.
  3. Use big fonts, different colors, etc. - the bug needs to be even more obvious here than in your summary.
  4. For complicated issues, record a short video! This adds a ton of helpful context when trying to reproduce bugs.

priority

The urgency and potential impact of the bug. Determines how quickly it needs to be fixed.

How to determine priority/severity:

  1. Critical: blocking bugs that directly prevent business. Example: a checkout page not loading.
  2. High: affects major features, but non-breaking. E.g.: the search bar on an e-commerce website.
  3. Medium: noticeable bugs that disrupt normal use. E.g.: broken link, long loading times.
  4. Low: small issues and enhancements: typos, missing images...

environment

For developers to reproduce and fix your bug, theyll need to know your browser version, screen size, operating system...

Some bugs only occur within specific environments.

  • source url:
  • operating system:
  • browser:
  • viewport:

How to find your environment info:

  1. Browser and version: look for a “Help” or “About” option in your browsers menu.
  2. Operating system: on PC, press the Windows key + Pause/break. On a Mac, click the Apple logo and choose “About this Mac”.
  3. Screen size: look in your computers display settings, or search online for “screen resolution” along with your device model.

console logs

This is where your web browser shows errors or warnings.

Console logs can help developers figure out what went wrong.

console log

How to access your console logs:

  1. Right-click the page, select “Inspect” or “Inspect Element”, then click on the “Console” tab.
  2. Try to make the bug happen again and see if any messages pop up there.

credits https://www.perfectbugreport.io/