Testing Excellence

Home » Testing Basics » Elements of a Bug Report

Elements of a Bug Report

Updated:

How to Write a Good Bug Report

bug-report-software-defect

Writing a good defect or bug report goes a long way in identifying and resolving the problems quickly. In here, I list the elements that are normally included in a bug report.

In no particular order:

Defect Identifier, ID

The identifier is very important in being able to refer to the defect in the reports. If a defect reporting tool is used to log defects, the ID is normally a program generated unique number which increments per defect log.

Summary

The summary is an overall high level description of the defect and the observed failure. This short summary should be a highlight of the defect as this is what the developers or reviewers first see in the bug report.

Description

The nature of the defect must be clearly written. If a developer reviewing the defect cannot understand and cannot follow the details of the defect, then most probably the report will be bounced back to the tester asking for more explanation and more detail which causes delays in fixing the issue.

The description should explain exactly the steps to take to reproduce the defect, along with what the expected results were and what the outcome of the test step was. The report should say at what step the failure was observed.

Severity

The severity of the defect shows how sever the defect is in terms of damaging to other systems, businesses, environment and lives of people, depending on the nature of the application system. The severities are normally ranked and categorized in 4 or 5 levels, depending on organization’s definition.

  • S1 – Critical: This means the defect is a show stopper with high potential damages and has no workaround to avoid the defect. An example could be the application does not launch at all and causes the operating system to shut down. This requires immediate attention and action and fix.
  • S2 – Serious: This means that some major functionalities of the applications are either missing or do not work and there is no workaround. Example, an image viewing application cannot read some common image formats.
  • S3 – Normal: This means that some major functionality do not work, but, a workaround exists to be used as a temporary solution.
  • S4 – Cosmetic / Enhancement: This means that the failure causes inconvenience and annoyance. Example can be that there is a pop-up message every 15 minutes, or you always have to click twice on a GUI button to perform the action.
  • S5 – Suggestion: This is not normally a defect and a suggestion to improve a functionality. This can be GUI or viewing preferences.

Priority

Once the severity is determine, next is to see how to prioritize the resolution. The priority determines how quickly the defect should be fixed. The priority normally concerns the business importance such as impact on the project and the likely success of the product in the marketplace. Like severity, priority is also categorized in to 4 or 5 levels.

  • P1 – Urgent: Means extremely urgent and requires immediate resolution
  • P2 – High: Resolution requirement for next external release
  • P3 – Medium: Resolution required for the first deployment (rather than all deployments)
  • P4 – Low: Resolution desired for the first deployment or subsequent future releases
  • P4 – Low: Resolution desired for the first deployment or subsequent future releases

Read more on Severity versus Priority

It is important to note that a defect which has a high severity also bears a high priority, i.e. a severe defect will require a high priority to resolve the issue as quick as possible. There can never be a high severity and low priority defect. However, a defect can have a low severity but have a high priority.

An example might be a company name is misspelled on the splash screen as the application launches. This does not cause a severe damage to the environment or people’s lives, but can have potential damages to company’s reputation and can harm business profits.

Date and Time

The date and time that the defect occurred or reported is also essential. This is normally useful when you want to search for defects that were identified for a particular release of software or from when the testing phase started.

Version and Build of the Software Under Test

This is very important too. In most cases, there are many versions of software; each version has many fixes and more functionality and enhancements to the previous versions. Therefore, it is essential to note which version of the software exhibited the failure that we are reporting. We may always refer to that version of software to reproduce the failure.

Reported by

Again, this is important, because if we may need to refer to the person who raised the defect, we have to know who to contact.

Related requirement

Essentially, all features of a software application can be traced to respective requirements. Hence, when a failure is observed, we can see what requirements have been impacted. This can help in reducing duplicate defect reports in that if we can identify the source requirement, then if another defect is logged with the same requirement number, we may not need report it again, if the defects are of similar nature.

