0

I am confused about whether the severity of the defect is set based on its impact on business (getting the desired result) or on testing (its impact on continuing the testing of a feature).

Example: Say the system contains two tools Quick Search and Search by Attribute. I used quick search to search for landmark but an error message is displayed. So as a workaround (to get the desired result) I used the search by attribute tool and get my result properly.

Now from the business point of view, the defect has a minor impact on the user since he is able to get expected result using an easy workaround.But from a testing point of view, it is critical (work stoppage) since as a tester I am not able to continue testing the tool.

So what is the severity of such defect: Critical or Minor?

Improve this question
2

It Depends

If the search feature is considered a single module with two flavors, then your defect is not as severe because part of the search is working.

If each search type (Quick Search and Search by Attribute) is considered a separate feature, then your defect is critical to the Quick Search feature because that feature can't be used.

This is independent of the business impact (which is an indicator of the chance of a user encountering the bug and how much it will affect them), or the priority (how much the company wants that bug fixed).

Improve this answer
1

Severity is based on its impact on funcionality of the product in the first place.

Imagine a point of sale with possibility of contactless payment. You want to pay using NFC in your mobile phone or a contactless credit card. But it's not working. Well, you might think it's a minor defect because you still can pay using some workaround - your chip credit card or cash. But in fact it is a critical defect because contactless payment function is not working.

Same thing in your case, as you describe it, the defect is not minor at all - the function "Quick Search" is not working. And it doesn't matter if a user can do some workaround to get the desired result.

Improve this answer
7
  • Don't agree - the type of workaround and type of user (in-house or client) may strongly influence the severity. By your reasoning, everything that doesn't work is critical, so all functional defects are by definition then critical.
    – FDM
    Dec 7 '17 at 9:58
  • @FDM If a specified function is not working, it doesn't matter what type of workaround you use. The feature is not working - over. It IS a major defect.
    – Embedded
    Dec 7 '17 at 10:01
  • @FDM what you mean by type of workaround? and what you consider the severity of the defect I mentioned in my question
    – user3584259
    Dec 7 '17 at 10:30
  • @Embedded no point in trying to explain myself further, but boy, I would love to see the bell curve of your defects' severity/priority. :D
    – FDM
    Dec 7 '17 at 10:39
  • @user3584259 Extreme example: users can find shortcuts (or workarounds) for processes and even prefer to use this way instead of the original process. In this case they couldn't care less if the original process worked or not, because they never even use it. So if in practice nobody will use your Quick Search, nobody will care whether it works. The inverse is of course also true. :)
    – FDM
    Dec 7 '17 at 10:41
1

First of all, I think it makes a big difference if this feature is already live.

If the Search is already in use by business... then (A) this defect might have come in via incident management. The user might have indicated how important it is, or the product owner can verify it with business when turning the incident into a backlog defect. Or (B) a tester might have seen it, while users didn't even bother to report the issue (or didn't notice). This likely indicates a very low business impact, but should be verified with the product owner or business.

If the Search is a new feature not yet released... then usually the tester sets the severity (how bad do I feel this is?). Presuming this is your situation, I would say:

  • Don't mix up priority and severity. In your example, the severity could be Medium (or even Low) because the business process can continue without perceivable loss of money. But the priority can be High, if it should be fixed and tested before the sprint or project ends (see my last paragraph regarding this). And ultimately, developers should work in order of priority (regardless of severity).

Further thoughts:

  • Some defect management tools have a field 'Blocking'. This could also be used to provide a work order to developers.
  • Do you work with a Definition of Done and/or Exit criteria? For example, it might say that no story is finished if there are Critical/Major defects open (severity) or High/Medium defects open (priority). This also eliminates any discussion regarding what should be fixed by when.
Improve this answer
4
  • Yes Iam working with severity definition, the exit criteria mention that No Critical/Major defects should be available in the system. but in the above scenario, we consider the severity as minor, so can we deleiver and tell the client he can use a workaround?
    – user3584259
    Dec 7 '17 at 10:28
  • If every user will start complaining and logging incidents to your helpdesk (and you can foresee needing to hotfix this issue) then the severity might be higher then you think - because your company will invest resources in the issue (and thus lose money by definition). Never forget: a defect is cheaper the earlier you fix it! Also, having a High priority I can't imagine this won't get fixed before the deadline. :)
    – FDM
    Dec 7 '17 at 10:36
  • Still I didnt get answer to my question. Is the defect severity related to its impact on testing or its impact on customer business. In scenario I have given in question the defect has a workaround from the business point of view so it might be minor, but for testing it is critical since it prevents me from continue my test. So what is the severity Critical or minor?
    – user3584259
    Dec 7 '17 at 13:04
  • It's priority that determines WHEN a defect is fixed, why are you so focused on severity?
    – FDM
    Dec 7 '17 at 14:12
0

Severity is based on impact on users/paying customers.

If QA needs to adapt the tests: if the cost to adapt is less that cost to fix the bug, QA should adapt.

QA is not a golden calf to be worshiped. QA is one of the tool/group (together with business analysis, architecture, design, coding, production support) in the process of delivering quality products to customers.

One consideration is: if defect broke existing feature, how important is to deliver consistent product? How important is that feature to customers, do we have a workaround, and how cumbersome is it?

As everything in engineering, answer is "'it depends", because it is a compromise between many competing priorities.

Improve this answer
0

Severity of a bug means how bug prevents User to complete desired action in everyday use.

If User can find results by using "Serach by Attribute", then there is a workaround so severity of a bug goes down to "Major".

If there is no workaround, its Critical or Blocker.

Improve this answer
1
  • but cannt we consider the severity as minor since the workaround is simple and direct forward?
    – user3584259
    Dec 11 '17 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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