Bug Classification - Severity, Priority and Triage

Severity is about the technical impact of a defect. Priority is about the urgency of the fix. Important is that severity is one of the factors influencing priority and that only priority should be used to decide what to fix next . For example, your project may have a policy to fix higher priority bugs p1 before fixing lower (p2 to 4); or to block the release of a product that has open, unfixed p1 bugs; or even require that a p1 bug be fixed immediately (in 4 hours, or the next patch) if it was found in a released, live product. The Severity of open bugs is often used to measure the overall quality of the product, or of a particular feature. Understandably, many projects use bug severity, along with other project or user data, to determine the priority of fixing a bug.

Severity
Sev 1 - System/Application crash, or data loss. Product/Service instability, major test blockage, broken build or failed new build
Sev 2 - Major loss of functionality or other severe problems (feature unusable; product crashes in obscure cases), Bug in major feature with complex workaround, or moderate test blockage.
Sev 3 - Minor functionality and feature problems; may affect 'fit and finish'. Feature problem with simple workaround, or small test impact.
Sev 4 - Very minor problem such as misspelled words (typos), unclear wording or error messages in low visibility fields, incorrect tab order in GUI, obscure feature broken, etc. Little or no test impact.

Note: Severity, priority ratings vary from company to company,and project to project

Priority
P1 - Fix by next build.
P2 - Should Fix soon, (specific timing based on test/customer “cost” of workaround, if exists.)
P3 - Fix (to replace customer workaround by next project milestone with related deliverable. )
P4 - Consider fix by upcoming release (somewhat trivial ticket, but may be postponed.)

Bug meeting - Triage:

Bug Triage Meeting is project meeting where software developer, software tester and business/product owner are the participants.

In most of the projects I worked, a bug triage meeting, is usually facilitated by test team lead. Triage team steps through each bug one at a time, reviewing about bug's severity, priority, and its impacts on development, test and business.

Bug Life Cycle - BLC

Bug life cycle starts when a bug is found by a tester. After that a tester has to do several things in different point of times.

The very first things to do before logging a bug is to make sure that this issue has already been identified or not. Simply, searching on bug storing database for similar issue. If bug is already has been entered; make sure it is still active and scenario is same that you have identified. If not reopen it and add more information (if repro. steps are different add your ) and bring this issue to developer's/team's attention.

Always avoid entering duplicate bug. Adding duplicate bug effects a tester image .

After tester entering a bug it must be assigned to someone, mostly to developer. (Eventually goes to developer). Developer checks bug and then fixes his code in same build, produces a new build with fix and assign bus to tester to verify it. Now tester needs to verify the fix, which is called regression testing. If bug has been fixed, it is tester's responsibility to close it. If not, the bug will be reactivated and cycle will starts all over again.