Attachments / Evidence

Any evidence of the failure should be captured and submitted with the defect report. This is a visual explanation of the description of the defect and helps the reviewer, developer to better understand the defect.

 

Selected Articles

  • Test Automation Problems
  • Test Automation Strategy
  • Agile Test Strategy example
  • How QAs add value in agile
  • Agile without automation
  • How agile killed managers
  • Agile testing challenges
  • Testing e-commerce websites
  • Role of QA manager in agile
  • Are you a good agile tester?
  • BDD tips and best practices
  • Myths of test automation
  • Test automation tips
  • Test automation pros & cons


/ Workflow tips

9 bug reporting templates you can copy for your web testing process

Web testing is tough.

That’s why choosing a bug reporting process is necessary.

Whether your organisation needs to report issues in a bug tracking app like Jira , GitHub , Trello , GitLab , Asana or keep a backlog in an Excel (.xls) spreadsheet, Word document (.doc) or via email, this post offers free bug reporting templates you can easily copy and implement with your team. Find what works for you in this list:

  • 1) Bug report template in GitHub
  • 2) Bug report template in Jira
  • 3) Bug report template in Trello
  • 4) Bug report template in GitLab
  • 5) Bug report template in Asana
  • 6) Bug report template in Excel
  • 7) Bug report template in Word
  • 8) Bug report template in PDF
  • 9) Bug report template in email

There are many different elements you can include in your bug report, but below are some examples of the most important. Usually, the bigger your organization, the more detailed your reports need to be.

The indispensable elements are:

  • ID/name: Keep it brief and use correct terms. A best practice is to include the name of the feature where you found an issue. A good example could be ‘CART – Unable to add new item to my cart’.
  • Description/summary: If you feel the name is not sufficient, explain the bug in a few words. Share it in easy-to-understand language. Keep in mind that your description might be used to search in your bug tracking application, so make sure to use the right words.
  • Environment: Depending on your browser, operating system, zoom level and screen size, websites may behave differently from one environment to another. Make sure your developers know your technical environment.
  • Source URL: Make it easy for your developers spot the problem by including the URL of the page where you found the bug. Big time saver!
  • Visual proof: A picture is worth a thousand words. Although it might not be enough, a visual element like a screenshot or a video will help your developers understand the problem better and faster.
  • Steps to reproduce: A screenshot is a proof that you had a problem, but keep in mind that your developer might not be able to reproduce the bug. Make sure to describe, with as much detail as possible, the steps you took before you encountered the bug.
  • Expected vs. actual results: Explain what results you expected – be as specific as possible. Just saying “the app doesn’t work as expected” is not useful. It’s also helpful to describe what you actually experienced.
  • Optional: You can also include extra information such as the severity (critical, major, minor, trivial, enhancement), priority (high, medium, low), name of the reporter, person assigned or a due date.

Bugs can be reported in a number of ways. However, using a bug tracker is probably the best way for your organization to move bugs from reported to fixed and help your developers stay focused.

1) Reporting bugs in GitHub with templates

A large number of developers use GitHub to build software in teams. The original goal of GitHub was to help developers collaborate on code, but as the services grew, they added more features and become a project management tool for building software. GitHub has an issue tracker built in, which makes it easy for developers to keep track of bugs.

Try Marker.io for Github

Taking into account the suggested elements from above, a well documented GitHub issue might look like this:

github-bug-report-template

As you can imagine, filling out a bug report like this one can take a while. If you need to report dozens of bugs during a testing session, it could take you several hours.

Fortunately, you can speed up that process dramatically by using Marker.io for GitHub . Take a screenshot with Marker.io when you spot a problem on your website, add annotations to get your point across and in 1-click the tool will convert it into a GitHub issue. All the important technical information (e.g.browser version, operating system, screen size and zoom level) are automatically embedded into your screenshot and included in your GitHub issue – without you having to do any extra work.

