Report a bug

How to create an issue?

  1. Choose the appropriate repository where the issue should be created.

  2. Be specific with the title, use module or unit name and a short description.

  3. Do not assign the issue to anyone.

  4. Choose a proper label for the issue, in this case bug.

  5. Choose CosmOS reference project in Projects.

  6. Choose Not planned in Milestone, till we decide in which release we would like to include your issue.

List of items that should be included in the bug report

  1. [Feature, Module, Unit Name] Title

  2. Environment

  3. Steps to reproduce

  4. Expected result

  5. Actual result

  6. Visual proof (screenshots, videos, text)

  7. Severity/Priority

Title

Your title should serve as a concise summary of what the bug is. Our report titles start with the feature, module or unit name in brackets at the very beginning of the title.

  • [generator] - bug report for the generator feature.

  • [buffer] - bug report for the buffer module.

  • [memoryProtection] - bug report for the memory protection unit.

Environment

The environment for every application can vary widely, but be as specific as you can. Testers should always follow the given bug report template unless otherwise specified — it helps to cut down on unnecessary information.

  1. Device: What type of hardware are you using? Which specific model?

  2. OS: Which version number of the OS has displayed the issue?

  3. Software Version: Which version number are you testing? Simply writing “latest version” is not enough, since some bugs are version-specific, make sure you include this specific information.

  4. Reproducibility Rate: How many times have you been able to reproduce the error, using the exact steps you have taken to activate the bug? It’s also useful to report how many times the bug has been reproduced vs. the number of attempts it took to reproduce the issue, in case it’s an intermittent occurrence.

Steps to Reproduce

Create a list of steps that we can easily follow through by repeating the same process.

Expected Result

What should happen when you trigger the call-to-action? This is where you put on your end-user cap and think about the desired outcome and offer deeper insights than “the app should not crash.”

Actual Result

Here is the result of the bug. Does the application crash? Does nothing happen at all? Is an error displayed?

Proof

Any pertinent screenshots, videos, or log files should be attached.

Severity/Priority

Sharing the severity offers a degree of impact the bug has on the functionality of the system and helps the dev team prioritize their work. We recommend using one of three categories of severity in your bug report:

  1. High/Critical: anything that impacts the normal user flow or blocks software usage

  2. Medium: anything that negatively affects the user experience

  3. Minor: ALL else (e.g., typos, missing icons, layout issues, etc.)