• Setting Bug Severity and Priority

  Guidelines for Setting the Severity and Priority of Bugs Found in Software Development Projects

   
    
   

  A simple process and guidelines for setting the Severity and Priority of bugs found in a software development project

  Contents

  • Bug Severity and Priority
  • Severity
  • Impact
  • Visibility
  • Class
  • What About Urgency?

• Bug Life Cycle

• Logging new defect

  When tester logs any new bug the mandatory fields are:
  Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce.In above list you can add some optional fields if you are using manual Bug submission template:
  These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots.
  The following fields remain either specified or blank:
  If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug to respective module owner.

   

  

   

   The figure is quite complicated but when you consider the significant steps in bug life cycle you will get quick idea of bug life.

  On successful logging the bug is reviewed by Development or Test manager. Test manager can set the bug status as Open, can Assign the bug to developer or bug may be deferred until next release.When bug gets assigned to developer and can start working on it. Developer can set bug status as won’t fix, Couldn’t reproduce, Need more information or ‘Fixed’.If the bug status set by developer is either ‘Need more info’ or Fixed then QA responds with specific action. If bug is fixed then QA verifies the bug and can set the bug status as verified closed or Reopen.

• Statuses associated with the Bug:

  New:
  When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the bug.
  
  

  Assigned:
  After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is assigned to it.
  
  Open:
  Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate that he/she is working on it to find a solution.
  
  Fixed:
  Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.
  
  Pending:
  After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending Retest’ is assigned to it.
  
  Retest:
  The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.
  
  Closed:
  After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it and marks it with ‘Closed’ status.
  
• Reopen:
  If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as ‘Reopen’.
  
  Pending Reject:
  If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.
  
  Rejected:
  If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.
  
  Postponed:
  Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of Test data, unavailability of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.
  
  Deferred: In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is marked with ‘Deferred’ status. 

2 more annotations...

• New, Bug Verified, Assigned, Fixed, Fix Verified, Closed, and ReOpened
• Assigned, Fixed, Closed, and ReOpened.
• New, By Design, Deferred, Duplicate,Enhancement, Irreproducible, Limitation, Fixed, User Error, Closed, Obsolete, Confirm by Design, Confirm deferred, Confirm Duplicate, Confirm enhancement, Confirm fix, Confirm Irreproducible, Confirm Limitation, Confirm Obsolete, Confirm User Error
• Open - Ticket has been submitted.
  Accepted - Ticket has been accepted into development.
  Deferred - Fix will be in a subsequent version/build or is under consideration.
  Rejected - Submitted ticket has been rejected.
  Resolved - Resolved, not yet confirmed by QT.
  Re-open - Resolved, rejected, or closed submission has been re-opened.
  Closed - The resolution (fix) has been confirmed.

• Behavioral Issue: a point or matter of discussion, debate, or dispute that stems from an alleged quality risk found during the software development or formal testing phases of the life cycle.

  A Behavioral Issue is either a defect or a change request. Now, if you have to start subsuming the business needs (more for the process or for more high level issue tracking) I introduce:

  Business Issue: a point or matter of discussion, debate, or dispute that stems from a localized or systemic business concern that may affect how a product is developed, shipped, tested, or supported.
• Open - New bug, bug in process
  Retest - Fixed and needs to be retested
  Closed - Bug gone
  Reopened - Bug back
  Pending - We know it's a bug, but it'll get fixed down the road.

• or these reasons, change AND defect requests can come from a number of sources, and there's a need to develop some sort of centralized process to ensure that those items do not get out of hand.

  ---

  Which will definitely require a filter at some point, whether that filter is Customer Care, QA, etc.
• - testers open ticket (New)
  - another tester verifies the issue (Bug Verified - allows Assignment)
  - project manager assigns ticket to developer - (Assigned)
  - developer fixes the issue (Fixed)
  - tester verifies the issue (Fix Verified - allows Closure)
  - a different person closes the ticket (Closed)
  - testers open a ticket (ReOpened)
• Development and Project Management can change a status to "Fixed". The developer in case of changes to the code, and Project manager in the case of updates to documentation/expectations.
• Verification of fixed versus closing the ticket is used because "Fix Verified" indicates that the defect has been re-tested in QA/UAT environment, and "Closed" indicates it's been verified in Production environments - this goes to a separate thread recently regarding verifying fixes in prod environments.
• 1- Open
  2- Assign Or 'Not a Bug'
  3- Testing
  4- Fixed (the QA will change it to Fixed after verify the fix otherwise go to step 5)
  5- Reopen
  6- Closed (after the software is released or shipped)
• 2 kinds of "Pending"
• There's 'Pending' which are low priority issues...the kind that may or may not get addressed. Then there's the 'Waiting on Customer' pending. These are usually issues that end up being new features and are associated with a customer mod request. So those aren't actively being worked on, but are not so much back-burner as a 'Pending' issue.
• Do you see a difference in the handling of tickets by leaving them as open, but assigning them to a different project, as oppossed to having another status for "Deferred" or "Pending"?
• A change request was generally submitted to a Product Manager. It took the status of "Open." (By this logic, the ticket is determined to be a change request; it is not yet incorporated into a project. As long as the ticket is in this state, it needs to be regularly reviewed and prioritized by Product Management or equivalent in title.)
• If, upon review, the change request is recognized as valid (meaning it positively affects the bottom line, answers to customer(s) demand, etc.) status of the ticket will be changed to "Accepted." The ticket, at this point, will remain assigned to the Product Manager that it was initially submitted to. (In this case "Accepted" means that the change request is accepted by a project team for analysis and design work. It does not mean it will be implemented necessarily. The Product Manager updates the status of the issue to "Accepted" and notes, in the detail, which project accepted it.)

• Understand that accepted means that the change request, as it has been stated in the ticket, is now going through the process of being fleshed out in requirements statements and described in a design specification. When the requirements and design work has been completed and a timetable for when the functionality should be included (meaning a specific release) is established, the ticket is assigned to the Application Development Manager (or equivalent title) - still with a status of "Accepted."

  When the Application Development Manager (or whomever the ticket has been assigned to) has incorporated the functionality into a build of the stated release, the status of the ticket is changed to "Resolved" and assigned to QA/QT. (Notice here that this is not resolved in the context of a defect; resolved just meaning that the change request has been implemented.
• o, to sum that up the change request, now incorporated into detailed requirements in a project, has transitioned to/been implemented in a build. It is important to realize that the change request, during the requirements/design phase, might have been determined to be too difficult to implement or not worth the implementation. In that case it could be "Rejected" or perhaps "Deferred."

16 more annotations...