Comparison between Severity and Priority
Severity defines the impact that a given defect has on the system. A severe defect may cause the system to crash or leads to an un-defined state.
- Should we fix it now, or can it wait?
- How difficult is it to resolve?
- How many resources will be tied up by the resolution?
Example Issue 1 (system crash) is definately severe, may be difficult to resolve, but only happens rarely. When should we fix it? Contrast that with the second issue (spelling error). Not severe, just makes you look bad. Should be a real easy fix. One developer, maybe 10 minutes to fix, another 10 to validate (if that). Which should get the higher Priority? Which should we fix now?
I'm going to recommend fixing the typo immediately, and if there is sufficient time, fix and resolve the blue screen before the next build. Many commercial defect tracking systems have either Severity or Priority. Some may have both. Personally I know of only one. But others allow you to modify existing fields or add additional fields. Of course those are severely lacking in other areas.
Bottom-line: you need to define both Severity and Priority for your application, and based on your user's needs.
well, nice description given for serverity and priority.....
ReplyDeleteit's very hard to assign priority rather serverity as a tester we will set high priority for the cosmetic (spell mistake) but for management might be having different prosepective:)
yes, you are right, management prospective is always different, but thanks for the feedback :)
ReplyDeleteVery Nice and useful post. Thanks for sharing this.
ReplyDeleteYou can get info on Severity and Priority as well with some guidelines with different