Software Performance Testing and it’s Bug Life Cycle


24 Jan 2018

Software Performance Testing and it’s Bug Life Cycle

software performance testing
Name of the bug status may vary depends upon the tools (QC, JIRA etc) used and the process followed in the organization.

Bug can be defined as the odd behavior of the software. Bug starts when a defect is found and ends when a defect is closed, after confirming it is not reproduced.

  1. New: – when a tester finds a new defect status of the defect posted by the tester is New. The tester should provide a proper defect document to the development team to reproduce and fix the defect
  1. Assign:– Defect which are in the status of “New” will be approved if valid and assigned to the development team by test lead or project lead or project manager; the status of bugs changes to assigned If the development team accepts the bug then the bug status changes and that status is “Open”
  1. Open: – If the Bug status is open then it means the development team starts analyzing and works to fix the defects.
  1. Fixed :- When a developer makes necessary coding & verifies the change then the status is changed as “fixed “ and that bug is passed to the testing team ; here the development team change bug status as test.
  1. Test: – If this state the defect is fixed and ready to do test whether it is fixed or not?
  1. Verified: – The tester retest the bug after it get fixed by the developer. If there is no bug detected in software then the bug is fixed and the status assigned is verified.
  1. Closed: – After verified the fixed, if the bug is no longer exist then the status of bug will be assigned as closed. Sometimes while doing retest we may encounter the same issue which means bug was not fixed properly. Now tester change the status as “Reopen “
  1. Reopened:- If the defect remains same after the retest then the tester post the defect using defect retesting document and changes the status to reopen again bug goes to the life cycle to be fixed.
  1. Duplicate: – If a defect is repeated twice. This concept of the bug the status is considered to “Duplicate” by the development team.
  1. Deferred: – In some cases, project manager or lead may set the bug status as “Deferred” and it will be fixed in the next release.
  • If the bug found during end of release and it is minor or not important to fix immediately
  • If the bug is not related to current build.
  • If it is expected to get fixed in the next release.
  • The customer is thinking to change the requirement.
  1. Rejected:-  If the system is working according to condition and bug is just due to some confusion such as referring old requirement or extra features  them  so  such bug is considered “Rejected”

Some other states of bugs are

  • Cannot be fixed
  • Technology not supporting
  • Root of the product issue
  • Cost of fixing bug is more
  • Not reproducible
  • Platform mismatch
  • Improper defect document
  • Data mismatch
  • Build mismatch
  • Inconsistent Defects
  1.  Need More Information

If developer is unable to reproduce the bug as per the step s provided by tester   then the developer can change the status as “Need More Information”


Welcome To Your Dreams


Click the link below for  all your software testing queries 


Introducing the Most Practical, Complete and Inexpensive Software Testing Training Course: Software Testing (Basics + Advanced) + Automation Basics







Comments are closed.