QCStandardProcesses Latest

Quality Center – Standard Processes and Templates
Quality Center
Standard Processes and Templates
-1-
CONTENTS
1 INTRODUCTION.........................................................................................................7
1.1 Purpose................................................................................................................................................................7
1.2 Objectives............................................................................................................................................................7
1.3 Scope....................................................................................................................................................................7
1.4 Approach.............................................................................................................................................................7
1.5 Quality Center Workflows...............................................................................................................................8
1.6 Quality Center Relationships.........................................................................................................................9
1.7 Acronyms and abbreviations.......................................................................................................................10
2 SYSTEM CONFIGURATION....................................................................................11
2.1 Version Control................................................................................................................................................11
2.2 Naming Conventions......................................................................................................................................11
2.3 User Registration............................................................................................................................................11
2.4 Quality Center Naming Conventions.........................................................................................................11
2.5 Terminology......................................................................................................................................................11
2.6 Quality Center Repository Registration....................................................................................................13
2.7 Access Levels..................................................................................................................................................14
3 RELEASES FUNCTION...........................................................................................16
3.1 Releases – Workflow Process.....................................................................................................................16
3.2 Roles and Responsibilities...........................................................................................................................16
3.3 Setting up a Release Folder.........................................................................................................................17
3.4 Release Details Screen..................................................................................................................................18
3.5 Cycles Details Screen....................................................................................................................................20
3.6 Major ‘Releases’ to Live................................................................................................................................21
4 REQUIREMENTS.....................................................................................................22
4.1 Requirements Workflow Process...............................................................................................................22
4.3 Requirement Types.........................................................................................................................................22
4.4 Importing Requirements................................................................................................................................23
4.5 Requirements Folders & Grouping............................................................................................................23
-2-
4.6 Creating Requirements Folders & Grouping...........................................................................................23
4.7 Requirements Details Screen (Manual).....................................................................................................24
4.8 Requirements Grid..........................................................................................................................................26
4.9 Requirements Traceability – Relationships.............................................................................................26
4.10 Test Coverage..................................................................................................................................................27
4.11 Risk Based Testing – Overview...................................................................................................................28
4.12 Risk Based Testing – Business Criticality...............................................................................................28
4.13 Risk Based Testing – Failure Probability..................................................................................................29
4.14 Risk Based Testing – Analyse results.......................................................................................................30
4.15 Requirements Details – Linked Defects....................................................................................................31
4.16 Requirements Review Process...................................................................................................................31
5 TEST PLAN..............................................................................................................33
5.1 Test Plan Workflow Process........................................................................................................................33
5.3 Test Cycles & Roles........................................................................................................................................34
5.4 Test Plan – Create Test Folders..................................................................................................................34
5.5 Test Plan – Test Details Screen...................................................................................................................35
5.6 Test Plan – Test Grid......................................................................................................................................36
5.7 Test Plan - Test Case Design.......................................................................................................................36
5.8 Test Plan – Test Case Requirements Coverage.....................................................................................36
5.9 Test Plan – Test Case Linked Defects.......................................................................................................37
6 TEST LAB.................................................................................................................38
6.1 Roles & Responsibilities...............................................................................................................................38
6.2 Test Set Details................................................................................................................................................38
6.3 Test Set Execution Grid.................................................................................................................................39
6.4 Test Run – Execution Flow...........................................................................................................................39
6.5 Test Run – Manual Runner...........................................................................................................................40
6.6 Test Run – Manual Runner- Run Sets........................................................................................................41
6.7 Submit a Defect from a manual run............................................................................................................41
6.8 Test Set - Linked Defects..............................................................................................................................43
7 DEFECTS..................................................................................................................44
-3-
7.1 Defects Workflow Process............................................................................................................................44
7.3 Add New Defect...............................................................................................................................................44
7.4 Defect Details Screen.....................................................................................................................................45
7.5 Defect Grid........................................................................................................................................................48
7.6 Business Impact..............................................................................................................................................48
7.7 Defect Status & Flow......................................................................................................................................49
7.8 Defect Process Flow Diagram......................................................................................................................51
7.9 Defect Category...............................................................................................................................................52
7.10 Document Defect Type..................................................................................................................................53
7.11 Fix Priority.........................................................................................................................................................54
7.12 Linked Entities.................................................................................................................................................54
8 E-MAIL NOTIFICATIONS.........................................................................................55
8.1 Manual E-mail Notification............................................................................................................................55
8.2 Automated E-mail Notification.........................................................................................................................55
-4-
1 Introduction
1.1 Purpose
This document will help Global Testing Services define the use of the Quality Center throughout GRCB by
proposing standard processes and templates to end-users. Once these processes and templates are
agreed among the testing community, these will be rolled out to Quality Center and every change in the
processes and / or templates will be controlled by Governance.
1.2 Objectives
The objective of the Quality Center implementation and specifically this document is to gain agreement from
all stakeholders on the standard processes and templates to be implemented in Quality Center moving
forwards. In setting a global standard GTS are looking to increase the quality of the testing process and to
drive forward best practices. Currently, the main focus of testing and the use of Test Director within that
process are to capture and manage defects; however the implementation of Quality Center and common
standards will offer the opportunity to expand this focus more widely and drive full usage of the Quality
Center functionality.
1.3 Scope
Within Scope
The scope of the document is to explain and detail the functionality and field configurations that are to be
set up within the new implementation of Quality Center. Within scope of this document are the areas of
functionality that are used on a day to day basis;
 Releases (& Cycles)
 Requirements
 Test Plan
 Test Lab
 Defects
Additionally the document provides information on some functionality that is available within Quality Center
and as such will be configured during this implementation but isn’t currently used within the Barclays
framework; Risk based testing and business component testing being two of these.
Out of Scope
Set up and configuration of users, infrastructures, databases, domains and projects is outside the scope of
this document and as such is detailed within the Quality Centre user & system administration process
Quality Center reporting and metrics are defined and documented within the QC Delivery Dashboard
document.
1.4 Approach
The approach taken in creating this document has been to present the reader with an understanding and
feel for Quality Center together with additional supporting information relevant to the application and usage.
To meet this purpose, the document presents a mixture of high level processes, screen shots together with
some more detailed data and field definitions to support the final technical deployment. It should be noted
that this document is focused on an end to end development cycle and does not in this version cover Fast
track projects, Agile or Lean developments.
-5-
1.5 Quality Center Workflows
The following diagrams have been designed to help demonstrate the standard workflows within Quality
Center:
Setting up and using Quality Center

Project User
Project Stage
Setup Project
Domain / Setup Programme Setup Project
Repository
Project Site Administrator
Define Access
Setup Cycle Setup Project
Setup Release levels for users /
(Test Phase) Users
functionality
Setting up and using Quality Center - Continued
Requirements Test Plan
Where applicable,
Enter Enter Test Scripts Ensure Test
link requirements Define Business Define Failure Analyse impact of
Requirements & & link to Coverage is
together Criticality Probability Risk Category
link to Release Requirements complete
(Traceability)
Releases
Release
Project User
Defect
Test Lab
Create test sets to Execute Test Analyse Tests - Manage

Fail
be run Scripts Pass or Fail Defects
Pass
Delivery
Dashboard
Administrator
Project Site
Produce reports on
testing conducted End
and success
1.6 Quality Center Relationships
-6-
R E L E AS E R E Q UIR E ME NT T E S T P L AN TE S T L AB
D omain R equirement
R equirement T est T est S et

P rog ramme P roject
F older F older F older
R equirement T est T est S et

R eleas e
F older F older F older
T est R equirement T est T est

C yc le/phase C ondition C ase S et
T est
R un
DE F E C TS
D efect
Relationship created by User

Relationship managed by QC
Mid Level Relationships
Release
Release to
Programme
Live
Contains
Releases from one or more
Projects or programmes
Quality Center
n
1
Relationships
Is Delivered in Is coded by Development
Project Party
1 n
Fixes
Version Changes 1 Codes Dev
n Application
Release Build Cycle
Runs Against
Is Tested
in Test Lab
1 n 1 n Test
Is Tested by
Party Executed
Change Release 1 Test in a Test Set
Requirement Test Phase n Set Run
Identifies
Requirement
0 n
Contains
0
Is Tested by Test Identifies
Defect
Case 1
Release
Requirement
Test Plan Defects
Test Plan
Test Lab
Defects
1.7 Acronyms and abbreviations
-7-
AG Auto Generated Field

BOD Business Operational Design
BOM Business Operational Management
C Conditional
CB Check Box
CIT Component Integration Test
DB Database
DD Drop Down List
E2E End to End
GAD Global Application Design
GRCB Global
GTS Global Testing Services
H History Available
HP Hewlett Packard
LDAP Lightweight Directory Access Protocol
MoSCoW Classification of test priorities based on Must test, Should test, Could test and Would
test
OAT Operational Acceptance Testing
QC Quality Center
RBT Risk Based Testing
RBQM Risk Based Quality Management
UAT User Acceptance Testing
SIT System Integration Testing
ST Text String
STO System Technology Office
-8-
2 System Configuration
1.8 Version Control
It will be possible in the future to configure Quality Center to use version control. This is done by selecting
one of the available version control add-ins and installing it. After you integrate Requisite Pro with Quality
Center, you will then be able to create a version control enabled project in Quality Center. You can then
update and revise your tests, while maintaining previous versions of each test. This allows you to keep
track of the changes made to each test in your Quality Center project, to see how and when a test was
modified, or to return to a previous version of the test
1.9 Naming Conventions

