Priority and Severity

Q. What is a test strategy?

Answer:
A test strategy must address the risks and present a process that can reduce those
risks.
The two components of Test strategy are:
a) Test Factor: The risk of issue that needs to be addressed as a part of the test
strategy. Factors that are to be addressed in testing a specific application
system will form the test factor.
b) Test phase: The phase of the systems development life cycle in which testing
will occur.]

Q. When to stop testing?

Answer:
a) When all the requirements are adequately executed successfully through test
cases
b) Bug reporting rate reaches a particular limit
c) The test environment no more exists for conducting testing
d) The scheduled time for testing is over
e) The budget allocation for testing is over]

Q. Your company is about to roll out an E-Commerce application. It is not
possible to test the application on all types of browsers on all platforms and
operating systems. What steps would you take in the testing environment to
reduce the business risks and commercial risks?

Answer:
Compatibility testing should be done on all browsers (IE, Netscape, Mozilla etc.)
across all the operating systems (win 98/2K/NT/XP/ME/Unix etc.)]

Q. What’s the difference between priority and severity?

Answer:
“Priority” is associated with scheduling, and “severity” is associated with standards.
“Priority” means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency). “Severity” is the state or quality of
being severe; severe implies adherence to rigorous standards or high principles and
often suggests harshness; severe is marked by or requires strict adherence to
rigorous standards or high principles, e.g. a severe code of behavior. The words
priority and severity do come up in bug tracking. A variety of commercial, problemtracking/
management software tools are available. These tools, with the detailed
input of software test engineers, give the team complete information so developers
can understand the bug, get an idea of its ’severity’, reproduce it and fix it. The fixes
are based on project ‘priorities’ and ’severity’ of bugs. The ’severity’ of a problem is
defined in accordance to the customer’s risk assessment and recorded in their
selected tracking tool. A buggy software can ’severely’ affect schedules, which, in
turn can lead to a reassessment and renegotiation of ‘priorities’.]