1

Quality Center 10.0

NOTE: Uninstall the current version of QC before downloading QC 10.0. All QC 10.0 documents can be located on the BI Shared Services Tools Team sharepoint site before downloading QC 10.

The first time you log into QC 10.0 it may take several minutes until the download completes. Do not interrupt this process. Due to latency the download will take longer for offshore teams.

2

The Management ModuleDefining Releases and Cycles

Allows users to clearly define releases and cycles. Cycles equates to builds/service packs etc.

• Define folder structure

• Establish Standard Naming Conventions

• Define release

• Define cycle

• Enter Start/End Dates

3

Libraries

A library represents a set of entities in a project and the relationships between them. The entities in a library can includerequirements, tests, test resources, and business components.

Select the folder level for the Requirement Root, Test Root and Resource Root

4

The Requirements module is now folder based. The base functionality remains the same with the addition of the ‘Assign to Release’, ‘Assign to Cycle’ and ‘Requirement Traceability’.

Requirements Module

5

Using the Requirements Traceability tab in theRequirement Details view, you can add traceability links to and from a selected requirement. Trace from links indicate requirements that affect a selected requirement. Trace to links indicate requirements that are affected by a selected requirement.Right click on the

requirement. Select Requirement Traceability

• Requirements traceability defines a relationship between two or morerequirements. When analyzing the impact of a change proposed in a specificrequirement, the traceability links indicate the other requirements that thechange might affect.• After defining your requirements in the requirements tree, you can establish traceabilitybetween the requirements. Using the Requirements Traceability tab in theRequirement Details view, you can add traceability links to and from aselected requirement. Trace from links indicate requirements that affect aselected requirement. Trace to links indicate requirements that are affectedby a selected requirement.• When a requirement changes, Quality Center alerts the affectedrequirements. The alerts can be seen by all users. Quality Center also sendsemail notifications to the authors of the affected requirements.

Requirements Traceability

6

Requirements Traceability

Example

The Trace From grid displays requirements that affect a selectedrequirement. The Trace To grid displays the requirements that are affectedby the selected requirement.

After establishing traceability relationships, you can analyze the impact of requirement changes by reviewing the relationships. The Impact Analysis tab helps you understand the many associations and dependencies thatexist between the requirements by displaying them in a hierarchical tree structure. Unlike the Relationships tab, the Impact Analysis tab shows the affected requirements along with their parent and child requirements.

7

Test Plan Module

There has been minimal changes to the Test Plan module. There is a new enhancement to add Test Parameters. This allows a tester to use different variables with their testing.

During test execution this allows a tester to select a default value or to enter in the actual value.

8

The Test Resources module enables you to manage resources used by your tests. You can organize your resources by defining a hierarchical test resource tree containing resource folders and resources. For each resource in the tree, you select and upload a set of resource files to the Quality Center repository. These files can be used by one or more tests.

Test Resources

9

10

About Calculating Requirement Risks

When planning how to test your requirements, you generally do not haveunlimited resources available, and are not able to fully test everyrequirement. You must make compromises and only partially testrequirements that have low criticality to the business, or those that haveonly a minor risk associated with their implementation. The risk-basedquality management feature enables you to calculate at which level to testeach requirement, based on the nature of the requirement and the resourcesyou have available. You can then plan your testing process based on theserecommendations.Each requirement type can be enabled for risk-based quality management.Each requirement type with risk-based quality management enabled cansupport either risk analysis which is referred to as an analysis requirement,or an individual risk assessment which is referred to as an assessmentrequirement.

➤ An analysis requirement is a requirement belonging to a type that representshigher levels in the requirements tree hierarchy, such as the Folder type. Youperform risk analysis on an analysis requirement based on the assessmentrequirements under it in the requirements tree.The risk results of multiple assessment requirements are aggregated to givean overall risk analysis which can then be used to determine testing effortand test strategy.

➤ An assessment requirement is a requirement belonging to a type thatrepresents requirements that are children of analysis requirements and at alower level in the requirements tree hierarchy. Assessment requirementsunder a particular analysis requirement form the basis for risk analysis onthat analysis requirement.You work with risk-based quality management in the Requirement Detailsview of the Requirements module. You can also work with risk-based qualitymanagement in the Risk view of the Requirement Details dialog box.

11

For each assessment requirement under the analysis requirement, you canassign or calculate the Risk and Functional Complexity. The Risk Category iscomposed of its Business Criticality and Failure Probability. The Functional

Complexity Category indicates the complexity of the requirement’simplementation.

You determine the Business Criticality, Failure Probability, and FunctionalComplexity of a requirement by assigning them values directly or by

assigning values to a set of criteria. If you do not determine these factors fora requirement, Quality Center does not include the requirement in the risk

analysis.You can customize these criteria, their possible values, and how these values

determine the Business Criticality, Failure Probability, and FunctionalComplexity. You can also customize how the Business Criticality and Failure

Probability are used to calculate the Risk.

12

Select the Risk tab for the specific requirement. Begin with the Risk Assessment tab. Select the Business Criticality tab. Select the appropriate value from the Criterion drop down list. Reference the ‘Description of Criterion’ window for definition of data values.

Do the same for the Failure Probability.

13

Follow the same steps with the Functional Complexity tab.

The Functional Complexity Category indicates the complexity of therequirement’s implementation.

14

