Skip to main content
All CollectionsGetting StartedOnboarding
Bug Report Requirements - Summary
Bug Report Requirements - Summary

How do I document a bug report properly, and what are Test IO's standards?

Nikolas Fantoni avatar
Written by Nikolas Fantoni
Updated over a week ago

Please note that this is just a summary article of Bug Report Requirements. To learn more about Bug Report Requirements and our rules which we have, please visit our main Bug Report Requirements article.

Customers need high-quality documentation to understand a bug, so make sure to include sufficient information. Here's a summary of our bug report requirements:

  • For functional bugs, select a Severity level before filling out the report.

  • The Title should answer what, where, and when the bug occurred.

  • Include the URL of the page where the bug happened.

  • Describe the steps taken to reproduce the issue, with the last step triggering the bug.

  • Explain the Actual Result and Expected Result separately.

  • Attach any required files and select the correct environment and browser.

  • Select the appropriate Feature in the drop-down list. If not, mark all Feature descriptions as read before returning to the form.

Bug Form


Functional bugs have an additional field called Severity that indicates the report's urgency. Severity levels vary and are explained in the Functional Bugs article. Other bug types do not have a Severity field.


When writing a bug report title, it should be precise, not too long, and include information about what, where, and when the bug occurred. Avoid stating what is not happening and, instead, describe what is happening. The title should reflect the real problem, including relevant conditions. To ensure the title is descriptive, view it from someone who has never tested the website/app perspective and adjust it if necessary.


You should put the URL form place where the bug occurs.

Steps to reproduce

To ensure a bug is reproducible, provide a step-by-step guide that describes your actions from the initial step up to the point when the bug occurs. The first step should indicate how to access the URL of the landing page or how to open the app. Avoid numbering your steps, as this is done automatically by the system. Keep your steps general and only include specific conditions if necessary. Make sure your steps contain the least amount of actions possible. The last step must describe the action that triggers the bug and avoid using "observing" as an action.

Actual result

Describe the problem and add any relevant details to help readers understand your thought process. Be specific and provide examples of the issue rather than making general statements. Ensure that the actual result is not the opposite of the expected result or the same as the report title.

Expected result

Describe the expected result after performing the last step to reproduce the bug. Be specific and detailed about what should have happened if everything had worked correctly. Note that the expected result differs from the actual result and should not include negative words or slight variations.


To learn what kind of attachment must be attached for your bug and what rules apply, please visit the following article: Requirements for bug report attachments.

Used environment

When reporting a bug, please indicate the device you used for testing a website or mobile app. Only use devices listed in the section; if you want to test with multiple devices, provide attachments for each. If you selected the wrong environment, you can change it after submitting a bug report before the report is reviewed by a team lead. Contact support to add a device to your list if unavailable. Removing a device from your profile after accepting a test invitation prevents you from submitting reports for that test.

Did this answer your question?