The different phases of a Bug Life Cycle and Cost of fixing bugs

Bug Life Cycle starts with an unintentional software bug/behavior and ends when the assigned developer fixes the bug.

A bug when found should be communicated and assigned to a developer that can fix it. Once fixed, the problem area should be retested. Also, confirmation should be made to verify if the fix did not create problems elsewhere. In most of the cases, the life cycle gets very complicated and difficult to track making it imperative to have a bug/defect tracking system in place.
Following are the different phases of a Bug Life Cycle:

-     Open: A bug is in Open state when a tester identifies a problem area
-     Accepted: The bug is then assigned to a developer for a fix. The developer then accepts if valid. Not Accepted/Won’t fix: If the developer considers the bug as low level or does not accept it as a bug, thus pushing it into Not Accepted/Won’t fix the state. Such bugs will be assigned to the project manager who will decide if the bug needs a fix. If it needs, then assigns it back to the developer, and if it doesn’t, then assigns it back to the tester who will have to close the bug.
-    Pending: A bug accepted by the developer may not be fixed immediately. In such cases, it can be put under the Pending state.
-    Fixed: Programmer will fix the bug and resolves it as Fixed.
-    Close: The fixed bug will be assigned to the tester who will put it in the Close state.
-    Re-Open: Fixed bugs can be re-opened by the testers in case the fix produces problems elsewhere.

Cost of fixing bugs 
       Costs are logarithmic; they increase in size tenfold as the time increases. A bug found and fixed during the early stages – requirements or product spec stage can be fixed by a brief interaction with the concerned and might cost next to nothing.
       During coding, a swiftly spotted mistake may take only very less effort to fix. During integration testing, it costs the paperwork of a bug report and a formally documented fix, as well as the delay and expense of a re-test.
       During system testing, it costs even more time and may delay delivery. Finally, during operations, it may cause anything from a nuisance to a system failure, possibly with catastrophic consequences in a safety-critical system such as an aircraft or an emergency service.

When can testing be stopped/reduced?
 It is difficult to determine when exactly to stop testing. Here are a few common factors that help you decide when you can stop or reduce testing: 

•     Deadlines (release deadlines, testing deadlines, etc.) 

•     Test cases completed with certain percentage passed

•     Test budget depleted 

•     Coverage of code/functionality/requirements reaches a specified point 

•     Bug rate falls below a certain level 

•     Beta or alpha testing period ends