Software defects priority

Software Defects Priority can be classified into four categories as i stated below:

Priority 1 – Resolve Immediately:

Example: User unable to launch ‘Funds Transfer’ page in a Banking application. When user clicks on ‘Funds Transfer’ button from Banking application home page the ‘Technical Problems’ or ‘Page Not Found’ displayed to the user.

In this example software tester should report the defect as Severity 1 or Showstopper because the system/application under test is out of service. In other words there is no work around or not usable to use the system/application unless the developer fix the defect for further usable.

In this case software tester should deem this as a top priority or Priority 1 defect to resolve immediately.

Priority 2 – High Attention:

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully but the ‘Complete Transfer’ button not clickable to initiate funds transfer.

In this example software tester should report the defect as Severity 2 or Critical because the major function of the system/application under test not working. In other words the intent of the application functionality is not usable and no workaround exists to use the application functionality unless the developer fix the defect for further usable.

In this case software tester should deem this as Priority 2 or High Attention defect to resolve the defect at the earliest.

Priority 3 – Medium:

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully and ‘Complete Transfer’ button is clickable to initiate funds transfer. But the application allows to transfer the money upto $1000 and not more than $1000. As a workaround user has to initiate funds transfer 2 times in order to transfer $2000 with each transfer of $1000.

In this example software tester should report the defect as Severity 3 or Medium because major function of the system/application under test not working but there is a temporary workaround exists to use the system.

In this case software tester should deem this as Priority 3 or Medium because this defect may be considered acceptable by the business to proceed to production and address as a post production issue.

Priority 4 – Low:

Example: Cosmetic issues in the ‘Funds Transfer’ page like spelling mistakes, page format issues.

In this example software tester should report the defect as Severity 4 or Minor because whenever components of the application are not functioning to specification but the situation is manageable i.e fix can be instituted in a future release.

In this case software tester should deem this as Priority 4 or Low because this defect may be considered acceptable by the business to proceed to production and address as a post production issue.

 

Software defects severity

Software Defects Severity can be classified into four categories as i stated below:

  • Severity 1 which is also called as Showstopper. Software tester should report the defect as Severity 1/Showstopper whenever the system/application under test is out of service. In other words, there is no work around or not usable to use the system/application unless the developer fix the defect for further usable.

Example: User unable to launch ‘Funds Transfer’ page in a Banking application. When user clicks on ‘Funds Transfer’ button from Banking application home page the ‘Technical Problems’ or ‘Page Not Found’ displayed to the user.

  • Severity 2 which is also called as Critical. Software tester should report the defect as Severity 2/Critical whenever major function of the system/application under test not working. In other words, the intent of the application functionality is not usable and no workaround exists to use the application functionality unless the developer fix the defect for further usable.

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully but the ‘Complete Transfer’ button not clickable to initiate funds transfer.

  • Severity 3 which is also called as Major. Software tester should report the defect as Severity 3/Major whenever major function of the system/application under test not working but there is a temporary workaround exists to use the system.

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully and ‘Complete Transfer’ button is clickable to initiate funds transfer. But the application allows to transfer the money up to $1000 and not more than $1000. As a workaround user has to initiate funds transfer 2 times in order to transfer $2000 with each transfer of $1000.

  • Severity 4 which is also called as Minor. Software tester should report the defect as Severity 4/Minor whenever components of the application are not functioning to specification but the situation is manageable i.e fix can be instituted in a future release.

Example: Cosmetic issues in the ‘Funds Transfer’ page like spelling mistakes, page format issues.

 

Software Defect Life Cycle

In a Software Defect Life Cycle, software defects will undergo following states:

  1. New: This is the default state when Defect is created.
  2. Rejected: Defect has been evaluated and deemed not valid because of a triage session.
  3. Open: Defect has been reviewed and is waiting to be assigned
  4. Need More Info: The assignee (usually Development Lead or Developer), who has determined that more information is needed, returns the defect to the issuer.
  5. Assigned: Defect has been assigned to a team member for resolution by test lead.
  6. Analysis: Defect is being analyzed.
  7. Repair: Defect is being fixed.
  8. Fixed: Defect has been resolved by the assignee and is waiting to be included in a build for re-test.
  9. Deferred: Defect has been deemed not immediately required for production and will be reviewed for a future release of the project.
  10. Pending Management Decision: Defect has been analyzed and deemed to require decision from management before any action can be taken.  Response from management is required before moving forward with Defect.
  11. Ready for Re-Test: The configuration management team has received this fix in a build request and the Defect has been applied to the test environment and is ready to be re-tested.
  12. Monitor: Defect has been identified as possibly incidental in nature.  Defect issue will be monitored for a set period to determine if it occurs again for moving forward with any resolution.
  13. Re-Open: Defect did not pass a test case after being fixed.
  14. Closed: Defect has been resolved and validated; it is no longer a problem.

What is meant by Software Defects?

The prime objective of a code developer is to write the code for creating a software while software tester prime objective is to find defects or bugs in the developed software. Now let’s see what is meant by software defects or software bugs.

Software defect or bug: The software functionality which is not in accordance with requirement specification documentation is called software defect or bug.

Type of defects: Defects are categorized based on the root cause on how they occur. The different types of defects are

  • Coding defects: The requirements have been coded incorrectly due to which behavior of an implemented software function is not in accordance with the requirement specification documents.

The other frequently occurred defects made by developers are due to

  1. Missed to code for the requirements which listed in requirement specification document
  2. Coding the requirements which are not specified in the requirement specification document

These types of defects are usually caused by developer’s oversight.

Example:

Requirement as per specification document: If user clicks on ‘Home’ link in a website then ‘Home’ page should be presented to the user.

Tester observation while testing the ‘Home’ link:  Tester found that ‘About Me’ page is displayed each time the ‘Home’ link is clicked which is a deviation in the behavior from the requirement specification document. This is an example of coding defect.

  • ‘Missing requirement’ defects:  A valid requirement which is mandatory and supposed to code (or implement) is missed. The root cause of this defect is due to not capturing this requirement in the specification document. These types of observations are categorized as ‘Missed requirements defects’ since the requirements are missed from requirement specification document.

These types of defects are usually caused by business analyst’s oversight.

Example:

Tester observation while testing the Website:  Tester found that ‘Disclaimer’ link is missing in the website. According to organization/webmaster guidelines it is mandatory to show ‘Disclaimer’ link in the website so tester expressed his/her concern that the ‘Disclaimer’ link is missing and to fix this developer expects the business analyst to document in requirement specification document.

  • ‘New requirement’ defects:  A requirement which is not in project scope to code (or implement) but later on it was determined that is mandatory to code (or implement) to address potential failures in the production (or after implementation).

These types of defects are usually caused by poor requirement analysis for scoping in assessing potential failures.

Example:

Requirement as per specification document:  System A transmits data to system B for data processing in system B.

System A: Transmits student records (records contain marks of each student) to system B

System B: Responsible for

  • Filter student records who gained more than 80 % passed marks in the examination
  • Process filtered student records to pass this information to the scholarship department

Tester observation while conducting system integration testing:  Tester found that data is not getting loaded in system B and on further investigation it is found that the root cause is memory constraints i.e system B fails to load data whenever system A transmits of more than 100000 student records.

To address this defect the project stakeholders decided to create additional (or new) requirement. So, the additional (or new) requirements are created as below in specification document.

System A: Transmits student records (record contains marks of each student) to system C

System C: This system is optimized to process (or handle) large volume of data i.e in this case system filter student records who gained more than 80 % passed marks in the examination and send to system B for further processing.

System B: Process filtered student records to pass this information to the scholarship department