At the bottom of the Risk tab, in the Estimated development time box, youcan type the estimated time needed to develop the requirement.Quality Center can then calculate the total estimated development time foran analysis requirement and its children as the sum of the estimated development times of the children. Assigning the estimated development time is optional, and does not affect the risk analysis.

15

The Risk Category is composed of two factors: Business Criticality andFailure Probability. Business Criticality measures how crucial a requirementis for business. Failure Probability indicates how likely a test based onthe requirement is to fail.The Failure Probability of a requirement is a measure of how likely a test onthe requirement is to fail. It has three possible values: 1 - High, 2 - Medium,and 3 - Low. For example, a requirement whose implementation involvesmaking significant changes across most areas of your application wouldprobability be assigned a High Failure Probability. In contrast, a requirementthat involves changing an icon in your application would probably nothave many associated risks, and so is likely to be assigned a Low FailureProbability.

The Business Criticality of a requirement is a measure of how important therequirement is to your business. It has three possible values: A - Critical,B - Important, and C - Nice to Have. For example, a requirement affecting aminor feature that is likely to be used rarely might be assigned a Nice to HaveBusiness Criticality, whereas a requirement that is essential to yourapplication’s functionality would probably be assigned a Critical BusinessCriticality.

16

QC calculates the risk based on the user input.

17

After you have finalized your testing policy for an analysis requirement, you can analyze the testing strategy for the analysis requirement and for theassessment requirements under it. The analysis results are only valid for the requirements at the time the analysis was last performed. If yousubsequently modify the Risk or Functional Complexity Categories of the requirements, or the testing policy, you should re-perform the analysis.

18

Defining the Testing Policy Settings

After you have defined the Risk and Functional Complexity for eachrequirement, you determine how much time each requirement needs to betested. The time needed to test a requirement depends on the FunctionalComplexity of the requirement. A requirement with a high Functional

Complexity generally requires more testing time as it is more likely that therequirement’s implementation contains defects. For each Functional

Complexity, you define the Testing Time needed to fully test a requirementwith that Functional Complexity.

Quality Center defines four Testing Levels: Full, Partial, Basic, and None. Forpartial and basic testing, you define how much Testing Time is required for a

requirement as a percentage of full testing. For example, if 20 hours arerequired to perform full testing on a requirement and partial testing is

defined as 75% of full testing, Quality Center calculates that 15 hours arerequired to perform partial testing on the requirement. A requirement

whose Testing Level is set to None is not tested at all, and the Testing Effortis zero.

After you define the Testing Time required for each Testing Level andFunctional Complexity, you can estimate at what Testing Level to testrequirements. For each Risk and Functional Complexity Category, you

assign a Testing Level.

19

To define the testing policy settings for a requirement:1 In the Requirement Details view of the Requirements module, select ananalysis requirement and click the Risk tab. Click the Show button todisplay the Change Analysis Constants section.2 Under Testing Time (full) per Functional Complexity, for each FunctionalComplexity value, type the estimated Testing Time required to fully test arequirement.3 Under Testing level, in the Partial and Basic boxes, type the default TestingTime required for partial testing and basic testing of a requirement. Youexpress this as a percentage of the effort required for full testing.4 In the Testing Policy grid, define the level at which to test a requirement ofeach Risk and Functional Complexity Category.To define these levels, click the arrow next to the cell in the grid. Select aTesting Level from the available Testing Levels. The available Testing Levelsare Full, Partial, Basic, and None. Next to each Testing Level, you can see theestimated time needed to test a requirement at that level, based on theTesting Efforts and Testing Levels you defined.5 To display the default constants used, click the Show Defaults button. TheRisk-Based Quality Management Constants Defaults dialog box opens.In the Risk-Based Quality Management Constants Defaults dialog box, youcan click the Restore Defaults button to assign these default values to theconstants used for the current requirement.

20

Finalizing the Testing Policy

Based on the testing policy you defined, Quality Center can calculate thetotal estimated testing time for the analysis requirement and the assessmentrequirements under it. You estimate how much time you have available totest these requirements and make adjustments to the testing policy to make

sure that the testing time required does not exceed the testing resourcesavailable.

For example, suppose you have 100 hours available to test a requirement.Quality Center estimates that you need 120 hours to test the requirement

using the current Testing Levels. You decide to lower the Testing Level forrequirements with Low Risk and Medium Functional Complexity from Partial

to Basic. After you adjust the Testing Level and recalculate the testing time,Quality Center estimates that you need only 98 hours to perform the

testing, which is within the time you have available. You can now plan thetesting of your requirement based on Quality Center’s recommendations.

21

To finalize the testing policy:1 Make sure that you have determined the Risk and Functional ComplexityCategories of all assessment requirements that are located under the analysisrequirement for which you want to finalize the testing policy, and that you

want to include in the risk analysis.2 You can filter the requirements tree to include only the assessment

requirements you want to include in the risk analysis.3 In the Requirement Details view of the Requirements module, select an

analysis requirement and click the Risk tab.

22

The Dashboard Module

The Analysis View tab contains a tree in which you organize all of youranalysis items. Analysis items can be any of the following analysis types:graphs, standard reports, and Excel reports.

23

The Dashboard View tab contains a tree in which you organize dashboardpages. In Dashboard pages you arrange multiple graphs that you created inthe analysis tree, and display them in a single view.

24

25