Bug Reporting Practices

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 information

  • 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 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

 

 

 

 

 

 

 

 

 

 

Â