This page contains tips for effective bug reporting in JIRA. Note that if Partners are using a different tool for project management, they should still follow the following recommendations as they are helping with easier bug fixing and smoother project delivery.
General info:
Bug reporting is a standard part of a project communication
It should be never taken personally - it is just about reporting a functional issue
Good bug reporting can help a lot with quicker bug fixing
Nobody can guarantee that the software is completely bug-free, so bugs are normal in IT projects
When:
during development phase - by QA Analyst or by customer project team
during UAT - mainly by customer UAT tester
Typical issues and how to fix them:
missing details about founded issue - typically how to reproduce the issue, data used for testing or detailed description
Possible solution: Follow the guideline and report bugs with all details
especially during UAT: what is reported is really not a bug, but more a suggestion for improvement, a question or just a misunderstanding because of not clear documentation
Possible solution: during the project - use project Stand-ups for discussing the behavior, discuss issues with UAT leader before reporting the bug
not reporting issues immediately
Possible solution: report founded issues daily, ideally before the tester is going home after testing
How to report a bug properly in JIRA:
Here is short
...
| View file | ||
|---|---|---|
|
...
tutorial to help you learn how to create bugs effectively.
Purpose
The purpose here is to explain how to report bugs to JIRA and show on examples what is important and what need to be described or attached.
Bug reporting is an important part of functional and UAT testing. It helps to increase quality and stability of software. No system is bug free, however with thorough testing and reporting issues and discrepancies the system will fulfil your requirements and it will help you in your business.
Basic terminology
Term | Description |
Summary | Short description of the issue |
Description | Thorough description of the issue including all possible information |
Priority | Order in which defects should be fixed |
Assignee | Person who is the first recipient of the issue |
Affects version | Version of pfx software where the issue is observed |
Linked to | Original ticket to which the issue belongs |
Sprint | Name of the sprint when the issue was found |
Step by step guidelines
All bugs are reported to JIRA by QA analyst or by customer. It is important to create bugs thoroughly with all possible details so time for investigation will decrease and bug can be solved within shorter time range. In the following text you will see what are the most important information by creating a bug. Also assigning bug directly to QA analyst will help to work on the issue faster and more effective.
The following information are essential to create bug correctly. If the information below is missing, it will be difficult to track and fix bugs. There are more additional information that you can fill; however please pay attention to the aspects mentioned above.
Summary – short description of the issue.
From the description should be obvious what is the issue related to.Try to keep one format for related issues, e.g.
Price analyzer – columns are missing in Data mart
Price analyzer – error on the main page
Description – is the most important part of bug report. It describes thorouhly the situation which you observed during the testing.
Description should contain following:
· Summary – short description of the issue
· Steps to reproduce – what steps needs to be taken to simulate the issue
· Actual results – result whit actual configuration
· Expected results – result which is expected based on the requirement
· Test data – data which were used when the issue appeared (modul, sku, record in the table etc.)
· Screenshots – it is easier to identify the issue with a screenshot or short video
Priority – by creating defect it is important to assign some priority – the developer will know what to fix first.
Priority is a parameter to decide the order in which defects should be fixed, it is dependent on bug’s severity. Severity is an impact of a particular defect on the software
· Critical – it is essential for using the solution, it is not possible to use the application without fixing those defects
· High (Major) – defect has to be solved immediately after the critical ones are fixed, some other functionalities or testing might be blocked by those defects
· Medium – the defect requires attention but does not block using the system or testing
· Low (Minor) – defects which need to be fixed but they don’t have significant impact on using the application
Linked to – select original ticket (user story) which is the issue related to. It helps to track all issues related to one functionality.
The following information is good to fill as it might help to track the issue and helps to navigate in JIRA :
Assignee – is a person who is the first recipient of the issue. Select QA analyst as assignee. He or she will investigate and will process it further
Affects version - select actual version which is this issue related to
Sprint - select actual version of the sprint which is the issue related to
