H-P H-S – Login id & Password Encryption is not done at
H-P L-S – Company Logo is mismatch
L-P H-S - Session is not expiring after clicking on logout
L-P L-S - Client Side Validation for text box & Field
Hi everybody what I found is there is a little clarification
needed for simple concept of severity and priority.severity
shows the impact on the application which can be high or low
like system crash will have high severity.while priority
denotes how much it is important to fix the bug.so if system
crashes once in say 150 times then it will have low priority.
so examples for these are below:-
1.High severity & low priority :- If a application crashes
on very rare occasions and changes are very low of
crashing.so severity will be high but priority will be low.
2.High severity & high priority:- if a application crashes
very frequently and duly visible or first time the
application came from development team to the testing
3.Low severity & low priority:- it is merely just a
enhancement bug which the client wishes like changing the
background colour of user interface,also like adding a
button like 'back' to navigate previous page.
4.Low severity & high priority:- In this case if the name of
the company on its home page is misspelt will be considered.
So to find that in which category the bug comes always
remember one thing that Low severity bugs are mostly related
to GUIs and high severity bugs always related to things like
system crash.severity is always technical while priority is
for business purpose.
A good way to clarify this may come from the so-called
"Failure Mode Effects Analysis" process in quality Management.
A triad of Severity (S), Occurrence (O) and Detectability
(D) produces a so-called "risk priority number" (P).
"S" - "How much money do we lose if this happens".
"O" - "What ratio of business processes are affected?"
"D" - "Can we find out in time if the defect occurred?"
If S is high, but O + D are low, then P is low.
If S is high and O + D are high, then P is high.
If S is low and O + D are low, then P is low.
If S is low and O + D are high, then P is high.
S high, O + D low:
Once a year, the database must undergo housekeeping or
tablespaces will one day overflow, crashing the entire
system, denying every business process until the tablespace
is freed and the application restored. Unfortunately, the
script does not work.
This is a very high severity defect.
This is very easy to detect (monitor tablespaces) and will
not occur quickly (a year down the line) so the priority is low.
S high, O + D high:
The corporate SOA "swallows up" fire-and-forget requests for
a certain constellation of parameters.
As you cannot know when a request got lost, you do not know
when or which business processes may fail.
As such, the priority is very high.
S low, O + D low:
The "undo" functionality of an application produces a
warning message when no change has been made prior to
execution. This irritates the user as "no action" or a
grayed-out button would be preferred.
Other than that, there is no business impact.
As such, there is a low priority: The developer might fix it
when by chance they are updating the module, otherwise no
sane project manager would waste budget on a fix.
S low, O + D high:
This is the typical scenario of "Defect with Business
The "Help" function from a portal sporadically causes the
servers to crash.
(There is a very easy workaround: just don't use the "Help",
and therefore people can still commence every business process.)
Something, however, still needs to be done, and that
quickly. An easy fix may be to disable "Help" - but you just
can't go live with that thing!
Description--->There are 5 modules in my application.
On every module there is a date box.
In 1st module, date box is used for 2
My Question is ---> Should I have to write test cases for
date box for every modules & submenus?