I am involved in a large development project in which we (a very small start up) are developing for an outside client (a very large company).
We recently received their first output from UAT testing of a fairly small iteration, which listed 12 'defects', triaged into three categories : Low, Medium and High.
The issue we have is around whether everything in this list should be recorded as a 'defect' – some of the issues they found would be better described as refinements, or even 'nice-to-haves', and some we think are not defects at all.
They client's QA lead says that it is standard for them to label every issues they identify as a defect, however, we are a bit uncomfortable about this. Whilst the relationship is good, we don't see a huge problem with this, but we are concerned that, if the relationship suffers in the future, these lists of 'defects' could prove costly for us.
We don't want to come across as being difficult, or taking things too personally here, and we are happy to make all of the changes identified, however we are a bit concerned especially as there is a uneven power balance at play in our relationship.
Are we being paranoid here? Or could we be setting ourselves up for problems down the line by agreeing to this classification?
Best Answer
You can say "Reported Customer Issue" or anything else if it makes people happy. I'm going to say "Bug" because it has such a grand history and is the industry standard term. In a brand new bug list, you might expect to fix near 100%. But the more bugs that are added to the list, the fewer you expect to fix. In fact, most bug tracking tools let you close bugs for various reasons: duplicate, feature-request, unable-to-reproduce, on-hold, additional-feedback-needed, etc.
The important thing is to capture the feedback and the actions taken on that feedback. We make it very clear to our customers that we get to choose what bugs we fix and what features we implement. We do it on the basis of what we think will make the most clients most happy, but it's our choice.
Be respectful in providing feedback on these bugs. If you aren't going to fix something, tell them why. Sometimes it's OK to say that you aren't ready to commit to a particular solution to a given bug. Or that a bug is out of scope for this release (or this product). Or that a bug in how the system works might be "fixed" through improved documentation (such as tweaking the UI or documentation so that users don't do what caused the bug). Obviously, if you fix some bugs, your client will be more open to your not fixing others.
If the customer has major problems using your software, no bug naming system will make them happy. If they love your software, the name won't matter either. Make great software, be respectful to your client and don't get hung up on bug categories.