Severity Value : S1 : Catastrophic Blocking :
The use case cannot be completed with any level of workaround. Problem causes data loss, corruption, or distortion. There is defective program functionality with no workaround. A system or product crash or fatal error occurs. Program produces an incorrect result, particularly when the result could cause an incorrect business decision to be made. Problem causes inability to use the product further. Problem results in considerable performance degradation, (i.e., 3+ times longer than requirement). The error will definitely cause a customer support call. A severity 1 bug would prevent the product from being released.
Severity Value : S2 :Serious (Critical/Major) :
The failure is severe and can be avoided with some level of workaround. There must be some means of completing the use case, however,the workaround is undesirable.. Program does not function according to product or design specifications. Product produces data or results that are misleading to the user. Problem results in performance degradation that is less than required (i.e., takes twice as long). There is a serious inconsistency or inconvenience. Problem is likely to cause a customer support call.
Severity Value : S3 : Normal
Soft failure, the main flow of the use case works but there are behavioral or data problems. Performance may be less then desired.Problem is a of less intensity or typographical issue. There is a minor functional problem with a reasonably satisfactory workaround. Problem is a minor inconvenience. Problem is a non-intuitive or clumsy function. Problem is not likely to cause a customer support call. A defect that causes the failure of non-critical aspects of the system. . The product may be released if the defect is documented but the existence of the defect may cause customer dissatisfaction.
Severity Value : S4 : Small (Minor) :
There is no failure, the use case completes as designed. Fix would slightly improve the use case behavior or performance. A minor condition or documentation error that has no significant effect on the Customer's operations. Also: Additional requests for new features and suggestions, which are defined as new functionality in existing License Software.Generally, the product could be released and most customers would be unaware of the defect's existence of only slightly dissatisfied.Such defects do not affect the release of the product.
Priority Value : P1 :
FIX the bug ASAP
Priority Value : P2 :
Bug can be fixed before current itteration/minor release.
Priority Value : P3 :
The bug is very minor. A fix for this defect is not expected during the current itteration/minor release.
Priority Value : P4 :
This defect does not need to be addressed in the current final release.
Type Of Defect :
High Severity & Low Priority (S1/S2 & P4) :
1) An application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report. This is a high severity fault but low priority [Exception : If this defect is discovered during last week of the year] because this fault can be fixed in the next release as a change request.2) An inability to access a rarely used menu option may be of low priority to the business, but the severity is high as a series of tests cannot be executed, all dependent on access to the option.
High Severity & High Priority (S1/S2 & P1) :
1) If there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.
Low Severity & High Priority(S4 & P1):
1) If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.
2) A spelling mistake would be deemed as a low severity by the tester, but if this mistake occurs in the company name or address, this would be classed as high priority by the business.
Low Severity & Low Priority(S4 & P4) :
1) If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priori
In simple words, severity depends on the harshness of the bug. In simple words, priority depends on the urgency with which the bug needs to be fixed.
It is an internal characteristic of the particular bug. Examples of High severity bugs include the application fails to start, the application crashes or causes data loss to the user. It is an external (that is based on someone's judgment) characteristic of the bug.
Examples of high priority bugs are the application does not allow any user to log in, a particular functionality is not working or the client logo is incorrect. As you can see in the above example, a high priority bug can have a high severity, a medium severity or a low severity.
Its value is based more on the needs of the end-users. Its value is based more on the needs of the business.
Its value takes only the particular bug into account. For example, the bug may be in an obscure area of the application but still have a high severity. Its value depends on a number of factors (e.g. the likelihood of the bug occurring, the severity of the bug and the priorities of other open bugs).
Its value is (usually) set by the bug reporter. Its value is initially set up by the bug reporter. However, the value can be changed by someone else (e.g. the management or developer) based on their discretion.
Its value is objective and therefore less likely to change. Its value is subjective (based on judgment). The value can change over a period of time depending on the change in the project situation.
A high severity bug may be marked for a fix immediately or later. A high priority bug is marked for a fix immediately.
The team usually needs only a handful of values (e.g. Showstopper, High, Medium and Low) to specify severity. In practice, new values may be designed (typically by the management) on a fairly constant basis. This may happen if there are too many high priority defects. Instead of a single High value, new values may be designed such as Fix by the end of the day, Fix in next build and Fix in the next release.
I hope that you are now clear about the difference between severity and priority and can explain the difference to anyone with ease.
Powered by Blogger.
CMM Level 5 companies list List of CMM-5 Certified Software Service Companies in India Listed in no particular order. The purpose of this l...
A formal technical review is a software quality assurance activity performed by software engineers (and others). The objectives of the FT...
The test case design techniques are broadly grouped into two categories: Black box techniques, White box techniques and other techniques tha...
The spiral model, originally proposed by Boehm , is an evolutionary software process model that couples the iterative nature of prototyping ...
The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. ...
Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements...
The spiral model suggests a framework activity that addresses customer communication. The objective of this activity is to elicit pro...
Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycl...
V-Model: The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identifie...
Severity Value : S1 : Catastrophic Blocking : The use case cannot be completed with any level of workaround. Problem causes data loss, corr...
- A Quick 10-Step Guide (1)
- Black Box Testing (3)
- Bug Life Cycle (2)
- Certifications (3)
- CMM level (2)
- Comparsion (1)
- Configuration Management (3)
- Cookie Testing (1)
- Defect and Failure (1)
- Functional and Non-Functional (1)
- Functional Testing (1)
- Inspection and Walkthrough (1)
- Interview Software Testing (1)
- ISTQB Question Paper Dump (3)
- Load and Stress Testing (1)
- QA and QC (3)
- QA vs QC (1)
- Regression vs Retesting (1)
- RTM (1)
- SDLC (2)
- SDLC Model (5)
- Severity and Priority (1)
- STLC (2)
- Test Cases (4)
- Test Entry and Exit Criteria (1)
- Test Plan (4)
- Types of Testing (2)
- V Model and W Model (1)
- Validation and Verification (2)
- Web Testing (2)
- White Box Testing (1)
- bipin singh
- ▼ May (5)