The following naming conventions and criteria will be applied to the system and must be adhered to moving
forwards.
1.10 User Registration

A users QC log on will conform to their PC and network logon.
E.g. For BDS+ which is formatted: y00021089, y00022026, etc. Other standards may vary.
It is intended that LDAP will be introduced and used in the near future with this application and therefore will
be supported by this approach.
 Where LDAP is available then the password will default to the users network password
 Where LDAP is not available then the system administrator will advise the user of their password
Note: It is intended that LDAP will be introduced and used in the near future with this application.
1.11 Quality Center Naming Conventions

Throughout this document you will see the naming conventions detailed in the following table used. It is
acknowledged that the use of some of these fields may not be consistent with the understanding and
common usage of that name by users of the system. Therefore we have provided a definition for each
name in the context that must be presently used in QC. It is the intention that these be reviewed and
agreement reached on the final usage.
1.12 Terminology
Generic Project Explanation Implemented in
Testing Term Quality Center as
STO Business A project or programme is always owned by just one STO A Domain
Domain (Business Unit) even if it is a cross business strategic or
regulatory project.
Programme A group of related projects. Set up new project
Project Process of delivering an agreed set of function between A folder within a
an agreed start and end date. May be part of a Programme
Programme or “stand alone”.
Release A project may be broken into one or more groups, Set up at the QC
“Releases”, of new or changed functionality to pass Release level
through each Test Phase before it is ready to go to Live.
Workpackage A workpackage is the end to end delivery of a predefined The totality of the
set of changes that are delivered as part of a QC Release level
‘Release’ This contains requirements, test plans, testing contents, testing
and defects from inception to delivery to ‘live’. and defects
Build Cycle In the development process a number of build cycles may A code “Version
take place before a testable set of working code can be Number” field.
released into a Test Phase. Each build must be discreet
and identifiable by a Version Number in order to associate
tests and defects with a specific build of code. Not every
Build Cycle may be released into Test.
The Build Cycle from a Test Cycle that passes the cycle
exit criteria is the first Build Cycle into the following test
-9-
Cycle.
Module A project defined break down of function required to be Drop down box in
delivered. It provides an additional level of granularity for Requirements
monitoring progress and reporting. section.
Release to Test A Build cycle that is released to Test. Tests will be
recorded against
There may be multiple development builds of the same defined Test Cycles
function dropped into each test phase depending on
complexity of defects and fix process.
Test Cycle e.g. Unit Test, Assembly Test, CIT, SIT, UAT, OAT, Implemented as
Performance, Security test, Live Confidence Test folders within the
Each Cycle Contains: QC “Cycles” folder
 Specific Requirements with the title
 Test Conditions to Test those Requirements changed to include
 Test Cases for the Test Conditions the Test Cycle
 Test Sets to group Test Cases for execution (may name.
be multiple times)
Defects are logged against Test Cases.
Release to Live The promotion to the Live environment of work packages QC Project data
fields to record
Releases may be “Interim”, probably of a single project target release type
being promoted to Live independently of a Major Release. and date.
Releases may be “Major” – containing a number of

workpackages from different Programmes or Projects –
e.g. A Quarterly Release.
In this instance they may combine workpackages from

across a number of business areas / STOs – but are
“owned” by a single STO.
Test Case A description of inputs, execution instructions, and Defined as a Test

expected results, which are created for the purpose of Case within the Test
determining whether a specific software features work plan function
correctly or a specific requirement has been satisfied
Test Script The step-by-step instructions that realise a test, enabling Defined within the
its execution. Test scripts may take the form of either Test plan function
documented textual instructions that are executed
manually or computer readable instructions for automated
test execution.
- 10 -
STO 1 STO 2
Programme 1
Project 3 Project 4
Project 1 Project 2 Mortgages Payments
Release Z Release N
System 1 System 2 System 3 System 4
Tested Project / Programme /

System Changes
Q1 RELEASE
Live Environment
Example structure
1.13 Quality Center Repository Registration
The naming conventions and hierarchy are as follows:
For the repository: <Domain>_<Programme>_db
Domain = STO Name, 6 characters maximum.

All existing STO’s will have a Domain set up using their name in accordance with the field restrictions. New
Domains may be set up by the system administrator upon receipt of a formal request.
Programme = Agreed Programme Name, 15 characters maximum
Programmes will be set up by the system administrator at the request of the respective STO and assigned
to the relevant domain.
For Example: UKRB_GPU_db
The structure then follows the standard pattern shown below where a programme is linked to a domain, a
programme may consist of many projects, projects may contain many releases, releases may contain a
number of testing phases and test phases will contain a number of test cycles.
- 11 -
Domain
Programme Programme
Project Project Project Project
Release 1
Release 1
Req’s
Release 1 Release 1
Test Req’s
Req’s Test
Test Req’s
Test
Test Test
Release 2
Test Release 2
Req’s Test
Req’s
Release 2 Release 2
Test
Req’s Test
Test
Test
Test Test
Test
Release 3
Test
Req’s
Test
Test
Example Domain / Programme Structure
1.14 Access Levels
The following table describes the access levels set within Quality Center:
Level Description
0 View only – all modules
1 Full access to Defect module + view only to other modules
2 Access to all modules but Releases (view only to this module)
3 Full access to all modules, with partial deletion rights
4 Full access to all modules, including full deletion rights (System Admin only)
5 Same access as Level 2 + Business Process Testing module
6 Restricted access to Defects module only
A full access permissions mapping of Quality Center fields is detailed within Appendix A of this document.
Rationale
It is not uncommon for people with multiple roles to be awarded multiple access rights on a system as their
roles and projects change. The result of this is that users over time frequently acquire ‘accumulated
permissions’ and these are both problematical and difficult to manage.
- 12 -
Levels
Roles 0 1 2 3 4 5 6
Administrator Y Y Y Y Y Y Y
Project Mgr Y Y Y
Tester Y Y Y Y
Test Mgr Y Y Y Y Y Y Y
Developer Y Y Y Y
Development Y Y Y Y
Manager
Automation Y Y Y
testing specialist
In order to address this in Quality Center, the access levels that people will be allocated will depend upon
the current project and roles they are performing. A user will be given the lowest access level required that
allows them to perform all tasks needed for any multiple roles they have. They will not be allocated multiple
access right levels. – E.g. in the above example the Project Manager may previously have ‘accumulated
permissions’ but would now only be allocated a level 5 permission. A process for handling the management
of user roles and access is described within the Quality Center Support Processes document.
Project Access Security
Project Access Security is managed by giving a user access to
A Domain/Programme that may contain multiple programmes and projects each of equal
confidentiality.
OR
To a Domain/Project if access to a single project must be restricted.
Users can be given access to more than one Domain/Programme or Project structure.
Once within a domain/project then user rights are determined by the standard assigned Access Levels.
- 13 -
3 RELEASES Function
1.15 Releases – Workflow Process
The set up process is started by configuring a ‘release’ structure by using the ‘releases’ module. Within
Quality Center, a release represents a group of changes or defined functionality that is to be delivered by a
particular project or as part of an overall Work Package. Within each ‘release’ there may be a number of
test phases and within that a number of cycles of testing . For example specific cycles may contain tests for
new functions, existing functions and/or regression tests.
The following example structure below shows how each project may contain a ‘release’ and within that a
number phases of testing, for example: Unit Test, Assembly Test, CIT, SIT, UAT, OAT, Performance,
Security) and within those several cycles of specific testing may be required.
Programme / Special Project
Release Folder
Release
Project
Cycle
Release A Release B
Unit Unit
Assembly Assembly
CIT CIT
SIT SIT
UAT UAT
OAT OAT
Performance Performance
Security Security
Release to Release to
Live? Live?
1.16 Roles and Responsibilities

The release name will be defined within Quality Center by the Test Manager in association with the
programme management and development teams and will conform to the naming conventions detailed
within section 2.1 – Naming Conventions.
- 14 -
The project “Test Strategy” document will state how the project will be tested including which Test Phases
are required and how they are conducted. QC set up should conform to either the global standard or
whatever variation has been agreed and signed off in the Strategy document.
The Test Manager is responsible for identifying and agreeing the test phases required for each Release
and for ensuring that these are added to the applicable release The QC “Cycles” folders must be created to
include the appropriate Test Phase name.
.
Common Release Functions
Level Add Modify Delete Add Delete Add Modify Delete
Release Release Release Release Release Cycle Cycle Cycle
folder folder
0
1
2
3      
4        
5
6
1.17 Setting up a Release Folder

When setting up Quality Center for single or multiple projects within a programme it is necessary to create
an individual project folder for each. This is done by using the New Folder option within the ‘Releases’
functionality. By creating this structure each project can then have multiple Release versions and test
Cycles assigned to it.
RELEASES
- 15 -
Add Release Folder

Field Label Type Description Values D H
Release Folder ST The name of the Project Folder 0-255 characters. Name should M N
Name be the project name
Project Name DD The name of the Project to be 0-255 characters. Name should M N
created be the project name
STO DD The name of the business Select from the list of available M N
domain values set up within the domain
Programme ST The name of the Programme 0-255 characters. Name should O N
Name containing the project. be the project name
Programme DD The name of the Programme Select from the list of available O N
Manager manager. values set up within the domain
Project Manager DD The name of the Project Select from the list of available O N
manager. values set up within the domain
Portfolio Manager DD The name of the Portfolio Select from the list of available O N
Manager. values set up within the domain
Description ST A description of the folder 0-255 characters. M N
1.18 Release Details Screen

