- STLC Tutorial
- STLC - Home
- STLC - Overview
- COMPARISON - STLC and SDLC
- Testing Fundamental Principles
- STLC - Requirement Analysis
- STLC - Entry and Exit Criteria
- STLC - Acceptance Criteria
- STLC - Test Planning
- STLC - Test Case Development
- STLC - Test Environment Setup
- STLC - Test Execution
- STLC - Defect Life Cycle
- STLC - Defect Classification
- STLC - Test Cycle Closure
- STLC Useful Resources
- STLC - Quick Guide
- STLC - Resources
- STLC - Discussion
STLC - Defect Classification
Defects are classified from the QA team perspective as Priority and from the development perspective as Severity (complexity of code to fix it). These are two major classifications that play an important role in the timeframe and the amount of work that goes in to fix defects.
What is Priority?
Priority is defined as the order in which the defects should be resolved. The priority status is usually set by the QA team while raising the defect against the dev team mentioning the timeframe to fix the defect. The Priority status is set based on the requirements of the end users.
For example, if the company logo is incorrectly placed in the company's web page then the priority is high but it is of low severity.
Priority Listing
A Priority can be categorized in the following ways −
Low − This defect can be fixed after the critical ones are fixed.
Medium − The defect should be resolved in the subsequent builds.
High − The defect must be resolved immediately because the defect affects the application to a considerable extent and the relevant modules cannot be used until it is fixed.
Urgent − The defect must be resolved immediately because the defect affects the application or the product severely and the product cannot be used until it has been fixed.
What is Severity?
Severity is defined as the impishness of defect on the application and complexity of code to fix it from development perspective. It is related to the development aspect of the product. Severity can be decided based on how bad/crucial is the defect for the system. Severity status can give an idea about the deviation in the functionality due to the defect.
Example − For flight operating website, defect in generating the ticket number against reservation is high severity and also high priority.
Severity Listing
Severity can be categorized in the following ways −
Critical /Severity 1 − Defect impacts most crucial functionality of Application and the QA team cannot continue with the validation of application under test without fixing it. For example, App/Product crash frequently.
Major / Severity 2 − Defect impacts a functional module; the QA team cannot test that particular module but continue with the validation of other modules. For example, flight reservation is not working.
Medium / Severity 3 − Defect has issue with single screen or related to a single function, but the system is still functioning. The defect here does not block any functionality. For example, Ticket# is a representation which does not follow proper alpha numeric characters like the first five characters and the last five as numeric.
Low / Severity 4 − It does not impact the functionality. It may be a cosmetic defect, UI inconsistency for a field or a suggestion to improve the end user experience from the UI side. For example, the background colour of the Submit button does not match with that of the Save button.