How do you decide if a QA issue is a defect?

Question

I've worked for several companies as a developer and have recently moved into QA automation at a new company. Each company is different and I have yet to see a way of handling this that I really like. All too often QA will say something is an issue and the response is either "well ya but it would be too hard and take too long to fix" or "it's not a bug, it's a feature!".
Has anyone found a reasonable way to determine if something that QA says is a bug needs to be fixed or not?

Answer 1

This is a duplicate of http://stackoverflow.com/questions/129655/survey-how-do-you-define-the-term-bug#129704

Answer 2

The way I used to do it was that one person (the Product Manager) was responsible for prioritising bugs and new features. The PM decided whether each item was a bug or a new feature, based on the following criteria:

• if the software does something that's just obviously wrong (i.e. not what anyone wanted or intended) then it's a bug.
• if the software does something counter to the design documentation for the software, and it doesn't have any obvious advantage, it's a bug.
• if the software does something that is not what a customer (or someone else) wants, but the behaviour conforms to the design docs, then it's a feature request.

The PM would discuss each bug or feature request with engineering as well as representatives of clients and on that basis (as well as common sense and experience) would assign a priority to each item. Additionally, engineering would be asked to indicate approximate timescales for each item, and the PM would use this to plan the next iteration.

In short, a bug is when the software does not do what the people who designed it planned for it to do, and a feature request is when someone wants the software to do something that wasn't planned for.

Answer 3

As a developer, I know you always get the bug that makes you swear (under your breath) at the QA - but I don't think the fix/don't fix decision should be given to the developer - as demonstrated by the excuses you mention!! The most humble of programmers resents bugs appearing in his/her code and thus can be tempted to give you a hard time. I think a little friction between testers and devs is a necessary evil (providing you buy them a beer at the end of the day!). 'It's not a bug it's a feature' is a common retort but sometimes valid, which is probably why an important person to involve is probably someone from the business side (if that makes sense in what you do).

In my experience, it is worth recording stuff even if they are not possible to fix right now - you can always assign a sliding priority scale and just fix down to a certain level. Regularly reviewing bugs with the tester/dev together can help as well.

Answer 4

The SCRUM methodology provides an answer to this question. The product owner decides if something is a bug which creates an item on the product backlog list. Then the item is scheduled into an iteration depending on its priority.

Answer 5

Functionality bugs and UI bugs are easy to find and less debatable. Design bug is the one which need to go through a BA and development team to get an opinion. Also environment related issues should be tracked separately and may not fall into bug category.

Answer 6

there are a number of ways. some of them:

1. Software requirements should be completely described. If you see that some requirement is not met, it is, obviously, bug.

2. You see that requirement is met, but in some non-obvious form. It is bug too. But this is situation when developer may say "all is fine" and try to close the bug. You could found your opinion (that defect exists) by:

   • examples how similar things are implemented in the same product.
   • examples how similar things works in similar products (e.g. gmail could be used as example of mail hosting and so on).
   • ask your sales and customer relationship managers what do people expect from the feature, how should it work from end user point of view.
   • use industry best practices.

3. You see that something works but could be improved. It is defect too :). It is similar to point 2 and all recommendation placed there are useful for this case too.

P.S. and discuss, discuss, discuss with people from other departments.