Once you have created a Project folder you can add a new Release by completing the following screen:
Example Screen
The following data can then be completed.
- 16 -
RELEASES
Add Release
+ Modify Release
Release Name ST The project identifier for the 0-255 characters. M N
project release version
Start Date DD The start date of the first test Click the down arrow to display a M N
activity e.g. Attending PID, Test calendar and select a start date
Strategy definition and/or Risk
Assessment Workshop
End Date DD Last day of the last test activity Click the down arrow to display a M N
required as a pre-cursor to calendar and select a start date.
going live.
Project Name AG The name of the ‘release’ folder The value will default to the M N
selected. ‘release’ folder (project) selected
Release Type DD Allows user to link the test Part of Major release, Not linked M N
phase to a ‘Quarterly Release’
– See section 3.5 for details for
management and reporting.
Application DD List of the application affected Select from the list of available O N
by the Release. (NB Could also applications set up within the
be used for “Product”.) domain
Developed by DD The name of the company Accenture, SQS, Xansa, etc. a O N
responsible for development centrally controlled list.
Development ST The name or the manager 0-255 characters. Should be the O N
Manager responsible for development name of the designated
Development Manager
Release date DD The official date for to be Click the down arrow to display a O N
released to live calendar and select a start date.
Release Manager ST The name of the manager 0-255 characters. Should be the O N
responsible for managing the name of the designated Major
‘Major’ Release Release Manager
Release to live DD The name of the Major Release Select the major release that the O N
details to be linked to. project release has been
assigned to from the available list
Description ST A description of the Release 0-255 characters. Should include M N
the release notes for the release
DD = Drop Down Box, ST = Text String, AG = Auto Generated
D = Display Type – Values: M = Mandatory, O = Optional, R = Read Only, C = Conditional.
H = History retained Yes / No
- 17 -
1.19 Cycles Details Screen

Adding a new test phase within a release is performed by completing the following screen within the add
cycles function:
Example Screen
RELEASE Cycles
Add Cycle (Test Phase)
Cycle Name ST The name of the test phase, 0-255 characters. This will be the M N
this corresponds to the name name of the test phase that the
set up in the tree view cycle relates to: Unit Test,
Assembly Test, CIT, SIT, UAT,
OAT, Performance, Security
Start Date DD Planned start date for phase. Click the down arrow to display a M N
Must be within Release Start calendar and select a start date.
date
End Date DD Planned end date for phase. Click the down arrow to display a M N
Must be within Release end calendar and select a start date.
date.
Project DD The name of the project that the Select from the list of available M N
Cycle relates to projects set up within the domain
Test Phase DD The formal name of the test Unit Test, Assembly Test, CIT, M N
phase being conducted SIT, UAT, OAT, Performance,
Security
Test Phase ST The name of the manager 0-255 characters. Should be the M N
Manager responsible for the test phase name of the designated test
manager for the phase
Test Company DD The name of the Test Company Select from the list of available M N
used for this test Phase companies set up within the
(includes GRCB) domain
Test Team DD The location of the team On Shore, Off Shore M N

Location conducting the testing within
the phase
- 18 -
1.20 Major ‘Releases’ to Live

It is recognised that QC must support the management and reporting of ‘major releases’ within its
configuration set up. A major release differs from a ‘Release’ (Test Phase) as stated within Quality Center
(see Section 2.1 for definition) in that it may be made up of a number of projects technical deployments
(often across multiple programmes and domains) that are brought together and deployed to the Live
Environment as a single entity. Each project will manage its own test phases and cycles end to end but
visibility of their status and defects may be required for reporting and management purposes.
The target ‘Release to Live’ for the tested project will be entered when the Project/Programme is set up.
This can be either a Major (e.g. Quarterly) release involving multiple programmes and projects or an Interim
release of one or two projects. Project data can then be aggregated to a target ‘Release to Live’ within the
Reporting Process.”
- 19 -
4 Requirements
1.21 Requirements Workflow Process
Define Create Input Analyse

Assign to release
Testing Scope Requirements Requirement Requirement
Risk
Assessment
Requirements describe in detail what needs to be tested in your application, and provide the test team with
the foundation on which the entire testing process is based. After specifying requirements, you assign them
to the releases and cycles defined in the Releases module, you can assign requirements to one or more
releases or cycles.
You can associate the tests in the Test Plan module to your assigned requirements to create coverage. By
defining coverage, you can keep track of the relationship between the tests in your test plan and your
requirements.

The following table details the role levels that would typically generate data and perform the actions
associated with requirements:
Common Requirement Functions

Level Define Add req Modify Delete Add / Risk Assign Add
req details req req remove ass’ment Req Traceability
details details tests to
coverage
0
1
2    *   
3        
4        
5    *   
6
* Where document owner
1.23 Requirement Types
Type Description Identifier

Business A business process requirement. B
Design A system design requirement D
Folder A Folder for organizing requirements. FD
Functional A system behavioural requirement. FC
Group A collection of related requirements GP
Non Functional Testing of reliability, integration etc NF
Performance A system performance requirement. P
Testing A testing requirement TS
Security A Security requirement. S
Undefined An undefined Requirement. A QC default that can not be U
removed but recommended not to be used.
* Requisite Pro: Any requirements to be imported from Req Pro must match these Types..
- 20 -
1.24 Importing Requirements
Once project requirements have been defined, reviewed and signed off these will need to be input into your
Quality Center project. This may be done manually into the Requirements screens or using the option to
import requirements directly from Microsoft Word, Excel, or IBM Rationale Requisite Pro into the project.
1.25 Requirements Folders & Grouping

In order to efficiently manage Requirements it is possible to create folders and sub folders to provide
grouping and sub grouping appropriate to a Project size and type, e.g. it may be appropriate to structure by
Project / Release / Product or Application. However, the last (or even only!) folder level must be based
around “Modules” that are groups of Product or Application function used as sections in Management
progress reporting. So “Module” is the bottom level folder into which Requirements are placed.
The names of the “Modules” are defined by each project and appear in a drop down list box. The name
given to the module folder is free text but for simplicity should match the DD box value selected. Within the
Module folders the individual Requirement conditions are placed.
1.26 Creating Requirements Folders & Grouping
New folders may be created by completing the following screens.
REQUIREMENTS
Add Requirement Folder
- 21 -

Name ST The name of the requirement Is the free text name of the M Y
grouping Requirement grouping folder.
Requirement DD The type of requirement to be Business, Functional, Non M Y
Type entered Functional, Performance, Design,
Test
Modified AG The date that the requirement This is read only, auto generated M N
details were modified. with the system date and time
Business ST A reference to a requirement 0 – 40 characters. O N
Requirement id source document. Probably not
used at Folder level.
Requisite Pro id ST A read only reference of a 0 – 40 characters. O N
requirement imported from
Requiste pro. Probably not
Project DD The project that the Select from the list of available M N
requirement is to be delivered projects set up within the domain
by.
Target Release DD A QC link to the Release Select from the list of available O
Module, links to the release in releases set up within the
which the requirement is Release module
expected to be delivered.
Module Name DD The name of a group of Select from the list of Project O N
requirements. Used as sections defined Module names set up on
of management reports. project creation Verify Value is
enabled.
Description ST A description of the Release 0-255 characters. Should include M N
the release notes for the release
1.27 Requirements Details Screen (Manual)

Adding a new Requirement is performed by completing the following screen:
Example Screen
REQUIREMENTS
- 22 -
Add Requirement Details

Name ST The name of the requirement 0-255 characters based on the M Y
condition naming conventions stated in 2.1
Requirement DD The type of requirement to be Business, Design. Functional, M Y
Type entered Non Functional, Performance,
Security, Test.
Project DD The overall project that the Select from the list of available M N
requirement is defined against projects set up within the domain
Author DD The user name of the person By default, this is the login user M N
who created the requirement. name.
Priority DD The priority of the requirement, Must Test, Should Test, Could M N
ranging from low priority (level Test
1) to urgent priority (level 5).
Business ST The business requirement Id 0-255 characters. Searchable. O N
Requirement Id
(non Req Pro)
Requisite Pro id ST A read only reference of a O N
requirement imported from
Requiste pro. Probably not
Reviewed DD Indicates whether the Reviewed, Not Reviewed, In M Y
requirement has been reviewed Review, Signed Off.
and approved by the person When changed to “Signed Off”
responsible. the Authorised field becomes
Mandatory and a “Comment”
required.
Authorised by DD The name of the person signing Defaults to user name, select the C Y
off the Requirement Review. drop down to change user
Creation Date DD The date on which the By default, the creation date is set O N
requirement was created to the current database server
date.
Click the down arrow to display a
calendar and select a different
creation date.
Creation Time AG The time at which the By default, the creation time is set R N
requirement was created. to the current database server
time.
Modified AG Indicates the date the N/A View Only R Y
requirement was last changed.
Description ST A description of the requirement 0-255 characters O N
Comments ST Displays comments about the 0-255 O N
requirement.
Target Release DD Links a Requirement back to System generated drop down O N
the “Release” in the Release from Release module.
Module.
Target Cycle DD Links a Requirement back to System generated drop down O N
the Test Cycle in the Release from Release module.
Module.
Module Name DD The name of a group of Select from the list of available O N
requirements Modules set up within the domain
Verify Value is enabled.
1.28 Requirements Grid
The Requirements Grid is a view that enables the user to see requirements in a non-hierarchical manner
with each line of the grid displaying a separate requirement.
- 23 -
1.29 Requirements Traceability – Relationships
Requirements traceability allows a user to define a relationship between two or more requirements.
Therefore, when you are analysing the impact of a change proposed in a specific requirement, the
traceability links indicate of any other requirements that the change might affect. When a requirement
condition is changed within Quality Center then an e-mail notification may be sent to the requirement
owner. While this option is available, it is expected that all projects will be set up with alerts ‘turned off’ by
default, this will ensure that numerous and unnecessary e-mails are not generated unless specifically
requested to be set up by the programme / project. Please refer to section 8 for details on e-mail
notifications within Quality Center.
- 24 -
1.30 Test Coverage
Once tests have been linked tests to requirements it is possible to select a requirement and display the test
coverage, this will display a list of tests that cover the selected requirement and a coverage chart. It is also
possible to view, add and remove tests from the coverage for the requirement.
- 25 -
1.31 Risk Based Testing – Overview
Note – This section defines how RBT should work in GTS. Problems with the software prevent this
from being implemented and the RBT function is as it comes from the box, similar in concept but
NOT exactly as described here until a fix implemented.
When you start to plan how you are going to test your requirements you need to consider what resources
and time you have available and how this can be best used to perform the testing. It is unlikely that within
your plan you will be able to fully test every requirement and therefore you need a mechanism to help you
understand where to focus your efforts.
In order to do this Quality Center offers the opportunity to use it’s Risk Based Testing functionality to assess
your requirements and to calculate the level of risk associated with it. From this evaluation you can
determine how much focus should be placed upon that requirement in terms of testing effort. It is sensible
that for a low risk requirement you may only want to perform partial testing whereas on a high risk
requirement you would plan to test this fully. You can then plan your testing strategy based on these
recommendations.
1.32 Risk Based Testing – Business Criticality

