2

Here is the scenario where I have difference of opinion with the developer.

We have this module that needs say - a username, password and server-IP-address as inputs from the user. First scenario, if all information is right, the user is able to get the functionality working. Second scenario, if any of the information is incorrect or if server is down or unreachable or rejects the user, functionality does not work for the user.

Now QA logged a bug saying - in second scenario, the user is not provided with a feedback error or log message in the logs specifying the reason for failure. She marked it as a critical bug. However, the developer downgraded it to Major from Critical. His argument is the feature is working as expected and not providing error or log message is non-critical issue. My take is if there is a failure and if we are not providing basic failure reason as error or log, the feature is not working as expected. It is an implicit requirement to provide basic error feedback so that user could take action based on the failure reason.

What is your say ?

PS -(Blocker, Critical, Major, Normal and Minor are our bug severity)

Improve this question
3
  • 6
    It's a matter of requirements and priorities for your particular project, so nobody here can answer this for you. In general, if members of your team cannot agree on requirements and priorities between themselves then it would typically fall to your product owner- i.e. whoever in your organisation has the ultimate authority and responsibility for defining things like your project's scope, requirements, priorities, etc.
    – Ben Cottrell
    Mar 13, 2017 at 6:49
  • Was logging the failure a specified requirement of the functionality the developer was implementing, or part of a general "definition of done" applying to all functionality added to the product? If not, it's arguably not actually a bug at all, but a new feature to be prioritised for implementation like any other.
    – jonrsharpe
    Mar 13, 2017 at 7:39
  • 3
    The real issue here is that you don't appear to have an agreed definition for your bug severities. Get that sorted out, and your problem should go away.
    – Kramii
    Mar 13, 2017 at 11:17

4 Answers 4

Reset to default
0

I like to have a zero-defect policy, which makes it so much easier to classify defects.

enter image description here

Who should do this classification? I would leave the classification to a business owner. If I was a business owner here I would make it an improvement, it seems to that error handling is missing.

Still if this was during the development of a new feature, so something not yet released. I would push the QA and Development to pair-test and improve this before it is shipped. But even then priorities might differ, so make sure you discuss it with someone who sets the priorities. Most often this is not a QA nor a developer.

Improve this answer
5

Remember that if everything is high priority, nothing is. There is no point in only using blocker, critical and major, ignoring the lower priorities.

You should create a policy defining what those labels mean and what the consequences are.

For example we use them roughly like this:

Blocker

Downtime, essential features don't work, incorrect payments, public security vulnerabilities...

In Production: Every minute counts. Work through lunch/outside business hours. Skip meetings. Cut testing short to speed up deployment.

Before release: Deploying this is out of question.

Critical

Significant but contained breakage. Correctable data corruption that only affects a small minority of users.

In Production: Try to fix it today, but tomorrow is acceptable as well. Takes precedence over ordinary task prioritization. Skip longer/less important meetings. Still test it properly before deployment. Justifies a hotfix/deployment by itself.

Before Release: Delay announced releases, fail customer committed deadlines if necessary.

Major

Less important features don't work. No data corruption or long term impact. Annoyances to the customer with acceptable workarounds. An affected customer won't be happy, but can live with the limitation/workaround in the short term.

In Production: Fix it within a week or so. More important than most new features, but business as usual. Roll it into the next deployment after completion.

Before Release: Delay discretionary releases, but not announced / committed releases.

Normal

On equal footing as typical new features.

Minor

Misspellings, small graphical glitches

I'd probably classify your issue as major on this scale, or possibly only normal if it's a rarely used feature (especially if it's not customer facing).

Improve this answer
2

An implementation defect exists when there is a difference between expected behavior and actual behavior. This should be a matter of fact, not opinion.

If the actual behavior is not defined, it's not a defect, it's a requirements gap. It should be addressed by the business analyst who owns the requirement set.

I would suggest in the case of logon, a specific error message is not only unnecessary, but it may be harmful, and is contrary to best practice recommendations. However, security is always a balance between cost, risk, and convenience, and sometimes an organization will opt to provide at least some information in the signon error message. That decision does not lie with you or with QA, but with the business stakeholders.

Improve this answer
-2

While @Ben Cottrell is correct, I would suggest that you try to view the severity from the eyes of the user of the system. How does he cope with missing feedback? Try to make that viewpoint clear to the devs, too - see are not programming for someone who can see the source code at any time, they are programming for someone who wants to work with the interface of the system.

Generally, you should strive to make your system as easy to use as possible and most of the time, error messages are a critical part of that goal. Remember all the times where the system said and you had no idea what went wrong? That's your system now - your users will love it! I really like the explanatory errors that RavenDB throws in many places - describe what the problem was and what you can do to correct it. Sure, that's a big string you throw, but it's much more useful as "error 42"

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.