You can even use the built-in bug report template before creating your issue and fill out the steps to reproduce the bug, as well as the expected and actual results.

marker-github-bug-reporting-template

If your team is on GitHub, consider signing up for a free Marker.io trial.

2) Reporting bugs in Jira with templates

Jira is a famous issue and project tracking software designed for development teams. It’s a bit complex for small teams, but it’s also very powerful – which is why some of the most well-known tech companies in the world use it.

Try Marker.io for Jira

I’m not going to review how Jira works, because it’s beyond the scope of this blog post. The important thing to understand is the concept of a Jira issue. In Jira, an issue is a ticket that enters the system. It can be a project task, a Helpdesk ticket or a software bug.

Bugs can be reported by anyone in the organization, so it’s important to define a process and a template that everyone can easily use.

A well documented bug in Jira looks something like this:

jira-bug-report-template

You can see that all elements of a well-reported bug are present, including: name/ID, summary, visual proof, environment, source URL, steps to reproduce, expected vs. actual results.

As you can imagine, filling out a bug report like this one can take a while. If you need to report dozens of bugs during a testing session, it could take you a while.

Fortunately, you can speed that process up dramatically by using Marker.io for Jira . Take a screenshot with Marker.io when you spot a problem on your website, add an annotation to get your point across. Marker.io will in 1-click convert it into a Jira issue. All the important technical information (e.g.browser version, operating system, screen size and zoom level) are automatically embedded into your screenshot and included in your Jira issue – without you having to do any extra work.

You can even use the built-in bug report template before creating your issue and fill out the steps to reproduce the bug, as well as the expected and actual results.

jira-bug report template

If your team is already using Jira, consider signing up for a free Marker.io trial .

3) Reporting bugs in Trello with templates

Trello is a free and super easy-to-use project management tool. Its ease of use is what makes it perfect for both small or medium size organizations.

Try Marker.io for Trello

For your bug tracking purposes, simply set up a board called bug tracking. I recommend creating the following lists: reported, accepted, in progress, to be validated, done. You can even use labels to define the importance of your bugs (critical, major, minor, trivial, enhancement). Next, start adding a Trello card for each bug.

Taking into account the previous suggested elements, a well documented bug report in Trello should look like this:

trello-bug-report-template

Side note: I published a post on Trello’s blog about managing your bug tracking with Trello .

All the elements of a well-reported issue are present, including: name, summary, visual proof, environment, source URL, steps to reproduce, expected vs. actual results.

As you can imagine, filling out a bug report like this one can take a while. If you need to report dozens of bugs during a testing session, it could take you a while.

Fortunately, you can speed up that process dramatically by using Marker.io for Trello . Take a screenshot with Marker.io when you spot a problem on your website, add annotations to get your point across and in 1-click the tool will convert it into a Trello card. All the important technical information (e.g.browser version, operating system, screen size and zoom level) are automatically embedded into your screenshot and included in your Trello card without you having to do any extra work.

You can even use the built-in bug report template before creating your card and fill out the steps to reproduce the bug, as well as the expected and actual results.

Marker-trello-bug-report-template

If your team is already using Trello, consider signing up for a free Marker.io trial .

4) Reporting bugs in GitLab with templates

With the recent acquisition of Github by Microsoft, an increasingly amount of teams are switching to Gitlab to manage the whole DevOps lifecycle in one place. All GitLab projects come with an issue tracker, making bug reporting and issue tracking a breeze.  

Try Marker.io for Gitlab

Ideally when a developer receives a new bug report, they would like new GitLab issues to have a similar structure to this:

While developers would want all Gitlab bug reports in GitLab to be as detailed as the screenshot above, this can drive reporters crazy! It’s just to much info and too many pieces of software. For reporters like clients, users and non technical colleagues, the GitLab interface can definitely be overwhelming.