You can assign or calculate the Risk Category of an assessment requirement. The Risk Category is defined
by its Business Criticality and Failure Probability. The Business Criticality of a requirement is a measure of
how important the requirement is to your business and what the impact would be.
REQUIREMENTS
Business Criticality
Req Id AG The system generated Id for the System Generated M N
selected requirement
Name AG The name of the requirement 0-255 characters based on the M Y
naming conventions stated in 2.1
Requirement AG The type of requirement to be Business, Functional, Non M N
Type entered Functional, Performance Test,
Development, Testing
Exclude from CB Allows a requirement to be Checked, Unchecked O N
Analysis removed from analysis
Criterion – Type DD The type of process that is Functionality, Reliability, M N
of Attribute affected by the requirement Efficiency, Maintainability,
- 26 -
Portability
Criterion – Impact DD The impact on the business if Cannot use, Incorrect Information, M N
of failure the requirement is not met Reputation, No Impact
Criterion – DD How often the feature High, Medium, Low M N
Frequency of use represented by the requirement
is used
Criterion – DD How many users are affected Significant, Some/Medium, M N
Number / by the requirement and how Minimal
Significance of important are these users to the
affected users business
Calculated AG The system generated score A (High), B (Medium) C (Low) M N
business derived from the values added
criticality under the criterion
Estimated ST The development time required 0 – 255 characters O N
Development to satisfy the requirement
time
1.33 Risk Based Testing – Failure Probability
The Failure Probability of a requirement is a measure of how likely a test on the requirement is to fail, based
on the technical complexity of the requirement’s implementation, without consideration of the requirement’s
impact on the business.
A user should determine the Business Criticality and Failure probability of a requirement by assigning those
values directly or by assigning values to a set of criteria. If you do not determine both these factors for a
requirement, Quality Center does not include the requirement in the risk analysis.
REQUIREMENTS
Failure Probability
Req Id AG The system generated Id for the System Generated M N
Name AG The name of the requirement 0-255 characters based on the M N
Requirement AG The type of requirement to be Business, Functional, Non M N
Type entered Functional, Performance Test,
- 27 -

Criteria – Change DD Whether the feature the New feature , Changed feature, M N
Type requirement is new, changed, Unchanged feature
or unchanged feature.
Criteria – DD How mature is the code of Immature, Intermediate, Stable M N
Software Maturity feature represented by the
requirement.
Criteria – Defects DD An estimate of how many High, Medium, Low M N
Rate defects are likely to be opened
that relate to the requirement.
Criteria – Number DD How many application screens > 4, 2-4, < 2. M N
of affected and entitities are affected by the
entities requirement.
Calculated failure AG The system generated score 1 High, 2 Medium, 3 Low M N
probability derived from the values added
under the criterion
Estimated Dev ST The development time required 0 – 255 characters M N
Time to satisfy the requirement
1.34 Risk Based Testing – Analyse results
After you have finalised your testing policy for a requirement, you can then analyse its effect from the
information accessible from the Analysis Results tab.
REQUIREMENTS
Analysis Results
Req Id AG The system generated Id for the System Generated R N
Name AG The name of the requirement 0-255 characters based on the R N
Requirement AG The type of requirement to be Business, Functional, Non R N
Type entered Functional, Performance Test, O
- 28 -
Use these for the CB Allows the user to add Checked, Unchecked O N
next calculation additional information to the
calculation
Testing Level DD Define the testing level included Must Test, Should Test, Could O N
in the calculation Test, Won’t Test
Testing Time ST The length of time that testing is 0 – 255 characters O N
expected to take
Estimated ST The development time required 0 – 255 characters O N
Development to satisfy the requirement
time
1.35 Requirements Details – Linked Defects
It is possible to link a defect to any of the following entities: requirements, tests, test sets, test instances,
runs, run steps, and other defects. Once the link is created you can use the Linked Defects dialog box or
tab to view and manage defect links.
1.36 Requirements Review Process

In order to ensure that requirements have been defined, captured and input correctly within Quality Center it
is necessary to ensure that the requirements review process is completed. The following diagram
demonstrates the process flow used to ensure that all requirements have been through a formal review
process prior to the start of testing.
Where a requirement is defined and entered directly onto Quality Center it will be reviewed by the relevant
personnel and comments made. Once comments have been formally reviewed and any updates made,
then the requirement status may be updated to a formally “signed off” state at which point the “Authorised
by” and “Comment” entries become mandatory.
- 29 -
Requirements review process

Not Reviewed
Test Manager
Requirements Update status to
starts review
Quality Center ‘Not Reviewed’
process
In Review
Comments from
Update status to
reviewers entered
‘In Review’
onto QC
Signed Off
Update status to Agree final Set status to

End
‘Reviewed’ wording ‘Signed Off’
Where requirements have been imported into Quality Center, either from Requisite Pro or Word / Excel,
following a formal review then they will be imported with the correct status of ‘reviewed’ set.
The importance of the review process should not be underestimated as industry experience demonstrates:
 20% of all defects are inserted during the requirements process
 30% change in requirements during a system life cycle will double the cost
 Requirements errors are the biggest class of errors (41 – 56%)
Hooks & Farry
- 30 -
5 Test Plan
1.37 Test Plan Workflow Process
Developing a clear and concise test plan is an essential requirement for successful testing. A good test plan
enables you to assess the quality of your application at any point in the testing process. Throughout the
Test Plan module users are provided with an analysis option which may be used to create and save their
own customised reports.
Common Test Plan Functions

Level Add Modify Delete Add Modify Delete Generate Link to Link Defect
Test Test Test Design Design Step Steps Script Req
Step
0
1
2   *   *  
3   *   *   
4         
5   *   *   
6
1.39 Test Cycles & Roles

Defined Standard Test Phases
- 31 -
Standard Cycles Phase Definition

Owner
Review Business with Testing of documents by using a review and sign off
(Static Testing) support from process. All “key” documents need to be reviewed,
GTS & QA defects raised where necessary and redrafts
produced. Typically “Requirement Errors” are the
biggest class of errors (41-56%) so the objective of
reviews is to remove the potential for defects before
they are coded.
A Defect Type of Requirement and Test Cycle of

Review will display an additional conditional
Document Defect Type list box.
Unit Test Application The testing of each part (unit) of code in isolation
Development
Assembly Test Application The testing of the whole part (unit) of code but in
Development isolation from any other components
Component Application Testing functionality of individual software
Integration Test Development components, including the integration and interfaces
(CIT) between integrated components
System Integration GTS Testing of integrated systems to verify that it meets
Test (SIT) specific requirements. Testing the integration of
system packages; testing interfaces to external
organisations. Covers both functional system testing
and non functional system testing (including
regression testing)
User Acceptance Business with Testing that the system supports the business
Test (UAT) support from processes as required. Customers or end users
GTS perform or are closely involved with the tests.
Operational Global Testing to ensure that new and changed technical
Acceptance Test Infrastructure infrastructure components can be implemented
(OAT) & Service reliably into the live environment and supported in
Delivery BAU.
Performance Test a test that evaluates the performance of actual or
simulated work activities. The test measures
performance as opposed to other factors.
Security Test Tests focused on ensuring the target-of-test, data, (or
systems) is accessible to only those intended
Live Confidence Business with An additional phase of testing that continues in the live
Test support from environment. Not used in all projects.
GTS
1.40 Test Plan – Create Test Folders

When creating your test plan you must first create your Test Folders by using the following screen, By doing
this you are able to segregate test within logical respositories dependent on the type and puspose of the
tests within. Once test sets have been created using the test lab functionality then they can be assigned to
the specific folders created here.
Create Test Plan Folder

Folder Name ST The logical name for the 0-255 characters. M N
grouping of tests contained
- 32 -
within
1.41 Test Plan – Test Details Screen

