| |
| |
More Resources
Some mistakes are made so often, so repeatedly,
by so many different people, that they deserve the label Classic Mistakes.
More...
Here are a few things to think about
when coding your error-handling routines and designing your error messages.
More...
|
|
|
| |
Have Something
to Share
software testing tip, interesting bug, or had an
interview lately?
Send us an Email.
|
|
|
| |
Promote Your
Products or Services
Interested in promoting your products on
SQAtester.com?
If so, we think you'll like
our Product Storefront Program.
The concept is simple.
More...
|
|
|
| |
Learn more material at a Fraction of Price!
Get the training that will help you face the challenges
and meet the demands of today's competitive market place.
Programs
Offered: Oracle DBA, Cisco Networking,
Software Testing & Programming. More...
|
|
|
| |
Software Team
Solutions That Fit.
Managed well, training is an effective
and simple way to improve organizational results, capabilities and personnel motivation. More...
|
|
|
|
|
| Defects Severity and Priority |
 |
_____________________________ |
|
Question:
One question on the defects that
we raise. We are supposed to give a
severity and a priority to it. Now, the severity can be Major, Minor or
Trivial and the Priority can be 1, 2 or 3 (with 1 being a high priority
defect).
My question is - why do we need two parameters, severity and priority, for a defect Can't we do only with one?
Posted by Nishant
Answer:
It depends entirely on the size of
the company. Severity tells us how bad the defect is. Priority tells us how soon it is desired to fix the problem.
In some companies, the defect reporter sets the severity and the triage team or product management sets the priority.
In a small company, or project (or product), particularly where there aren't many defects to track, you can expect
you don't really need both since a high severity defect is also a high priority defect. But in a large company,
and particularly where there are many defects, using both is a form of risk management.
Major would be 1 and Trivial would be 3. You can add or multiply the two values together (there is only a small
difference in the outcome) and then use the event's risk value to determine how you should address the problem.
The lower values must be addressed and the higher values can wait.
I discovered a new method for Risk Assessment. It is based on a military standard, MIL-STD-882. If you want a copy
of the current version, search for MIL-STD-882D using Google or Yahoo! The main area of interest is section A.4.4.3
and its children where they indicate the Assessment of mishap risk.
They use a four-point severity rating (rather than three): Catastrophic; Critical; Marginal; Negligible. They then
use a five-point (rather than three) probability rating: Frequent; Probable; Occasional; Remote; Improbable. Then
rather than using a mathematical calculation to determine a risk level, they use a predefined chart.
Blocker: This bug prevents developers from testing or developing the software.
Critical: The software crashes, hangs, or causes you to lose data.
Major: A major feature is broken.
Normal: It's a bug that should be fixed.
Minor: Minor loss of function, and there's an easy work around.
Trivial: A cosmetic problem, such as a misspelled word or misaligned text.
Enhancement: Request for new feature or enhancement.
Posted by Walter Gorlitz
Answer:
Severity Levels can be defined as
follow:
S1 - Urgent/Showstopper. Like system crash or error message forcing to close the window.
Tester's ability to operate the system either totally (System Down), or
almost totally, affected. A major area of the users system is affected by the incident and it is significant to
business processes.
S2 - Medium/Workaround. Exist like when a problem is required in the specs but tester can
go on with testing.
Incident affects an area of functionality but there is a work-around which negates impact to business process.
This is a problem that:
a) Affects a more isolated piece of functionality.
b) Occurs only at certain boundary conditions.
c) Has a workaround (where "don't do that" might be an acceptable answer to the user).
d) Occurs only at one or two customers. or is intermittent
S3 - Low. This is for minor problems, such as failures at extreme boundary conditions that
are unlikely to occur in normal use, or minor errors in
layout/formatting. Problems do not impact use of the product in any substantive way. These are incidents that are
cosmetic in nature and of no or very low impact to business processes.
Posted by Aileen
 Share your thoughts on Bugs and Fixes in SQAtester Group.
 E-mail to a Friend.
|
| Books to Read |
|
________________________________________ |
|
|
|
Testing Applications on the Web
Written by a true authority in the field, Hung Q. Nguyen's Testing Applications on the Web is a nicely comprehensive
guide to virtually every conceivable aspect of software testing. It's filled with must-have background information
for any test engineer or manager who's testing thin-client. More...
|
|
|
|
Testing Computer Software, 2nd Edition
The original printing of Testing Computer Software set the standard for the emerging field of test engineering
with a full tour of the state of the art in managing the testing process. The reissued text makes this classic
out-of-print text available once again. Though it relies heavily on older. More...
|
| Categories |
|
________________________________ |
| Community |
|
________________________________ |
| Specials |
|
__________________________________ |
| Millions of titles discounted up to 40-90% off. Great
low prices on your favorite books. More... |
|
Find all of your favorite software.
More... |
|
|