Thankfully, you can speed up that process dramatically by using Marker.io for GitLab , the best way to report visual and highly actionable bug reports into GitLab, without ever leaving your website. Simply snap a screenshot, add annotations and click send! Marker.io will automatically capture all technical data from the reporter’s environment such as Browser, Operation system, screen size, etc…). Finally, if you want your reporters to follow a specific bug report template to help structure the issue description, simply switch on the template

If you’re team is running on GitLab, sign up for your free trial of Marker.io for Gitlab

5) Reporting bugs in Asana with templates

Asana has really become over the years the professional alternative to simpler project management tools like Trello. Although Asana is great for keeping track of tasks, an increasingly amount of teams are also using it as a bug tracker.

Try Marker.io for Asana

Ideally when a developer receives a new bug report in Asana, they would like new Asana tasks to have a similar structure to this:

As you can see, all the elements for a great bug reports are all in there! However, creating such a detailed bug report in Asana can be overwhelming for clients, users and non technical colleagues.

Fortunately, you can speed up that process dramatically by using Marker.io for Asana . Take a screenshot with Marker.io when you spot a problem on your website, add annotations to get your point across and in 1-click the tool will convert it into a Asana task. All the important technical information (e.g.browser version, operating system, screen size and zoom level) are automatically embedded into your screenshot and included in your Asana task without you having to do any extra work.

Finally, if you want your reporters to follow a specific bug report template to help structure the bug report into the Asana description, simply switch on the template to have the steps to reproduce the bug, as well as the expected and actual results.

If you’re team is running on Asana, start your free trial of Marker.io for Asana

6) Reporting bugs in Excel with templates

Reporting bugs in a spreadsheet can be a cumbersome process. However, smaller teams can still benefits from this method. If you’re team decided to report and track bugs in Excel, it’s important to define a template that everyone in the organisations agrees to.

In this template, you’ll find all the elements you need to report bugs in a structured way:

excel-xls-bug-report-template

Download the templates here:

  • Microsoft Excel (.xls) spreadsheet bug report template
  • Google Spreadsheet bug report template

7) Reporting bugs in Microsoft (MS) Word with templates

Although not optimal, reporting bugs in a .doc file can be a fast and structured way to report bugs to technical members on your team. As always, make sure that all necessary information is there. You don’t want your developers to have to come back to you, and ask for more information.

Here is what your bug report template should look like:

word-file-doc-bug-report-template

Click here to view in Google docs or here to download the .doc file for MS Word

8) Reporting bugs in PDF with templates

Reporting bugs in a PDF file is similar to the previous MS Word document option. PDFs are not very flexible, however it might be a requirement to use them inside your organization. If that’s your case, feel free to copy our template.

I’ve prepared the document from above in a PDF file for you to download here

9) Reporting bugs in email with templates

Most communication is still done through email. For example, if you’re a web agency client but the team didn’t give you a structured process to report bugs, you can always send them via email. To ensure your emails always follow the same structure, we recommend saving the email template below for your bug reporting.

bug-report-email-template

Copy paste the content in this text file or download the txt file .

Conclusion

Web and software testing is tough. A lot of people from different backgrounds and expertise need to give their feedback. Miscommunication can lead to huge delays and growing frustration. By establishing a process for reporting bug based on a fixed template, you can greatly reduce these problems.

— Marker.io blog —

Workflow tips

  • 5 reasons why bug tracking with Asana sucks (and how to fix it)
  • How to write a bug report that will make your developers happy
  • How Trello's Custom Fields will make you awesome at bug reporting
Software reviews

Trello vs. Jira: new 2018 detailed review

Are you struggling to decide whether Trello or Jira would help you track projects more effectively?Looking to learn more about each tool so that you pick the best solution for your team?

Workflow tips

Why can’t bug reporting and issue-tracking be easy?

How one web agency built a simple, yet powerful bug reporting and feedback tool that changed their workflow.

9 bug reporting templates you can copy for your web testing process

Discover Marker.io