Once a folder has been created it is possible to add new Tests by completing the following scree n flow
Add Test
The name of the test to be
Test Name ST performed 0-255 characters M N
Manual, Auto, WR_Automated,
Confirms if the test should be VAPI_XP_Test, LT_Scenario,
Manual or Auto DD run automatically or manually System Test, ALT_Scenario M N
Example Screen
Add Test Case Details

+ Modify Test Case Details
Test Id AG Unique Identifier for the Test System generated Id M N
Test Name ST The name for the test case 0 – 255 characters M Y
Status DD The status of the test. Design, Assigned, Information, M Y
Review, Approved, Failed,
Retired.
Test Designer DD The user name of the person Defaults to user name, select the M N
who designed the test or drop down to change user.
currently “owns” it.
Creation Date AG The date on which the test was By default, the creation date is set O N
created. to the current server date.
Test priority DD The priority of the test Level 1 - 5 M N
Description ST Describes the test. 0 – 255 characters M N
Comments ST Allows comments to be 0 – 255 characters O N
recorded against the test case
1.42 Test Plan – Test Grid
The Test Grid is a view that enables the user to see tests in a non-hierarchical manner with each line of the
grid displaying a separate test. The data that is displayed within the grid can be filtered to restrict the view
- 33 -
to meet the criteria selected in the ‘filter selection’ function. Filtered views can be saved to favourites for
easy re-use.
1.43 Test Plan - Test Case Design
You build tests in the Test Plan module by defining design steps: these are detailed, step-by-step
instructions on how to execute a test. A step includes the actions to perform on your application, the input to
enter, and the expected output. A step can also include parameters. You define steps for a test after you
add the test to the test plan tree and define basic test information.
1.44 Test Plan – Test Case Requirements Coverage

Once you have linked tests to requirements you are then able to select a requirement and display the test
coverage, this will display a list of tests that cover the selected requirement and a coverage chart. It is also
possible to view, add and remove tests from the coverage for the requirement. The data that is displayed
can be filtered to restrict the view to meet the criteria selected in the ‘filter selection’ function. Filtered views
can be saved to favourites for easy re-use.
1.45 Test Plan – Test Case Linked Defects

As detailed in section 4.10 It is possible to link a defect to any of the following entities: requirements, tests,
test sets, test instances, runs, run steps, and other defects. Once the link is created you can use the Linked
Defects dialog box or tab to view and manage defect links. The data that is displayed within the grid can be
filtered to restrict the view to meet the criteria selected in the ‘filter selection’ function. Filtered views can be
saved to favourites for easy re-use.
- 34 -
- 35 -
6 Test Lab
Create Test Case
Analyse Test
Create Test Sets Schedule Runs Run Tests Define Defects
Results
Link Defects
Once you have completed your Test Plan specifications you can begin to start to prepare to run the tests.
Within Test Lab you can create test sets and choose which tests to run in each set. After you have defined
your sets you can then start to execute them and pass or fail them, once completed you are then able to
analyse the results. Where defects are identified you can define and record these and also link them within
Quality Center.
1.46 Roles & Responsibilities

Common Test Lab Functions
Level Add Modify Delete Add / Schedule / Analyse Define Link defects
test Set test set test set remove run tests test defects
test to results
test set
0
1 
2     
3        
4        
5      
6  
 Where document owner
1.47 Test Set Details

A test set is a group of tests designed to achieve specific test goals. Test sets can include both manual and
automated tests and are added by completing the following screen. When a test fails within Quality Center
then an e-mail notification is sent to the test owner. Please refer to section 8 for details on e-mail
notifications within Quality Center.
TEST LAB
- 36 -
Add Test Set

+ Modify Test Set
Field
Label Type Description Values D H
Open Date DD The date that the Test Set was Click the down arrow to display a M N
opened calendar and select a start date.
Status DD Displays the current status of Open, Closed M N
the Test Set
Target Cycle PF Displays the cycle that the test Defaults to the Test Cycle defined R N
set has been assigned to at the Test Set Folder level
ITG Request Id AG The ITG Request Id Id Number O N
Project DD The project that the set is Select from the list of available M N
assigned to projects set up within the domain
Close Date DD Indicates the date on which the Click the down arrow to display a M N
test set was closed. calendar and select a start date.
Test Phase DD The phase of testing that the Select from the list of available M N
test set is assigned to phases set up within the domain
Vendor Name
1.48 Test Set Execution Grid

The Execution Grid within Test Lab organises the data and displays it in a grid. Each row represents a
separate test record. From the function you can either run a specific test or a test set. The data that is
displayed within the grid can be filtered to restrict the view to meet the criteria selected in the ‘filter
selection’ function. Filtered views can be saved to favourites for easy re-use.
1.49 Test Run – Execution Flow

Quality center allows a user to examine the execution flow for each test run. In the execution function the
test data is displayed as a diagram and this may be used to control how, when and under what conditions
the tests are to be executed. Unlike the Execution Grid, which displays the tests with only test run information, the
Execution Flow displays the tests with conditions in a diagram.
- 37 -
For example by using the execution flow you are able to specify a date and time that you want the test to
commence and also set any conditions for executing the test. By setting conditions, you can instruct the Test
Lab module to postpone execution of the current test until the other specified test has either finished running or
passed. You can also set the sequence in which to execute the tests.
1.50 Test Run – Manual Runner

When you run a test manually, you execute the test steps you defined in test planning. You pass or fail
each step, depending on whether the actual results match the expected output.
You can execute a manual test as many times as needed. The results are stored separately for each run.
- 38 -
TEST LAB
Test Runner – Manual Runner
Run Name AG The identifier for the test run System generated R N
Exec date AG The date that the test is started System generated defaults to R N
system date
Tester DD The name of the resource System defaults to the current R N
starting the run logged in user, however by
selecting the down arrow this may
be changed from the list of
authorised users
Project DD The name of the project. Click the down arrow to display a O N
list of projects.
Test Phase DD Type of test phases Click the down arrow to display a O N
list of test phases
Exec Time AG The time that the test is started System generated defaults to R N
system time
Status AG The status of the test run Defaults to Not Completed R N
Target Cycle AG The target cycle that the test Pre-filled with the target cycle R N
set is assigned to
Test Details ST Comments or details to be 0 -255 Characters O N
recorded about the Test Run
D = Display Type – Values: M = Mandatory, O = Optional, RO = Read Only, C = Conditional.
1.51 Test Run – Manual Runner- Run Sets

As the test set is run the user can update each step with the actual result and set a pass or fail status.
1.52 Submit a Defect from a manual run

If a defect is identified during a test run it should be recorded by the tester. The following screen allows
users to record details from within the Test Lab functionality. A full field and data summary is provided
within section 7.3 Defects
- 39 -
TEST LAB
New Defect
Summary ST A brief summary of the defect. 0 – 255 Characters M N
Type DD The type of defect See defect category definitions in M Y
the category section of 7.6
Sub Type DD A sub category of the defect See defect category definitions in M Y
type the category section of 7.6
Status DD The current status of the defect. See defect status level definitions M N
in section 7.7
Sub Status DD The sub status of the defect See defect sub status level M N
definitions in section 7.7
Project DD The name of the project where Click the down arrow to display a M N
the defect occurs. list of projects.
Test Phase DD The test phase in which the Unit, Link, CIT, SIT, UAT, OAT, M N
defect was observed Performance Test, Security Test,
Live Confidence Test
Detected by ST The user name of the person who By default the system will default M N
found the defect. to the user logged in. By selecting
the down arrow this may be
changed.
Detected on Date ST The date on which the defect was By default this is set to the current M N
detected. system data
Environment DD The test environment that the Drop down will contain test O N
defect was identified environments defined locally by
Programme
Reproducible DD Can the defect be reproduced Yes, No M N
Document Defect DD Static review of documents Drop down will contain list of O N
Type document defect type
Business DD The business severity of the Severity 1 – 4 M N
Severity defect
Application DD The name of the application Drop down will contain M N
that the defect relates to applications defined locally by
Programme
Detected in DD Indicates the Release in which Select from the list of currently M N
Release the defect was detected. configured releases in Release
module.
Detected in Cycle DD Indicates the Cycle in which the Select from the list of currently M Y
defect was detected. configured cycles in Release
module.
Detected in DD Indicates the build version in Drop down will contain code M N
Version which the defect was detected. versions defined locally by the
Programme
Description ST A full description of the defect 0 – 255 Characters M N
- 40 -
1.53 Test Set - Linked Defects
As seen in Sections 4.10 & 5.6 of this document it is possible to Link a defect to other entities and these
links are displayed in the following screen:
- 41 -
7 DEFECTS
1.54 Defects Workflow Process
Don’t Fix / Defer
Reporting
Analyse Defect
Test Execution Add Defects Review Defects Fix Defects Status
Data
Re-test
Defect Management is the process of identifying, assessing, documenting, tracking, and communicating
problems that arise over the course of systems development and the lifespan of the system in Production.
This usually specifies that there should be an adequate process to handle and resolve unplanned incidents
and proactively reduce occurrence of unplanned incidents.
The Defect Management workflow enables the capturing and reporting of metrics for defects, and can be
used to determine the quality of the system under development.

Common Defects Functions
Level Add Review Update Delete Link Link Analyse
defect defect defect defect defect entities defect data
0 Defects
   cannot be   
1 deleted
2    within   
3    Quality   
   Center   
4 (even if
5    entered in   
6    error)   
1.56 Add New Defect

