1. HP Quality Center 10.0 The Test Plan Module
To protect the confidential and proprietary information included in this material, it may not be disclosed or provided to any third parties without the approval of QA TRAINING EXPERTS.

2. Introduction

3. Agenda About the Test Plan Module Test Planning Process Flow
Creating the Test Plan Tree
Creating your Tests

4. Creating a Test Plan Tree
Creating Subject Folders, Sub‐Folders
Adding a Test
Filling in the Details Tab
Adding Test Steps
Requirements Coverage
Linking Tests to a Requirement

5. About the Test Plan Module

6. The Test Plan Module is where tests are created and stored.
This module is the place where all of our tests for the project will be stored.
The Test Plan Module is our Test Repository.
All Types of Tests can be stored in this module such as Manual, Automated, Performance, etc.

7. The Test Planning Process Flow

8. The Test Planning Process Flow
Define Test Subjects
Define Tests
Add Tests Steps
Link to Requirement

9. The Test Planning Process Flow
Define Test Subjects
The process begins by defining the Test Subjects. The Plan Test Tree is a graphical representation of your test plan.
It is a hierarchical list of the tests organized according to topic.
usually be decided by the QA Lead.
can be organized by functionality, method, phase of testing, etc.
referred to as Subjects in the Test Plan Module.

10. The Test Planning Process Flow
Define Tests
Once the Test Plan Tree has been created the next step in the process is to define the tests that will be required.
Note:
Test Scenarios are represented by folders
Test Cases are represented by tests

11. The Test Planning Process Flow
Add Test Steps
After creating a test the next step is to add test steps describing the actions to perform and their expected results.
Note:
Test Parameters can be added to make the test flexible enabling you to run the same test repeatedly and assign different values to the parameters.

12. The Test Planning Process Flow
Linking to Requirements
Test Cases are linked to requirements from the Test Plan module to show coverage.
By linking a Requirements to a Test a relationship is established between the two entities.
Note:
This can be done before test steps are added when tests are identified to show coverage.

13. Creating a Test Plan Tree
You define framework for your test plan by creating a Test Plan Tree that contains folders and subfolders.
In this tree, tests are added to folders and subfolders, and strategy for testing is defined through the structure.

14. Creating Subject Folders & Sub-Folders

15. Select folder where you want to place the test
Test Type will typically be Manual
Test Name specifies the name by which the test will be referred to in all other places in QC
QC will challenge user for required fields after OK is pressed
Tests can be moved from folder to folder via drag/drop or cut/paste

16. Filling in the Details Tab

17. Adding Test Steps

18. Links are added between tests in the Test Plan Module and requirements in the Requirements Module.
Purpose is to have traceability between requirements to tests as well as tests to requirements
In Test Plan Module, requirements coverage is by selecting requirements to link to a test.
In Requirements Module, tests coverage is by selecting tests to link to a requirement.

19. You can define links between
requirements and tests from either the Test Plan module or the Requirements module.
You can review the test‐requirement
relationship at any time during the testing process to check how changes in requirements impact your test plan.

20. In Test Plan Module, select a test
Click on ‘Requirement Coverage’ tab
Click ‘Select Requirement’ button (Requirement Tree appears)
Select a requirement
Add to Coverage (Without Children or Include Children)

21. Linking Requirements to a Test

22. Linking Tests to a Requirement

23. Linking Requirements to a Test

24. More about Creating tests
Copying Test Steps
Managing Design Steps
Calling Manual Tests
Calling Tests with Parameters
Defining a Parameter
Using Parameters

25. Copying Test Steps Steps can be copied:
From one test to another
Within the same Test
Tests can be copied from Project to
Project

26. Managing Design Steps To manage your design steps you can:
Editing Design Steps
Reordering Design Steps
Renumbering Design Steps
Resizing Design Steps
Arranging Design Step Columns
Deleting Design Steps
Copying Design Steps in a Project
Copying Design Steps Across Projects
Finding And Replacing Step Text

27. Calling Manual Tests
Calling a Test allows you to call the steps of another manual test into another.
A Test can be called within another Test for reusability purposes.
You cannot pick and choose what steps
of the test are called.
All Steps of the Test being called are included in your existing test.

28. alling Tests th ameters
Parameters act as placeholders for input values.
You add parameters to save the place for
inputs that can be specified later.
Parameters are very useful when specific inputs are not known when a test is created.
Parameters are used to create reusable tests or a template test.
Parameters can be used to allow for a step to be repeated using different inputs each time.

29. Defining a Parameter
Parameters are variables that allow you to pass the actual value when the test case is setup for execution
A parameter can be embedded in both the Step Description and the Expected Result
A parameter is highlighted with <<< and >>> surrounding the variable
You can use the button interface to add the parameter or manually add the <<<‐>>> values to the step fields

30. Using Parameters

31. A Template Test is a test designed to be reused across multiple tests.
Template Tests
A Template Test is a test designed to be reused across multiple tests.
A Template Test can contain parameters.
It is normally called into a Test.
Only Manual Tests can be Template Tests.

32. Mark a Test as a Template Test
Marking a test as a Template Test ONLY, makes calling the test from other modules easier via a filter.
This does not affect the test case in any way. The test case can also be executed on its own like any other.

33. Calling a Template test that has Parameters
If you call a template test that contains parameters, you will be challenged with a table that contains a row for each parameter in the template test. Leaving them blank will ensure that the system will ask again for these values when you pull the test case into an execution test set.

34. Editing the Values of Called Parameters

35. More about Parameters
When parameters are used you will have multiple opportunities to provide the actual run time values
If you call a template test with parameters you will be challenged to populate the actual values when you make the call
When the test case is pulled into a test set for execution
When the tester starts execution
Parameter values can also be edited or updated after they have been populated

36. Calling a Template Test
A Template test can be created to establish a series of test steps that are repeated across many test cases.
You can call to this test from any other test and the steps of the template test will be inserted into the test steps at run time.
When you create your Template test you should update the ‘template flag’ to a ‘Y’ value to ease the ability to locate the test.

37. Viewing the Test Plan Tree
The Test Plan Tree also contains other icons representing different test types:

38. Exporting Test Cases from xcel
Why write Test Cases in Excel
Why write Test Cases in QC
o Direct access to
o Resources may not know
how to use QC
requirements linkage
o Can add attachments
Can call other test templates
Can specify parameter values
It is the test case designer’s choice as to where they design their test cases, with Excel or QC

39. Agenda
Test Planning Advanced Topics

40. Test Planning Advanced Topics
Test‐Requirement Relationship
Generating Automated Test Scripts
About Working with System Tests
About Managing Test Resources
About Viewing Dependencies
Viewing Dependencies
Generating a Live Analysis Graph