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, problem tracking/

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 with 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’.]