Bug Report Guideline

Once you've found the problem, you need to record that information and notify the
developers about it. The bug report is divided into separate fields. Use this guideline to
submit precise bug reports.
Assignee
Assign defect to developer who responsible for issue.
Priority
Define appliction priority using this table.
Low Medium High Blocker

Class: C Class: B Class: A Class: MF (Must Fix)
Description Any Any feature Any Major feature A defect that completely
cosmetic implemented implemented hampers or blocks testing
defects that is not that is not of the product/ feature is
including meeting its meeting its a critical defect. An
spelling requirements/use requirements/use example would be in the
mistakes or case(s) and case(s) and case of UI testing where
alignment behaves behaves after going through a
issues or differently than differently than wizard, the UI just hangs
font casing expected but the expected, it can in one pane or doesn’t go
can be impact is be classified further to trigger the
classified negligible to under Major function. Or in some other
under Low some extent or it Severity. cases, when the feature
Severity. doesn’t have a developed itself is missing
major impact on from the build.
the application,
can be classified
under Minor
Severity.
Title
A brief and very clear title that expressed the problem. The summary consists of two parts:
„problem + few details“. The problem is the main information and the source states where
the problem is reproduced.
Summary just like headline doesn‘t contain articles.
Example:
Send doesn‘t work in Categories
No data when Home loaded
Avoid to write generic or very broad descriptions like "Had to send message" or "Problem in
Categories dialog". Such titles do not sufficiently describe the problem to get the attention.
Problem
A descriptive summary of the issue. This includes details, explanations other available
information necessary to reproduce the problem.
In the description be sure to include all of these parts:
• What the defect did to the application:
[Example 1] The application unexpectedly quits.

[Example 2] Cashe is corrupted.
• How / When the defect happens
[Example 1] when pressing ‚Enter‘ key.

[Example 2] after killing application process.
• Where the defect happens
[Example 1] in the Categories cotextual menu.

[Example 2] in the main menu.
• Who in the application caused the problem (if such information is available)
[Example 1] The ‚Enter‘ key event calls infinity requests to the server that prevents the
app from woking properly.
[Example 2] Issue cause hot fix #ID363.
Steps
Always imagine that person is not familiar with your project and he must understand how to
reproduce the defect from first attempt to read steps.
1. Describe the action and purpose (if necessary) of each step.
Example:
Tap Jobs button to open the list of persons.
Click Settings button to enter the application settings screen
2. Number each step.
• Eliminate unnecessary steps to get the defect to appear.

• Find more frequent and / or more common scenarios that could include the
remaining essential steps.
3. First step starts from general area, commonly from the default menu.
4. If there are many steps, you can merge more generic steps to one sentence using these
examples.
5. If necessary, provide details where the step should be complete.
Example:
1. Press ALT + ENTER shortcut in the Create New Template window to enter full screen
mode
Actual Result
Describe what actually happened after completing the steps above.
In certain circumstances screenshots or video materials is big advantage as well.
Example:
Distorted lines are visible on the Create dialog.
Expected Result
Describe result that is expected for the correct functioning of the application.
Sometimes expected result is very important element of submitted problem especially

when requirements are not enough clear. If you don't know what is correct program
behaviour, always consult with project lead.
Example:
Expected Result:
New result is displayed in the table when clicking Display button.
1. Use generic expected result for obvious situations
Example:
Situation: Application quits unexpectedly when pressing a button.
Expected result:
Application works without malfunctions.
Situation. Small vertical line is visible in the left screen corner.

Expected result:
There is no graphical glitches.
2. Expected result is formulated as direct requirement. Do not use such expression like:
"should", "would be better" and so on.
Example:
Correct: Application must set language from the system settings.
Incorrect: It would be great if application could set language from system settings.
Reproduction Rate
Specify the frequency this problem reproduces:
Always
Approx. 80 %
Approx. 50 %
Approx. 10%
Unable to Reproduce

Bug Report Guideline

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Bug Report Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bug Report Guideline

Uploaded by

Copyright:

Available Formats

Once you've found the problem, you need to record that information and notify the

Low Medium High Blocker

Summary just like headline doesn‘t contain articles.

In the description be sure to include all of these parts:

• What the defect did to the application:

[Example 1] The application unexpectedly quits.

• How / When the defect happens

[Example 1] when pressing ‚Enter‘ key.

• Where the defect happens

[Example 1] in the Categories cotextual menu.

1. Describe the action and purpose (if necessary) of each step.

• Eliminate unnecessary steps to get the defect to appear.

5. If necessary, provide details where the step should be complete.

Sometimes expected result is very important element of submitted problem especially

Situation. Small vertical line is visible in the left screen corner.

You might also like