When a defect is identified it may be added by completing the following screen from Test Lab function:
- 42 -
DEFECTS
New Defect
Summary ST A brief summary of the defect. 0 – 255 Characters M N
Sub Type DD A sub category of the defect See defect category definitions in M Y
type the category section of 7.6
Status DD The current status of the defect. See defect status level definitions M Y
in section 7.7
Sub Status DD The sub status of the defect See defect sub status level M Y
definitions in section 7.7
Test Phase DD The test phase in which the Unit, Link, CIT, SIT, UAT, OAT, M N
defect was observed Performance Test, Security Test,
Live Confidence Test
Detected by ST The user name of the person By default the system will default M N
who found the defect. to the user logged in. By selecting
changed.
Detected on Date ST The date on which the defect By default this is set to the current M N
was detected. system data
defect was identified environments defined locally by
Programme
Reproducible DD Can the defect be reproduced Yes, No M N
Business DD The business severity of the Severity 1 - 4 M N
Severity defect
that the defect relates to applications defined locally by
Programme
Detected DD The name that the release was Select from the list of currently M N
In Release identified in configured releases
Detected in Cycle DD Indicates the cycle in which the Select from the list of currently M Y
defect was detected. configured cycles
Detected in DD Indicates the application Select from the list of currently M N
version version in which the defect was configured versions
detected.
Description ST A full description of the defect 0 – 255 Characters M N
and any associated screen
shots
1.57 Defect Details Screen
When a defect has been recorded, the following screen allows the user to update the defect and add /
update details relevant to it:
- 43 -
DEFECTS
Defect Details
Description ST A description of the defect 0-255 characters. This will be pre- M N
filled from initial creation of the
defect
Defect Id SG An auto generated ID System Generated M N
Sub Type DD The second level status of the See defect category sub type M Y
defect type definitions in the category section
of 7.8
Status DD The current status of the defect. See defect status level definitions M Y
in section 7.9
Sub Status DD The second level status of the See defect sub status level M Y
defect definitions in section 7.9
Detected by DD The user name of the person By default the system will default M N
who found the defect. to the user logged in. By selecting
changed.
Detected on date DD The date on which the defect By default this is set to the current M N
was detected. system data
defect was identified in environments defined locally by
Programme
Reproducible DD Indicates whether the defect Yes, No M N
can be recreated under the
same conditions by which it
was detected.
Business ST The business severity of the 1–4 M Y
Severity defect.
Fix priority DD The priority of the defect, Must; Should; Could; Would fix. M Y
ranging from low priority to high
priority. The fix priority is the
- 44 -
primary driver for determining

when fixes should be
completed.
that the defect relates to. By applications defined locally by
association, this may also Programme
indicate the “Product”
Assigned to DD The user name of the person Click the down arrow to display a O Y
who is assigned to fix the defect list displaying the name and full
name of each user.
Last modified AG Indicates the date and time System displays the date and O Y
when this defect was last time of last update
changed.
Detected in DD Indicates the Release in which Select from the list of currently M N
Release the defect was detected. configured Releases in the
Release module.
Detected in Cycle DD Indicates the Cycle in which the Select from the list of currently M Y
defect was detected. configured Cycles in the release
Module
Detected in ST Indicates the code build version Drop down will contain build M N
Version in which the defect was versions defined locally by
detected. Programme
Planned Closed DD Indicates the code build version Drop down will contain build O N
in Version in which the defect is planned versions defined locally by
to be fixed in. Programme
Closed in Version DD Indicates the code build version Drop down will contain build O N
in which the defect was closed. versions defined locally by
Programme
Change Request ST The CR number to resolve the 0 -255 characters C Y

Number defect. Mandatory when Closed
with Defect sub type Change
Request.
Defect Leakage DD Drop down list to indicate if the Yes / No M Y
incident could have been Default is “No”
found out in earlier testing
phases
Defect Leakage DD Drop down list to indicate the Test Phase values: O Y
Origination phase from which incident had Requirements, Analysis, Design
Phase leaked. Conditional on “Defect Build, Unit, Link, CIT, SIT, UAT,
Leakage” being “Y”. OAT, Performance Test, Security
Test, Live Confidence Test
Target Release DD Indicates in which Release the Click the down arrow to display a O N
defect is targeted to be closed. list of releases.
Should be the same as that
found in.
Target Cycle DD Indicates in which Cycle the Click the down arrow to display a O N
defect is targeted to be closed. list of cycles.
Should be the same as that
found in but may “leak” into a
later test cycle.
Estimated fix time ST Indicates the estimated number 0-255 characters O N
of days required for fixing the
defect
Actual fix time ST Indicates the actual number of If this field is left blank, Quality O N
days needed to fix the defect. Center automatically calculates
the Actual Fix Time as Closing
Closing date AG Indicates the date on which the Read only System date when C N
defect was closed. status changes to ”Closed”
- 45 -
DD = Drop Down Box, ST = Text String, AG = Auto Generated,

D = Display Type – Values: M = Mandatory, O = Optional, R = Read Only, C = Conditional. H = History retained Yes / No
1.58 Defect Grid

The Defect Grid is a view that enables the user to see defects in a non-hierarchical manner with each line
of the grid displaying a separate defect. The data that is displayed within the grid can be filtered to restrict
the view to meet the criteria selected in the ‘filter selection’ function. Filtered views can be saved to
favourites for easy re-use. The defects grid also provides users with an analysis option which may be used
to create and save their own customised reports.
1.59 Business Impact
A Severity 1 defect will result from the identification of a risk to

Impact Severity 1
the organisation of an individual situation in terms of;
(Severe
Business Impact)  Potential to adversely affect the image of the organisation
and / or result in adverse media comment.
 Potential for significant financial loss to the Bank.
 Identification of significant impact to any service provided to
an internal or external customer where;
 It is a critical point in the customer's business day.
 Critical client deliverable(s) are impacted.
 Significant infrastructure failures.
 Data is lost or corrupted (including the provision of incorrect
information to customers).
 The potential for any of the above exists.
 Inability of the Bank to meet its own, or causing widespread
impact to its customer base in meeting their, statutory
requirements.
A Major defect will be a severity 1 defect displaying one or more
of the following characteristics;
 An unknown recovery path.
 Protracted recovery.
 Failed recovery.
- 46 -
Potential to threaten individual customer relationships / generate

Severity 2
customer complaints.
(Considerable
Business Impact) Potential for financial loss to the Bank.
Identification of significant impact to any service provided to an
internal or external customer where it is a non-critical point in the
customer's business day.
High volume/ dispersed infrastructure failures, not yet causing
significant impact
Severity 3 Non critical impact with visibility to clients and/or customers,

(Limited including procedural / documentation clarification
Business Impact)
Severity 4 (Minor Non critical impact with no visibility to clients and/or customers,
Business Impact) including non-critical enquiries.
1.60 Defect Status & Flow
The different States a Defect can pass through are:

Status Sub-status Comment Owner
New Raised Just raised, nothing yet happened to the Tester
defect. Owned by the person who raised it
Open Under Review Being evaluated by PM / TM / BA / etc… Test / Defect
Manager
Assigned Assigned to someone believed qualified to fix
the defect – a developer, a DBA, a BA, etc….
Deferred Defect will not be fixed immediately but will be Test / Defect
at some point. Remains Open but no action Manager
being taken on it. Until the end of the Project
at which time all defects will be set to Closed.
This is the only case which may by-pass
Fixed state
Clarification Reviewer / Assignee could not decide what to Test / Defect
do based on the information provided. Passed Manager
to someone else to clarify – the original tester,
a specialist, more senior BA, etc…
Fixed Not Released (to Defect has been fixed by developer but the Developer
Test) Build Cycle incorporating the “Fix” has not yet
been released to Test.
Released (to Waiting for tester to rerun script / test case. Tester
Test)
Passed Re Test has taken place and Passed. (See Tester
Reopen in failed.)
Closed Duplicate Identified as a duplicate of an existing defect. Test / Defect
Manager
Error Defect was raised in error – e.g. by Tester. Test / Defect
Manager
Passed Defect has been fixed, retested and Passed Test / Defect
the test case. Manager
Exemption The Project is ending. ALL defects must be Test / Defect

Closed but this defect is unresolved. An Manager
exemption to go live with the defect is needed
with an email attachment as proof. The
Comments field must show where the defect
has gone – e.g. to a Production Incident log in
Service Center, the next project, etc.
- 47 -
Status Sub-status Comment Owner

Reopen A defect has Failed the retest and is sent back Tester
through the appropriate investigation / fix
cycle.
Also, a Defect that has already been “Closed”
in an earlier Test Cycle, or even an earlier test
Phase, but has re-emerged. NB This requires
recognition by the Raiser, Reviewer, etc. or a
search of old Defects when a new one is
raised (process needed…..). In this instance
the “new” defect is “closed” and the old defect
is reopened. So a defect can go to the
“Reopen” state at anytime it has been
recognised as an old defect……
Under Review As above Test / Defect

Manager
Assigned As above Developer
Deferred As above Test / Defect
Manager
Clarification As above Test / Defect
Manager
The relationship between defects, Status and responsibility areas is shown in the
following Defect Process State Flow diagram.
- 48 -
1.61 Defect Process Flow Diagram
Responsibilities Action (s) Status
Find Problem
Tester
State = New
Tester Report Problem SubState = Raised
State = Open/ Reopen

Test Manager/ SubState = Under Review
Review Problem
Defect Manager
State = Open/ Reopen
SubState = Clarification
State = Open
Application Team / SubState = Assigned
External Supplier Analyse Problem
Additional fix required from
“Test Passed?” = No.
then
State = Reopen
Test/Defect Manager Sub State = Assigned
Application Team / and
Fix Required?
External Supplier No Reopen Counter = +1
Yes
Test/Defect Manager State = Open/ Reopen

