Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
in my interview i was asked
there is a login page in which the forget password button is not working what will be Severity and Priority
and then he told me what if the Submit button not working along with it then what will be the Priority and Severity
and pls give me real time some(3) examples of
High Severity – High Priority bug
low Severity and High Priority bug
low Severity and low Priority bug
Severity of defect is determined based on how much business will be impacted due to this defect if goes in production. Business impact can be financial, compliance etc.
Priority of defect is determined based on how early you want defect to be fixed by development team. If majority of test cases in a test cycle are blocked due to defect then it will be marked as high priority defect.
Example -
High Severity – High Priority bug : Bug has both high business impact as well blocking majority of test cases in test cycle.
Low Severity and High Priority bug : Bug has low business impact but blocking majority of test cases in test cycle.
Low Severity and low Priority bug : Bug has low business impact and not blocking many test cases in test cycle.
No final answer as it really depends on business
But, as a general rule;
if business critical features are not working and no workaround are available => High Severity – High Priority bug
if a non-critical feature is not working but is deemed important by business => Low Severity and High Priority bug
if a non-critical feature is not working, and not deemed important by business => low Severity and low Priority bug (e.g. spelling error or minor layout stuff)
As for the non-working forget password button, I would probably classify it as Low severity / medium priority as manual work around via a customer service should be available. Medium priority to prioritize the bug above cosmetic changes.
If the non-working submit button is the login button => High Severity – High Priority bug as no login is possible
Basically, severity defines the impact that a given defect has on a tested system. Usually the severity is defined in terms of financial loss, damage to environment, company’s reputation etc...
Priority defines the order in which we should resolve a defect. Should we fix it now, or can it wait?
That leads to many possibilities and combinations. To give some real examples:
High Priority & High Severity: Log in functionality does not work on production website
Low Priority & High Severity: If an application or web page crashes when a deep hidden link is clicked, in this case clicking the link by an user is rare but the impact of application crashing is severe. So the severity is high but priority is low.
High Priority & Low Severity: If the company name is misspelled in the home page of the website, then the priority is high because it looks unprofessional and severity is low to fix it because it does not do much harm (of course it depends, there might be cases where misspelling company name in a way it offends someone might be severe)
Low Priority & Low Severity: This might be for example an incorrect font on rarely visited page
There can be of course more combinations, it depends on defined levels of severity and priority. There are usually four levels of severity(Critical, Major, Minor, Trivial) and three levels of priority(High, Medium, Low).
But as already said, there are no strict rules for prioritization and severity assignment because it is closely related to one's development process and business specifics It would be different for medical appliance and for an online shop.
Putting it in very simple terms:
Priority of a bug is decided on the basis of business impact whereas severity is decided on the basis of technical impact
If a bug is business critical, then generally the priority will be high. For example, on a website, if the brand name is misspelled or logo has some issue.
Higher the technical impact of a bug, higher the severity. For example, if a bug requires writing or changing code of a complex functionality that would impact multiple modules and might require a lot of development and testing effort.
That’s why the priority is generally decided or reviewed by product owner or business analyst. And generally the severity is decided by people on development side ( developer, development lead or technical architect )
For the examples that you have requested in your question, please refer to THIS link. It will provide you examples for below scenarios:
High Severity – High Priority bug
low Severity and High Priority bug
low Severity and low Priority bug
