Free quality center Tutorial ebooks download - quality center Tutorial in free PDF format ebooks for Beginners ready to download with high speed - www.ebookzdownload.com

1. Quality Center Roles and Defect Workflow
BU Admin
PERMISSIONS:
• Can modify all QC Components at the project level except Administration items reserved to the
QC Admin (specifics still TBD)
• Administer security at the QC project level
• Create QC projects and modify fields determined to be customizable at the BU Admin level
• Can delete a defect
PFG BPT
PERMISSIONS:
• Can create and modify components in Business Process Testing
RESTRICTIONS:
• View only access to other modules, can be combined with another role for additional access

2. PFG Business Analyst
PERMISSIONS:
• Can add, modify and delete requirements
RESTRICTIONS:
• Can’t add or remove tests from coverage
• View only access to other modules, may be combined with another security role (such as PFG
Tester)

3. Developer Roles (3 Levels)
PFG Developer Lead
PERMISSIONS:
• Can add, modify and delete tests in Test Plan module
• Can add, move, modify and delete folders in Test Plan module
• Can add, modify and delete test sets
• Can add and modify defects
RESTRICTIONS:
• View only access to Requirements and Business Components modules
• Defect Workflow - Cannot change defect status to CLOSED, except when Test Type selected for
the defect is UNIT
• Cannot delete a defect

4. PFG Developer
PERMISSIONS:
• Can add, modify and delete tests in Test Plan module
• Can run tests and modify run in Test Lab module
• Can add and modify defects
RESTRICTIONS:
• View only access to Requirements and Business Components modules
• Cannot add, move, modify or delete folders in Test Plan module
• Defect Workflow - Cannot change defect status to CLOSED, except when Test Type selected for
the defect is UNIT
• Cannot delete a defect

5. PFG Developer Limited
PERMISSIONS:
• Can run tests and modify run in Test Lab module
• Can add and modify defects
RESTRICTIONS:
• View only access to Requirements, Business Components and Test Plan modules
• Defect Workflow - Cannot change defect status to CLOSED, except when Test Type selected for
the defect is UNIT
• Cannot delete a defect

6. Tester Roles (3 Levels)
PFG Test Lead
PERMISSIONS:
• Can add, modify and delete requirements and add/remove them from test coverage
• Can add, modify and delete tests in Test Plan module
• Can add, move, modify and delete folders in Test Plan module
• Can add, modify and delete test sets
• Can add and modify defects
RESTRICTIONS:
• View only access to Business Components module
• Cannot delete a defect

7. PFG Tester
PERMISSIONS:
• Can add, modify and delete tests in Test Plan module
• Can add, move, modify and delete folders in Test Plan module
• Can run tests and modify run in Test Lab module
• Can add and modify defects
RESTRICTIONS:
• View only access to Requirements and Business Components modules
• Cannot delete a defect

8. PFG Tester Limited
PERMISSIONS:
• Can run tests and modify run in Test Lab module
• Can add and modify defects
• Defect Workflow – is allowed to change defect status from READY FOR RETEST to ASSIGNED
in the event a test of a fixed defect fails
RESTRICTIONS:
• View only access to Requirements, Business Components and Test Plan modules
• Defect Workflow - Cannot change defect status from NEW to ASSIGNED
• Defect Workflow - Cannot change defect status to CLOSED
• Cannot delete a defect

9. Defect Form status workflow
• When a defect transitions from NEW to ASSIGNED status the ‘Assigned to’ field is required
• When CLOSE status is selected the ‘Root Cause’ field is required.
Questions for BU Reps on Defect Form
1. Is date field required on defect form for the date a defect is closed or will defect history
be sufficient for tracking date closed? A field for this purpose would allow for filtering
by Closed Date but History does provide date/time stamps for when the defect is closed.
2. Are date fields required for tracking duration defects remain in ‘IN PROGRESS’ status
or will defect history be sufficient for tracking time it takes developer to fix defects once
they are accepted (as indicated by changing status to IN PROGRES)? We noted some
areas are currently tracking time required to fix by using date fields within their defect
form.
3. Do we need to add a field to the defect form titled Build/Version# or will the ‘Detected
In’ field provide enough flexibility in conjunction with the folder structure to track defect
detection by build and test cycle?
4. Do we want the ‘Detected By:’ field to be read only reflecting the ID of the person that
opened the defect or will we allow this field to be modified? Consideration is that a
defect may be opened by one test team member on behalf of another. History does track
ID when this field is changed.

10. Defect Form status workflow
• When a defect transitions from NEW to ASSIGNED status the ‘Assigned to’ field is required
• When CLOSE status is selected the ‘Root Cause’ field is required.
Questions for BU Reps on Defect Form
1. Is date field required on defect form for the date a defect is closed or will defect history
be sufficient for tracking date closed? A field for this purpose would allow for filtering
by Closed Date but History does provide date/time stamps for when the defect is closed.
2. Are date fields required for tracking duration defects remain in ‘IN PROGRESS’ status
or will defect history be sufficient for tracking time it takes developer to fix defects once
they are accepted (as indicated by changing status to IN PROGRES)? We noted some
areas are currently tracking time required to fix by using date fields within their defect
form.
3. Do we need to add a field to the defect form titled Build/Version# or will the ‘Detected
In’ field provide enough flexibility in conjunction with the folder structure to track defect
detection by build and test cycle?
4. Do we want the ‘Detected By:’ field to be read only reflecting the ID of the person that
opened the defect or will we allow this field to be modified? Consideration is that a
defect may be opened by one test team member on behalf of another. History does track
ID when this field is changed.