BUG and work item rules

 

Team, when creating bug work items please refer to these guidelines. Will do another for user stories/developer tasks.  Please let me know if any questions. 

The Description tab:

The description tab should include the following:

• A to-the-point description of the bug the user is encountering.  
  • This description should not include language about what the solution would or should be.  Save that for your comments in the dev notes.  
  • Your target audience of this description includes people with a variety of technical background and different frames of reference.  
  • Make a judgement call on your use of acronyms and developer jargon, please keep things intelligible to the general audience of QA, BAs, other devs, CM, management.  
  • Use complete sentences.
    
    
• A list of steps to reproduce the bug.  If these repro steps are complex, you can save the details for the test case, but it's still helpful to see a general idea of how to get the bug to occur in this section.
  
  
• The expected outcome of performing the repro steps (IE how SHOULD the system behave?)
  
  
• The actual outcome of performing the repro steps (IE the error message or incorrect system behavior)

The Dev Notes Tab:

Each time you set a bug to resolved you should be adding your dev notes with the following:

• Your name and the date you resolved the WI.  
  • In case of multiple comments in dev notes due to a WI being returned, keep your most recent resolutions on top - above the older ones.
    
    
• A description of what you had to change to fix the bug
  
  
• An acknowledgement that you successfully ran through the attached test case on the dev environment (not just your local box). 
  • This step is mostly a reminder to yourself to do the critical step of testing your own changes in our dev environment both inside and outside Citrix.  
  • It will help us catch any configuration issues on the dev server and prevent easily catchable issues that should never even make it to QA.

The Tester Notes Tab:

This tab is used by the QA team to mark their notes on passing a test or describe why a WI is being returned. Dev should not write anything here.

An Attached test case:

All bugs must have an attached test case that amply walks the user through reproducing the bug (should be similar to the steps in the description tab, including more detail when necessary)

Screens affected:

As a developer, it is part of your job to know which screens you are affecting either directly or indirectly with your changes.  It is especially important to make use of this tab to give the QA a heads up on changes that will affect multiple parts of the system, including any reports.  It helps do targeted testing on those parts of the system early, instead of waiting to find an issue lurking during the full regression test, which is done closer to the release date.