Immediate Defer
Application Team / SubState = Deferred
Fix Required? No Problem
External Supplier
Yes
Application Team / State = Open/ Reopen

External Supplier Fix Problem SubState = Assigned
Application Team/ Fix Released Build Defect Fix State = Fixed

External Supplier to Test? Release SubState = Not Released
No
Yes
State = Fixed
Tester Retest Problem
SubState = Released
No
Test Passed?
Yes
Test Manager/ State = Fixed

Defect Manager Wait Closure SubState = Passed
No
Test Manager/
Defect Manager
Close Problem?
Yes
State = Closed
Reopen Defect. SubState = One of:
If a “Closed” defect reoccurs Passed
the “New” defect is “Closed” Problem Closed Duplicate
and the existing defect Error
“Reopened”. Exemption
- 49 -
1.62 Defect Category

Category Sub Level Sub Level Definition
tbc tbc A Defect type permissible only for defects with a
state of “New/Raised”; “Open/Clarification” or
“Open/Under Review”. See next table. Use when
the defect category is not yet clear and “to be
confirmed”.
Code The result of incorrect application coding.
Build
Configuration Error identified within the build documentation
Local to Appl Incorrect data contained within local databases

(e.g. EPAT, E Services, IDT)
Data Mainframe Incorrect data contained within mainframe

databases (e.g. DB2, IMS)
Reference Incorrect reference data contained on mainframe

and/or local database
Hardware Hardware fault.
Environment Connectivity Problem with the applications connectivity/comms

between the applications being tested.
Network Network problems (e.g. IMSA, CICS)

Deploy - Test Env Incorrect implementation into the test environment.
Implementation
Deploy - Live Env Problems with deployment into a live environment
Design Incorrect Design requirements
Operational Incorrect Operational requirements
Performance Test Incorrect Performance Test requirements
Requirements Business Faults found in Business Design (e.g. BOM, BOD)
Technical Faults found in the Technical specifications (e.g.

System or Detailed design)
E2E Faults found in the High Level design (e.g E2E

design)
Change Raised The defect has identified a functional problem in

design which requires a change request
No Fault Found Defect raised but found not to be a problem
User Error Tester or user error (i.e. incorrect script)
Un reproducible Defect raised but the problem could not be re

Test produced.
Duplicate Defect Defect raised but found to be a duplicate.
- 50 -
Defect Type and Sub Type for a New Defect.
When a Defect has just been raised it may not be possible to determine an accurate “category”. For an
initial stage of the defect life cycle a type of “tbc” is permitted.
Defect Status Sub Status Defect Type Sub Type Owner

Defect is first New Raised tbc tbc Raising TA
raised.
Defect is Open Under tbc tbc Test /

being Review Defect
evaluated Manager
Additional Open Clarification tbc tbc TA/BA,
information specialist,
needed. …
The defect Type and Sub Type is NOT restricted to “tbc” i.e. other values are permitted if an early decision
is made.
For ALL other defect states a defect Type and Sub Type become mandatory as a value OTHER THAN “tbc”
– i.e. a decision has to be made.
1.63 Document Defect Type

Quality Center supports the static review of documents and enables specific defect types to be used for
analysis.
When the Defect Category is Requirements and the Test Phase is “Review” an additional drop down list
box appears
Defect
Definition
Classification
Ambiguous The word or phrase may be interpreted with more than one meaning
Incomplete A phrase should contain enough information to fulfil its purpose.
Untraceable All requirements/components/items must have unique identifiers
Untestable It must possible to prove that a requirement has been achieved
Mistake The document author has made a factual or technical error
Cosmetic Spelling mistakes etc which do NOT affect the meaning of the document
Any defects not clearly covered in the above defect classifications
Other A classification of “Other” would not normally be acceptable. Can it be
removed?
- 51 -
1.64 Fix Priority

Priority This has a severe impact on testing. This must be fixed
immediately.
A Must A critical set of functionality scoped to be tested cannot be
completed and needs this issue fixed before testing can
be continued.
This has a major impact on testing. This should within
fixed within a day of the defect being logged
B Should A major set of Functionality can only be tested by use of a
complicated work-around which is slowing down test
progress.
This has a medium impact on testing. The problem could
be fixed before release of the current version in
C Could development.
The Bug affects pass success on some tests but the issue
can be by-passed for other tests by means of a simple
work-around
This has a minor impact on testing. The defect would be
fixed if there is time, but it could be deferred until another
D Would release.
This defect is normally cosmetic in nature and does not
affect the key delivery of the Business requirements.
1.65 Linked Entities

A defect can be linked directly or indirectly to an entity. When you add a defect link to an entity, Quality
Center adds a direct link to this entity and direct links to other related entities.
In addition, during a manual test run, if you add a defect, Quality Center automatically creates a linkage
between he test run and the new defect.
(DEFECT => RUN => STEP RUN => TEST SET => STEP => TEST CASE => REQUIREMENT =>
RELEASE => FULL TRACEABILITY)
- 52 -
8 E-mail Notifications
It is possible to use and configure the system to provide e-mail notifications, these can be either manual or
in some cases automated. The following sections provide further detail on where and how these can be
used.
1.66 Manual E-mail Notification

Requirements
Within the requirements functionality you are able to send an e-mail to other users in the (Quality Center)
project. By doing this you are able to inform development, quality assurance and project members about
the status of a requirement. The e-mail that is generated contains a link to the requirement and enables the
recipient to go straight to that specific requirement and view its content. In order to create an e-mail the user
just selects the Send by E-mail button from the requirements screen and the e-mail dialogue box is opened.
Defects
Within the defects functionality you are also able to manually send an e-mail regarding a defect to another
user. Typically this may be used to advise the relevant people within a project of the defect status and
repair activity. Again the functionality is accessed by the Send E-mail function and the above dialogue box
opens allowing the user to create the e-mail containing a link.
1.67 Automated E-mail Notification

When setting up and running a project it is possible to activate Alert rules for the project. By doing this the
administrator can configure the system to send notification e-mails and set up automatic alerts to inform of
changes that may occur within the project that may affect the overall testing process. By default these
notifications are ‘turned off’ but can be configured by Testers with Access level 3, e.g. a Test Project
Manager.
Where agreed, the project administrator can configure these settings from the customisation function within
Quality Center, this Auto mail function allows the user to define the circumstances and changes that will
trigger when alerts or notifications should be sent, the information provided and who it should go to. This
functionality may be used to update a Project Manager if requirements are updated or changed or to notify
an individual that a defect has been assigned to them.
It is advised that Testers use customised views to regularly monitor all tasks that have been
assigned to them and NOT rely on multiple emails.
- 53 -
Alert Rules
As mentioned it is possible to set Alert rules up within Quality Center. These alerts will allow the project
team to keep track or requirements, tests and defects as the testing process is undertaken. The Alert Rules
are set up from within the customisation functionality and may be configured to best suit the project needs.
- 54 -
Appendix A – Access Permissions
Key:
Level Description
0 View only – all modules
1 Full access to Defect module + view only to other modules
2 Access to all modules but Releases (view only to this module)
3 Full access to all modules, with partial deletion rights
4 Full access to all modules, including full deletion rights
5 Same access as Level 2 + Business Process Testing module
6 Restricted access to Defects module only
x Full rights access
x* Document owner only
RELEASES Level Permissions

0 1 2 3 4 5 6
Add Release x x
Modify Release
+ Application x x
+ Attachment x x
+ Description x x
+ End Date x x
+ Major Release Details x x
+ Project x x
+ Release Name x x
+ Release Type x x
+ Start Date x x
+ STO x x
+ Test Environment x x
+ Test Manager x x
+ Test Phase x x
+ Test Team x x
+ Vendor Manager x x
+ Vendor Name x x
Delete Release x
Add Release Folder x x
Modify Release Folder
+ Attachment x x
+ Description x x
+ Developed By x x
+ Programme x x
+ Programme Manager x x
+ Project x x
+ Project Manager x x
+ Release Date x x
- 55 -
RELEASES Level Permissions

0 1 2 3 4 5 6
+ Release Manager x x
+ Release Name x x
+ Release Type x x
+ STO x x
+ Vendor Name x x
Delete Release Folder x
Add Cycle x x
Modify Cycle
+ 3rd Party x x
+ Attachment x x
+ Description x x
+ End Date x x
+ Name x x
+ Project x x
+ Project Manager x x
+ Release Name x x
+ Start Date x x
+ STO x x
+ Test Environment x x
+ Test Phase x x
+ Vendor Name x x
Delete Cycle x
- 56 -
REQUIREMENTS Level Permissions

0 1 2 3 4 5 6
Add Requirement x x x x
Modify Requirement
+ Attachment x* x x x*
+ Author x x x x
+ Authorised By x x x x
+ Business Requirement ID x x x x
+ Comments x* x x x*
+ Creation Date x x
+ Creation Time x x
+ Description x* x x x*
+ Developed By x x
+ Direct Cover Status x x
+ Module Name x x x x
+ Name x x x x
+ Old Type (obsolete) x x
+ Priority x x x
+ Project x x x
+ RBQM xxxxx x x
+ Release Name x x
+ Requisite Pro ID x x x x
+ Requirement Type x x x x
+ Reviewed x x x x
+ Rich Text x x x x
+ STO x x
+ Target Cycle x x
+ Target Release x x
Delete Requirement x* x x*
Add Tests To Coverage x x x x
Remove Tests From Coverage x x x x
Add Requirement Traceability x x x x
Modify Requirement Traceability
+ Trace Comment x* x x x*
Remove Requirement Traceability x* x x x*
Risk-Based Quality Management
+ Assess Business Criticality x x
+ Assess Failure Probability x x
+ Analyze x x x x
TEST PLAN Level Permissions

