Bug report creation

Introduction

Bug finding, reporting, tracking, and fixing are integral processes of software development. Each of them is very important and has got a big impact on the quality of the product that is built.

The bug report is the first one from the above list of processes that must be created so that the rest of them are run smoothly and efficiently.

What is a bug report?

A bug report is a document that informs the development team about a specific issue with an application that needs to be fixed. A bug report should be well-structured and adequately detailed about the problem in the application. It needs to contain all details that can help developers to understand the problem and find the best solution quickly. It should not not be very long, because developers usually work under time constraints and they don’t have time to read a ‘novel’ – it must be concise.

What are the main components of the bug report?

The structure of the bug report must be clear, must give a solid understanding and must contain some main components such as:

1. Title – this is what everybody sees first. Not only when a specific bug report is opened but also in the list of bug reports in any tracking tool like Jira. It is like a small hint or summary of what the bug is. In this short sentence, you need to state what exactly is not working and what the results don’t match up with. It should not be generic, it should be specific:

• Continue button is not working – generic, not very helpful
• Continue button can’t be triggered on the main page – specific, more informative

Here you can also indicate where something is not working – which environment, frontend or backend, mobile or web, etc. Clear bug report titles reduce the possibility of duplicating errors in the tracking tool and could be found quickly in the future if needed.

2. Bug ID – should be unique because it makes identification easier. In a bug tracking tool like Jira, it is created automatically with a unique ticket number
3. Environment, product version, platform, operating system – sometimes if the environment is not specified, reproducing the bug could be impossible. When the bug exists in the iOS system then this information must be provided in the report, because the same issue could not exist in the Android system. A similar situation appears when the bug is found in the specified version of the application – it could not exist in in different versions, for example: on the Dev environment it exists, but in the Production there is no issue
4. Priority – it describes when the bug should be fixed, for example fix the bug as soon as possible or fix it when time permits
5. Severity – it describes the impact of the bug, if the issue is a blocker or critical, or the issue doesn’t have much impact on the product, it is a minor problem. We can distinguish following types of severity:

• Blocker: No further testing work can be done.
• Critical: Application crash, Loss of data.
• Major: Major loss of function.
• Minor: Minor loss of function.
• Trivial: Some UI enhancements.
• Enhancement: Request for a new feature or some enhancement in the existing one

6. Status – the first status of the created bug should be New and later on, the bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix, etc
7. Assign to – if the bug is related to the frontend it could be assigned to a frontend developer, same for the backend, API, etc. If it is not certain who can take care of this, it should be left blank and will be assigned at the proper time
8. Description – the bug description section should provide information on what led to the problem which the output testers expected, and what happened:

• Issue: what is the problem and where? It shows the existing problem with more details than in the title. It helps to understand the problem.
• Steps to reproduce – the bug should be reproducible, otherwise it won’t be fixed. The report must describe step by step what actions led to the bug occurrence. It should be very detailed, ideally, it should be a numbered list of simple actions. If there are any prerequisites they should be added before the first step, because this will help to make the list of steps shorter.
• Actual result – it shows what happens when all steps have been taken
• Expected result – it shows what should happen if all steps have been taken
• Note – is not mandatory, but it might help the Developer, when the bug report creator, usually QA, adds his/her own thoughts, observations, comments, hints

9. Proof – screenshot, recording – it helps to understand the bug, speed up the process of bug reproducing and it is also the proof that something is not working for you. If the issue is associated with website elements like a textbox or page layout the screenshot is enough. When it is related to the actions taken, a short recording is a better way.

Why a good bug report is so important in the software development process?

During the testing process, when a potential bug is found, it means there is something wrong with our product and it should be reported, discussed, and fixed if necessary.

Finding a bug is both good and bad news:

• it is good because it was found and can be fixed before the product is released to the customer
• it is bad because the product just has a bug When comparing both good and bad information, it is better to find the error and report it than for the customer to find it.

When the bug is found and the decision is made that we are creating a bug report for any feature or functionality that is not working as expected it is important to do it correctly. The better the report is, the faster the bug gets fixed. In turn, if the report doesn’t provide all the essential details or does it in the wrong way, fixing the bug will take more time, effort, and money.

It is also very important the have a clear atmosphere in the team. Sometimes unnecessary, bad, and not clear bug reports could begin potential conflict between the developer and tester.

Tips to write a good bug report

Below please find some hints on how to create a good bug report:

• Do not include multiple bugs in one bug report. Keep it limted to one bug = issue
• Avoid duplicates – before a bug report is created, check in the bug tracker that this issue has not been reported earlier
• Avoid criticizing – obviously, bugs are irritating, but criticizing won’t make your report better or more effective
• Double-check the report – before clicking create, check if all mandatory fields are populated in the report, all details are provided and the report is clear and understandable
• Reproduce the bug before creating the bug report – check if the bug really exists and if you are able to reproduce it. It will avoid situations when the developer can’t reproduce the bug and neither can you
• Keep the report simple – keep everything as straightforward as possible. Using bullet points or numbered lists can help
• Do not wait – report the bug immediately when you are sure you have found the bug and no report has been already created for it

Bug reporting tool

One of the very popular tools for bug reporting is Jira. We can easily go through the process of bug creation. We need to open our tool. Find and click on the Create button.

After that: 

We should choose Issue Type as a Bug. Write a meaningful Summary. Add affected component. The main part is the Description where you can add a bug detail description, according above advice. You can attach printscreens logs etc. in the attachment section. Assign a responsible person. Add the affected version. Choose Sprint but keep in mind new bug that has some story points can make changes to the current sprint.

Conclusion

Creating a good quality bug report is a valuable skill for any Quality Engineer. A good report is the main communication point between the developer and the tester. Efforts spent on creating this document will create a good relationship between team members, help save the resources of the company and make life easier for the testers themselvs.

References

1. https://developerexperience.io
2. https://www.careerist.com
3. https://blog.instabug.com/
4. https://www.fingent.com/
5. https://www.atlassian.com/