Real QA Testing

How to classify bugs

April 30, 2019

I’m writing this since I’ve finally had enough of poorly titled or duplicate bugs. I’ve also talked about good ways to title bugs in the past in case you’d like some more color on this subject.

Having properly classified bug tickets will help your team appropriately triage and schedule bug fixes as to not cause loss of development cycles. If your development team uses Agile, this could be a very helpful discipline. Anything helping your business know how something is supposed to work, how to recognize when it doesn’t work, and be able to say what’s broken is going to pay dividends in shipping quality software.

A good question to ask here is how many duplicate bugs are being filed by your QA team? If that number is more than 1, there is a bug classification problem. Duplicate tickets do happen and that’s OK, but knowing why the bug ticket was duplicated is important; duplicate bug tickets are duplicate work and a loss of productivity (money).

It is an ideal setup to make sure your QA team is testing against a spec and not just out of the blue. What I mean by this is testing should strictly follow a documented script from start to finish. Once the end of the script is reached, testing should halt and the results need to be published to a developer or product manager. Testing should not be done on a “feels good / bad” basis or involve the opinion of a QA employee. Influence by QA teams should be done in the planning phase of the user story and their feedback should be integrated into the requirements before development and testing begins.

Lastly, one common problem I routinely encounter is regression bugs in the product producing different bug titles. If this happens, it’s definitely a symptom of not understanding the product and not having explicit specifications to say what is happening is indeed a bug. If it is not possible to determine what is expected to a explicit extent, then what’s broken can’t reliably be measured.


This website talks about sensical approaches to QA testing and how to really know that your application does what it needs to do day in and day out.