0 1 2 3 4 5 6
- 57 -
Add Test x x x x
Modify Test
+ Approved By x* x x x*
+ Comments x* x x x*
+ Creation Date x x
+ Description x* x x x*
+ Designer x x x x
+ Estimated DevTime x x
+ Execution Status x x x x
+ Path x x x
+ Release Date x x x x
+ Reviewed x x x x
+ Reviewed By x x x x
+ Status x x x x
+ Subject x x x
+ Template x x
+ Test Designer x x x x
+ Test Name x x x x
+ Test Priority x x x x
+ Test Type x x x x
Delete Test x* x* x x*
Add Design Step x x x x
Modify Design Step
+ Attachment x x x x
+ Description x x x x
+ Expected x x x x
+ Step Name x x x x
Delete Design Step x* x x x*
Add Folder x* x x x*
Modify Folder
+ Name x x
Delete Folder x
Move Folder x x x
Copy Folder x x x
Generate Script x x x
TEST LAB Level Permissions

0 1 2 3 4 5 6
Add Test Set x x x x
Modify Test Set
- 58 -

0 1 2 3 4 5 6
+ "On Failure" Settings x x
+ Close Date x x
+ Execution Flow x x x x
+ ITG Request Id x x x x
+ Open Date x x x x
+ Project x x x x
+ Release Name x x x x
+ Status x x x x
+ STO x x x x
+ Test Phase x x x x
+ Test Set x x x x
+ Test Set Notification Settings x x x x
+ Vendor Name x x x x
Delete Test Set x x
Move Test Set x x
Copy Test Set x x x x
Add Folder x x
Modify Folder
+ Name x x
+ Target Cycle x x x x
Delete Folder x
Move Folder x x x
Copy Folder x x x
Add Tests To Test Set x x x x
Modify Test in Test Set
+ "On Failure" Settings x x
+ Exec Date x* x x x*
+ Order Tests In Test Set x x x x
+ Planned Exec Date x x x x
+ Planned Exec Time x x x x
+ Planned Host Name x x x x
+ Project x x x x
+ Release Date x x x x
+ Responsible Tester x x x x
+ Reviewed x x x x
+ Reviewed By x x x x
+ Run Configuration x* x x x*
- 59 -

0 1 2 3 4 5 6
+ Status x x x x
+ Test Phase x x x x
+ Test Priority x x x x
+ Test Version x x x x
+ Time x x x
Remove Test From Test Set x x x x
Run Test x x x x
Modify Run
+ Actual [STEP] x x
+ Attachment [RUN] x* x x x*
+ Attachment [STEP] x x x x
+ Description [STEP] x x x x
+ Duration [RUN] x x x x
+ Exec Date [RUN] x x x x
+ Exec Date [STEP] x x x x
+ Exec Time [RUN] x x x x
+ Exec Time [STEP] x x x x
+ Expected [STEP] x x x x
+ Host [RUN] x x
+ Operating System [RUN] x x
+ OS Build Number [RUN] x x
+ OS Service Pack [RUN] x x
+ Project [RUN] x x x x
+ Run Name [RUN] x x
+ Source Test [STEP] x x
+ Status [RUN] x x x x
+ Status [STEP] x x x x
+ Step Name [STEP] x x
+ Test Details [RUN] x* x x x*
+ Test Phase [RUN] x x x x
+ Test Version [RUN] x x
+ Tester [RUN] x x
Delete Run x* x
Reset Test Set x x
Add Hosts x x x x
Modify Hosts x x x x
Delete Hosts x
Add Host Group x x x x
Modify Host Group x x x x
Delete Host Group x
- 60 -
- 61 -
DEFECTS Level Permissions

0 1 2 3 4 5 6
Add Defect x x x x x x
Modify Defect
+ Actual fix time x x x x
+ Application x x x x x x
+ Assigned to x x x x x x
+ Attachment x x x x x x
+ Business Severity x x x x x x
+ Change Request No. x x x x x x
+ Closed in Version x x
+ Closing Date x x
+ Comments x x x x x x
+ Defect Leakage x x x x x x
+ Defect Leakage Organisation Phase x x x x x x
+ Description x x x x x x
+ Detected By x x x x x x
+ Detected in Cycle x x x x x x
+ Detected in Release x x x x x x
+ Detected in Version x x x x x x
+ Detected on Date x x x x x x
+ Environment x x x x x x
+ Estimated Fix Time x x
+ Fix Priority x x x
+ GRCB_nn x x x x x x
+ GTS_nn x x x x x x
+ Planned Closing Version x x x x x
+ Project x x x x x x
+ Project_nn x x x x x x
+ Release Name x x x x x x
+ Reproducible x x x x x x
+ Re-raised counter x x x x x x
+ Status x x x x x x
+ Subject x x x x x x
+ Sub-Status x x x x x x
+ Sub-Type x x x x x x
+ Summary x x x x x x
+ Target Cycle x x x x x x
+ Target Release x x x x x x
+ Technical Component x x x x x x
+ Test Phase x x x x x x
+ Type x x x x x x
Delete Defect x
- 62 -
DEFECTS Level Permissions

0 1 2 3 4 5 6
Add Defect Link x x x x x x
Modify Defect Link
+ Link Comment x x x x x x
+ Link Type x* x x x x x
Remove Defect Link x* x* x* x x* x
- 63 -

QCStandardProcesses Latest

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

QCStandardProcesses Latest

Uploaded by

Copyright:

Available Formats

Quality Center – Standard Processes and Templates

1.5 Quality Center Workflows...............................................................................................................................8

1.6 Quality Center Relationships.........................................................................................................................9

1.7 Acronyms and abbreviations.......................................................................................................................10

2.1 Version Control................................................................................................................................................11

2.2 Naming Conventions......................................................................................................................................11

2.3 User Registration............................................................................................................................................11

2.4 Quality Center Naming Conventions.........................................................................................................11

2.6 Quality Center Repository Registration....................................................................................................13

2.7 Access Levels..................................................................................................................................................14

3.1 Releases – Workflow Process.....................................................................................................................16

3.2 Roles and Responsibilities...........................................................................................................................16

3.3 Setting up a Release Folder.........................................................................................................................17

3.4 Release Details Screen..................................................................................................................................18

3.5 Cycles Details Screen....................................................................................................................................20

3.6 Major ‘Releases’ to Live................................................................................................................................21

4.1 Requirements Workflow Process...............................................................................................................22

4.2 Roles and Responsibilities...........................................................................................................................22

4.3 Requirement Types.........................................................................................................................................22

4.4 Importing Requirements................................................................................................................................23

4.5 Requirements Folders & Grouping............................................................................................................23

4.6 Creating Requirements Folders & Grouping...........................................................................................23

4.7 Requirements Details Screen (Manual).....................................................................................................24

4.8 Requirements Grid..........................................................................................................................................26

4.9 Requirements Traceability – Relationships.............................................................................................26

4.10 Test Coverage..................................................................................................................................................27

4.11 Risk Based Testing – Overview...................................................................................................................28

4.12 Risk Based Testing – Business Criticality...............................................................................................28

4.13 Risk Based Testing – Failure Probability..................................................................................................29

4.14 Risk Based Testing – Analyse results.......................................................................................................30

4.15 Requirements Details – Linked Defects....................................................................................................31

4.16 Requirements Review Process...................................................................................................................31

5.2 Roles and Responsibilities...........................................................................................................................33

5.3 Test Cycles & Roles........................................................................................................................................34

5.4 Test Plan – Create Test Folders..................................................................................................................34

5.5 Test Plan – Test Details Screen...................................................................................................................35

5.6 Test Plan – Test Grid......................................................................................................................................36

5.7 Test Plan - Test Case Design.......................................................................................................................36

5.8 Test Plan – Test Case Requirements Coverage.....................................................................................36

5.9 Test Plan – Test Case Linked Defects.......................................................................................................37

6.2 Test Set Details................................................................................................................................................38

6.3 Test Set Execution Grid.................................................................................................................................39

6.4 Test Run – Execution Flow...........................................................................................................................39

6.5 Test Run – Manual Runner...........................................................................................................................40

6.6 Test Run – Manual Runner- Run Sets........................................................................................................41

6.7 Submit a Defect from a manual run............................................................................................................41

6.8 Test Set - Linked Defects..............................................................................................................................43

7.1 Defects Workflow Process............................................................................................................................44

7.2 Roles and Responsibilities...........................................................................................................................44

7.3 Add New Defect...............................................................................................................................................44

7.4 Defect Details Screen.....................................................................................................................................45

7.5 Defect Grid........................................................................................................................................................48

7.6 Business Impact..............................................................................................................................................48

7.7 Defect Status & Flow......................................................................................................................................49

7.8 Defect Process Flow Diagram......................................................................................................................51

7.9 Defect Category...............................................................................................................................................52

7.10 Document Defect Type..................................................................................................................................53

7.11 Fix Priority.........................................................................................................................................................54

7.12 Linked Entities.................................................................................................................................................54

8.2 Automated E-mail Notification.........................................................................................................................55

1.5 Quality Center Workflows

Setting up and using Quality Center

Setting up and using Quality Center - Continued