Bug's settings

<accesscontrol>Main:MyGroup</accesscontrol>

Settings for Bug template:

Properties:

_Property: Reporter [Resource - Required]

• Objectives:

     This parameter stores information about the bug reporters so that we can:
       + Contact to them to get more information of the bug report, to ask them for approval after the bug was fixed.
       + Add them to the task's Observer list so that they can get informer messages about the status of the bug they have reported.

• Value:

     Select the person who sent the bug report.

_Property: Priority [Single - Required]

• Objectives:

     This parameter is used to prioritize bugs so that we can know which one is more important to be fixed than others.

• Values:

     Critical: choose this option if:
               + Important work process cannot be completed or Cattask crasking.

     High: choose this option if:
               + A work process cannot be completed.   
               + A bug that makes Cattask fail.    
               + Return wrong results.    
               + Cause invalid data in the database.    
               + Performance issue on important modules. 
               + The client want it fixed immediately.

     Medium: choose this option if:
               + A work process doesn't work, but a work-around works.    
               + Validation incorrectly limits something that should be allowed.    
               + A work process doesn't work in FireFox, but works in other browswers.    
               + Text resources wrong/misleading.    
               + That LnF guideline are not followed prevents users from finishing a work process properly.    
               + Perfomance/speed issue.

     Nice to have: choose this option if: 
               + Validation error that doesn't limit normal work processes.    
               + That LnF are not followed doesn't prevent users from finishing a work process properly.
               + Text resource doesn't look nice but not misleading.

_Property: RootCause_Project [Single - Required]

• Objectives:

    This parameter is used to keep information about why the bug occurs. 

    Investigating this parameter's information, we can know how stable we are regarding to the Project Management process. 

• Values:

     From making projects: choose this option if the bug is caused from making a new projects.

     From fixing other bugs: choose this option if the bug is caused from fixing other bugs.

     New discoveries (Bugs comming out of nowhere): choose this option if the bug is on the system from very early versions.

     From changes in FD: choose this option if the bug is caused from changes in FD.

     From changes in LnF guideline: choose this option if the bug is caused from changes in LnF guideline.

     From missing features when making new projects: choose this option if the bug is caused from missing features when making new projects.

     Unknown: choose this option if you cannot choose one of the above options.

_Property: TaskStatus [Single - Required]

• Objectives:

     This property is used to keep Task's status infomation. It allows us to create the task before the problem is considered as a bug. In the other words, with this property, we can speed up the interaction with clients by creating the task and reply to them right after receiving bug reports.

• Values:

     Reproducing: choose this option if the task is created for the bug report but it is not accepted as a bug yet. Tester/Dev is trying to reproducing the reported problem.     

     Needs more information: choose this option if the problem cannot be reproduced with the reported information. It requires more information from reporter.     

     Assigned: choose this option if the reported problem can be reproduced and assiged to responsible Dev/Group.

_Property: FoundIn_Project [Resource - Not required]

• Objectives:

     The property simply tell us which project the bug comes from; therefore, presents the project's quality.

• Values

     Choose the project that the bug comes from.

_Property: FoundIn_Stage [Single - Required]

• Objectves:

     The property store information about in which stage of the Project Development Life Circle the bug comes from. Since "the cost of fixing faults increases as you move the product towards live use", this property allows us to have an overview of our "cost of fixing bug" and then improving the Testing process.

• Values

     Testing: choose this option if the bug is found in testing phase before giving it to QA for approving the testing task.     

     Approving: choose this option if the bug is found after the testing task was sent to QA for approval at the first time.     

     Before Deploy: choose this option if the bug is found after IAT but before client ever had the chance to find it.     

     Pre-Released: choose this option if the bug is found after the project was released to client (PRE PROD).     

     Released: choose this option if the bug is found after the project was released to client (used in production site).

• Notes

     The first three options depend on project status while the last two depend on version status. For example: If the bug is found only in developing version, its stage will never be "Released" no matter which project it belongs to.

_Property: FoundBy_User [Single - Required]

• Objectives:

     Similiarly to Approver parameter, this property stores information about the bug reporter. The main idea of having this property is that we can know if the bug is found by the members of development team or other teams. It would be great if all bugs are found by development team in testing stage.

• Values    

     Development Team: choose this option if the bug is found by the Team itself, including QA and BA if in the Approval phase.

     Other Team: choose this option if the bug is found by some other team.

     Production: choose this option if the bug is found while doing production work (Catinet and Process).

     Client/User: choose this option if the bug is found by end clients/users/partners.

_Property: Version [Multi – Required)]

• Objectives:

     The property stores information about how many and which versions the bug occurs so that the Devs and Tester can know in which versions the bugs should be fixed.

• Values:

     Select all the versions having the bug.

New Version setting (applied from Jan 25th, 2010)

• Objectives:

     In order to support the sub version setup, a new Version property should be created for each version.
     The property stores information about how many and which sub-versions the bug occurs so that the Devs and Tester can know in which sub-versions the bugs should be fixed.

• Values:

     Select all the sub-versions having the bug.

_Property: Version_unFixed [Multi – Required]

• Objectives:

     This property stores information about which versions the bug hasn't been fixed yet. Using it together with the Version property, we have all information about relationship between bugs and versions.

• Values:

     Select all the versions having the bug which has not been fixed yet.

New Version setting (applied from Jan 25th, 2010)

• Objectives:

     In order to support the sub version setup, a new Version property should be created for each version.
     This property stores information about which sub-versions the bug hasn't been fixed yet. Using it together with the Version property, we have all information about relationship between bugs and sub-versions.

• Values:

     Select all the sub-versions having the bug which has not been fixed yet.

 

 

_Property: Known issue [Multi - Not Required]

• Objectives:

    This property is used to categorize issues which will not be fixed in a release due to technical limitation or bad ROI. It should be specified by the TL together with RnD team. Detail reasons should be specified in the resource's journal.

• Values:

    Technical limitation: choose this option if the issue cannot be fixed by our current technique.

    3rd party library's bug: choose this option if the issue come from 3rd party's problems.

    Costly bug: choose this option if the issue can be fixed but it takes too much time, manpower in comparison to the benefit.