Defect Severity & Defect Priority

-

● Severity Defect:​  

“ Severity of a bug depends on how much severe the bug is and the impact of the bug over operation of the program.”  For Example: ​ If an application crashes by clicking on some button then the severity of that issue is high and the priority is low. 

Defect severity can be categorized into three class:  
Major:​ 
It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.  
Medium:​ 
It causes some undesirable behavior, but the system is still functional.  
Low:​ 
​It won’t cause any major break-down of the system. 
  

● Priority Defect:​ 

“Priority of a bug depends upon the requirement of the project and how soon the bug needs to be fixed to deploy it.”   For Example:​ If the logo of the application is not correct or displaced then the priority of that issue is high and severity is low to fix it. 

Defect priority can be categorized into three classes:  
Low: ​
The Defect is an irritant but a repair can be done once the more serious Defect has been fixed.  Medium:​ 
During the normal course of the development activities defect should be resolved. It can wait until a new version is created.  
High:​ 
The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed. 
   
Examples of Severity and priority are 
1. ​High severity and Low priority: ​If an error occurs at some functionality which will use in rare conditions and not block the user to use the application. 
2. ​High Severity and High Priority: ​If an error occurs in some major functionality of the application like if the user is not able to submit the form and placing an order of some e-Commerce website or if users are not able to open the application.  
3. ​High Priority and Low Severity: ​If the logo of the company is not displayed properly or the spelling of the company name is wrong the priority of that issue is high because it needs to fix soon and severity is low because this issue will not block the user to use the application. 4. ​Low Priority and Low Severity: ​If there is some spelling issue in some paragraph of the application which is rare to access by the user
                                  Difference between Priority and Severity: 



















Comments

Post a Comment

Popular posts from this blog

Implicit and Explicit requirements

-
Implicit and Explicit requirements Explicit Requirements​ :    ● The Things business analyst Wrote Down.  ● These are the requirements explicitly stated or mentioned by the customer.  ● Explicit requirements are most commonly found in documents communicated by stakeholders to the development team.   ● This is the simplest type and the easiest to test.  ● The development team might take the form of an elaborate design specification, a set of acceptance criteria.  ● Explicit requirements in the form of claims that is, communications to end-users about things the software can do.   Implicit Requirements​ :  ● The Things client Will Expect  ● These are the requirements that are not explicitly stated by the customer, but implied or derived from the requirement stated by the customer.  ● These are all the things that users are going to expect that were not captured explicitly.  ● Examples include performance...
Read more

Software Configuration Management (SCM)

-
Software configuration management (SC) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SC helps in identifying individual elements and configurations tracing changes and version selection control and baselining.   SC is also known as software control management. SC aims to control changes introduced to large complex software systems through reliable version selection and version control.   Software Configuration Management does​ ​   ● Introduction to Software Configuration management and Configuration management for software Testers.  ● Software configuration management (SC) is the discipline for systematically controlling the changes that tae place during Software evelopment.  ● Software development software consists of a collection of items (such as program documents etc..) that can easily be changed. uring software...
Read more

Identified for Configuration Management

-
The term configuration item (CI) refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents software models and plans. The configuration-management system oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification change management status accounting and audits. This system aims to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.     Configuration Management Activities ​:     1. ​Configuration Item Identification ​:  ​In this phase, the item will be identified for making changes.  Example: ​Requirement document design document source code etc    2. ​Change Control ​: ​ Controlling the release and changes of the product throw out the software life cycle here CCB team will approve or disapprove changes prioritize the change...
Read more