Skip to main content

What to log in a bug?

Bugs are a testers bread and butter, it's what we live on and thrive on raising.

However, my pet hate are bugs that just aren't very descriptive. I've seen bugs in the past with the simple message "Search is not working"... This wastes time of a developer who will then have to debug and find out for themselves when/where search isn't working, why it isn't working and then fix the issue. It also reflects badly on QA, which in previous posts is something we have to fight against!

This does tie in when should you raise a defect (more on this in a future post), as I like to go by the principle of if it will take longer to raise a bug than to fix it then don't raise it and just speak to a developer and explain the situation, giving them a walk through if needed, and then wait for them to fix it and test it again. Obviously this isn't always the route that is chosen, and when a fix for the issue will take a lot of investigation or time to fix, then a bug is to be raised.

What to log in the bug?

I find any information that you, as a QA feel would help the Developer fix it is a good start.

This can be (but not limited to) the following:

  • Title
  • Description - Usually a descriptive summary of what the bug is, how it is reproduced, the effects of the bug, and areas that are affected by said bug
  • Severity - How severe is the bug? Often this can be given as a 1-5 number, with 1 being the most critical and absolutely blocking anyone from doing any testing on the system, to 5 which can often be a minor cosmetic issue. Often the company you are at will have a defined Severity list... if not, I think it's best you create one ASAP!
  • System Specification - This can vary depending on the system under test, if a website is under test, useful information here would be things like Browser type, Browser version, however if a windows app is under test, then obviously windows version with the version number, RAM, CPU etc would be useful for a developer
  • Associated Test Cases - List here any test cases that are failing as a result of this test, this ensures there is traceability and also helps when the bug is fixed to identify the minimum tests that need to be run
  • Build Number - Was a specific build responsible for the bug? If so raise it here. 
  • Environment - Which environment the bug was found in, was it a UAT environment? A development environment? etc.
  • Attachments - Not always a necessity, but things like a screenshot are often good here.
  • Status - This is important for following the progress of the bug throughout it's life. 
Often, people will say to put in a Business Priority, this to me isn't something that should come from a QA, and thus isn't always included in a bug template, if you wish to include this field (which can be useful in deciding what bugs to fix) then speak to the Product Owner, explain the bug, explain the issues and try and come to a conclusion together on the Business Priority in getting this bug fixed.

To me, the more information you can include in a bug the easier it will be for a developer to recreate, investigate and hopefully fix the issue. 

There are tools you can get that can record the interactions with the browser (I will discuss useful addons in later posts for browsers) and thus a video can be produced which will aid the developer in viewing the steps required to recreate the issue.

So taking the bug above, which was labelled as "Search isn't working", we can apply the above template to it and achieve the following.

  • Title : When Searching an "Oops Something has gone wrong page is shown"
  • Description - When the user searches for a search term on any page, then an Oops Something has gone wrong page is displayed. The Server logs show the following error in the Event Viewer:

    " ERROR - Failed to establish connection to XXX "

    The values in the web.config for the search Endpoint are:

    " XXXXX "

    Calling the search API directly also does not generate any results.

  • Severity - 2
  • System Specification - The bug occurs under any browser.  
  • Associated Test Cases - 52342, 234234
  • Build Number - 0.8742
  • Environment - http://ajh-web-dev-23
  • Status - New
(The screenshot in this instance doesn't really add much to the bug report, but it can help the developer in other cases, most notably on browser specific issues where elements are misplaced etc)

From the above bug the developer will know exactly what has already been checked, they can see immediately if the endpoint is correct, and even that it's not an issue with the website as the API directly isn't generating any results.

I think you'll agree that the above bug is far more informative than "Search is not working" and will save time from the developer and even the QA in having to play a game of information ping pong with the developer in getting the correct information out of the QA! This will be the first impression the developer gets of the bug, so make it as informative and easy to follow as possible.


  1. Nice post. I've had lots of discussions about this over the years, and come to the conclusion that you should always assume the person reading the bug report doesn't have any intrinsic knowledge of the system. Therefore, don't use any special terms/abbreviations that are only known internally, and add a step-by-step guide to reproducing the bug. Consider it a "how to recreate this issue for dummies". :)

  2. Apart from the ones mentioned above, I usually also like to include the following details in a bug report:

    Title: Dev's/Product guys in my current company like to know priority and severity at the start of the title, starts with P0;SH (sounds like posh but this is showing that this is a blocker bug. Example: P0;S-H When Searching an "Oops Something has gone wrong page is shown"

    Severity - have 3 levels, High - blocking user from doing something, Medium - Nothing obviously noticeable, Low - Affects nobody and no harm is done.

    Priority - signifies how quickly a bug needs to be fixed. And I appreciate your comments on this one as I have also noted that testers usually tend to mark bugs with the highest possible priority to any bug they log, but this can cause issues with Dev's because they will not take this field seriously in the future and lose respect. I think testers should put priority on bugs anyway, and able to justify this because they know the bug so well and are in a position to guess this field. This always be triaged later with the Product owner and scrum master.

    Bug Type: Functional/UI offset or Type/ Data issue

    Reproducibility: Always/intermittent use of this field is to specify the degree of reproducibility of the issue. Does the bug reproduce consistently every time that some steps are followed? or if is it a random bug?

    what are your thoughts on this one?


Post a Comment

Popular posts from this blog

Advantages of using Test Management tools

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager...
In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools.
Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block. 
One of the more popular tools is that of Microsoft Test Manager, it's big…

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 

By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

        public static void AfterTestRun()
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))

        private s…