CS-6302 APPLICATION LIFECYCLE MGT

TEST PLANNING
Page |1

Module 006 TEST PLANNING

“Quality is never an accident; it is always the result of intelligent effort.”

– John Ruskin

Overview of the Course

Students learn how to manage quality information throughout the

development cycle, from constructing requirements, designing and executing tests,
through monitoring defects.

Students learn how to work with the Desktop client and the new Web client. In
addition, using the HP Sprinter and its new features are discussed, including:

 Using HP Sprinter on manual tests

 Using version control to keep track of changes and also to create and
manage libraries
 Creating and comparing baselines
 Importing and exporting from Microsoft Excel
 Generating reports and graphs using the dashboard
 Using cross-project customization and Project Planning and Tracking
(PPT)

Objectives:
After completing this module, you should be able to:

 Organize subjects and tests in a Test Plan tree

 Create tests that define the steps for testing an application

 Use parameters in tests

 Generate test scripts from design steps

 Define test configurations

 Generate a live analysis graph from a Test Plan tree

CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |2

Researching beyond the coverage of this module is highly encouraged to

supplement your understanding of the topics covered. Always, think and see
beyond the box.
The citation provided is a guideline. Please check each citation for accuracy
before use.

So, what are we waiting for? Let us now explore the Lifecycle
Management of Application

Introduction

The ALM Roadmap

The third stage of the testing process is test planning. After the
requirements are approved, the testing team designs tests that validate whether
the application meets these requirements. The efficiency of the test runs
depends on how you plan and execute these tests.

Test Planning Overview

Developing a clear and concise test plan is fundamental to successful

application testing. A good test plan enables you to assess the quality of your
application at any point in the application management process.
To outline a strategy for achieving your requirements, as defined in the
Requirements module, you must answer two basic questions:
How should you test your application?
 Which testing techniques will you use (stress tests, security tests,
performance and load tests, and so on)?
 How will you handle defects (severity classification, authorization to
open and close defects, and so on)?
What resources do you require?
 What resources do you require to test (personnel, hardware, and so on)?
 When will the various tasks be completed?
Example
Consider a flight reservation application that lets you manage flight
scheduling, passenger bookings, and ticket sales. For testing, you must design
both manual and automated tests. You could assign testing personnel with
programming experience the task of designing automated tests, while non-
programmers could design manual tests.
To develop a test plan, perform the following steps:
1. To develop a Test Plan tree:
a. Create subject folders in the Test Plan tree.
b. Define the specific tests within each subject folder.
2. Add manual steps for each test.
3. Build test scripts, as appropriate.
4. Link tests to requirements.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |3

Opening the Test Plan Module

The typical application is too large to test as a whole. The Test Plan
module enables you to divide your application according to functionality. You
divide your application into units, or subjects, by creating folders in a Test Plan
tree. This is a graphical representation of your test plan, displaying your tests
according to the hierarchical relationship of their functions.
You perform all test-planning tasks from the Test Plan module. To navigate to
this module, click the Test Plan icon under the Testing group from the ALM
sidebar.

The Test Plan Tree

The test plan is displayed in the left pane of the Test Plan module. The
Test Plan tree is a graphical representation of your project test plan. It contains
the Subject folder at the root level. You create folders in the Subject folder and
add tests to these folders.
The Test Plan tree:
 Organizes tests according to the functional units or subjects of an
application
 Provides a clear picture of the testing building blocks and assists in the
development of actual tests
 Shows the hierarchical relationships and dependencies between tests
When planning your Test Plan tree, consider the hierarchical relationships
of the functions in your application. Divide these functions into subjects and
build a Test Plan tree that represents the function of your application. The slide
above shows an example of a Test Plan tree for an online travel agency. The main
test subject Flight Reservation is displayed as a first-level folder. To break down
complex subjects, you use second-level folders or subjects as you see for Book
Flight, Flight Confirmation, Flight Cost, and Flight Finder.

Converting a Requirement to a Test

After you create the Requirements tree, the requirements are used as a
basis to define your test plan in the Test Plan module. ALM has a built-in wizard
that converts your project requirements to tests.
You convert requirements to tests to automatically create a one-to-one
mapping between requirements and tests. ALM replicates the hierarchy in the
Requirements tree in the Test Plan tree. In addition, during this conversion
process, ALM enables you to decide whether a particular requirement should be
converted to a folder, a test, or a design step.
Converting a requirement to a test has some limitations. For example,
while defining requirements, you list the objectives that the requirement must
meet. However, you do not specify the impact of a failing requirement on the
testing process. After you convert a requirement to a test, you must manually
specify the impact of a failing requirement on the testing process. In addition,
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |4

you must specify the pass and fail conditions for every test.
For example, the requirements for an application login process specify
valid values for the user name and password fields. You could convert these
requirements directly to tests, where the pass or fail condition for each test
would be based on the allowable values for each field. However, a failure of
either test would mean that the application user could not be authenticated,
resulting in a serious impact to the testing process.
Selecting an Automatic Method for Conversion
To convert requirements to tests, you select an automatic conversion
method that determines whether tests are converted to design steps, tests, or
test folders.
To select an automatic method for conversion, perform the following steps:
1. In the ALM sidebar, click the Requirements icon under the Requirements
group.
2. From the ALM menu bar, select View → Requirements Tree.
3. From the Requirements tree, select a requirement.
4. From the ALM menu bar, select Requirements →Convert To Tests. The
Choose An Automatic Conversion Method dialog box is displayed.
5. In the Choose An Automatic Conversion Method dialog box, under
Automatic Conversion Method, select a conversion method and click the
Next button. The Manual Changes To The Automatic Conversion dialog
box is displayed.

Making Changes to the Automatic Conversion

After you select an automatic method for conversion, you can customize the
conversion. For example, you select the Convert Lowest Child Requirements To
Design Steps automatic conversion method. During the conversion process, you
realize that some of the converted requirements should be represented as
folders in the Test Plan tree. ALM enables you to select a requirement and
convert it to a test plan folder. To make changes to the automatic conversion,
perform the following steps:
1. In the Manual Changes to the Automatic Conversion dialog box, from the
Name list, select a requirement.
2. From the toolbar, click one of the following buttons:
 Convert To Subject – Converts the selected requirement to a subject
folder
 Convert To Test – Converts the selected requirement to a test
 Convert To Step – Converts the selected requirement to a test step
 Convert To Description – Converts the selected requirement to a test
description
 Exclude From Conversion – Excludes the selected requirement from
the conversion process
3. Click the Next button. The Choose the Destination Subject Path dialog box
is displayed.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |5

Selecting the Destination Path

After you manually change the automatic test conversion, you select the
destination path for the newly created tests.
To select the destination path, perform the following steps:
1. In the Choose the Destination Subject Path dialog box, click the Browse
button in the Destination Subject Path field. The Select Destination
Subject dialog box is displayed.
2. In the Select Destination Subject dialog box, select a test plan folder and
click the OK button from the Test Plan tree.
3. Click Finish to close the Choose The Destination Subject Path dialog box.
The Information message box informs you that the conversion process
is successfully completed.
4. Click the OK button to close the Information message box.

Creating Test Subjects

To create the Test Plan tree in the Test Plan module, you manually create
folders and add tests to these folders. The Test Plan tree starts with the Subject
folder, which is available by default. From the Subject folder, you create main
subject folders and add subject subfolders within each main folder.
To add a folder, perform the following steps:
1. From the Test Plan tree, select the Subject folder to create a main subject
folder.
Note: You can select an existing main folder to create a subfolder.
2. On the ALM toolbar, click the New Folder button. The new test Folder
dialog box is displayed.
3. In the Test Folder Name field, type a name for the new test subject.
Note: A folder name cannot include any of the following characters: \, ^, or
*.
4. Click the OK button to add the folder to the Test Plan tree

Adding a Test

To add a test to the Test Plan tree, you define basic information about the
test, such as its name and type.
To add a test, perform the following steps:
1. From the Test Plan tree, select the subject folder in which you want to
add the new test.
2. On the ALM toolbar, click New Test. The New Test dialog box is
displayed.
3. From the Type list, select a type for the test.
4. In the Test Name field, type a name for the test.
Note: A test name cannot include any of the following characters: \, /, :,
“, ?, <, >,|,*,%, or‘.
5. Click the OK button to add the test to the Test Plan tree.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |6

Key Pointers for Defining Tests

After defining the subjects in the Test Plan tree, the next step is to add and
define the specific tests to be performed for each subject. You need to write tests
that define the set of inputs, events, actions, and expected outcomes to verify
that the application complies with a specific requirement. When you create
tests, you must ensure that the tests are:
 Accurate – Each test should have a distinct objective, such as verifying a
specific function or system requirement.
 Economical – A test must include only the necessary steps and fields that
are needed for its purpose.
 Consistent – Each iteration of the test must execute consistently.
 Appropriate – A test must be appropriate for its testers and its
environment.
 Traceable – A test must map to a requirement or a process.
To define a test, perform the following steps:
1. Add a test to the test plan tree.
2. Specify the details of the test.

Test Types

Populating the Details Tab

You use the Details tab to define the basic information about a test, such
as its status, creation date, and designer. In addition to the standard fields
provided, you use the Description field to provide a brief overview of the test.
For example, the slide above shows the Description field that contains a
statement about the test.
Note: You can provide additional information about a test by adding
attachments in its Attachments tab. This tab provides the same functionality as
the Attachments tab in the Requirements module.
Note: A test name preceded by an exclamation point in the Test Plan tree
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |7

indicates an alert for the test. A red exclamation means that the alert is new. A
gray exclamation means that the alert has been read. The site administrator can
define and activate alert rules that create alerts and send email when changes
occur in the project.

Design Test Steps

After defining manual tests, you specify the detailed steps to execute
each test. Adding a test step involves specifying the actions to perform on the
application, the input to enter, and the expected output.
To add and define a test step, perform the following steps:
1. From the test plan tree, select a test.
2. In the right pane, click the Design Steps tab.
3. On the Design Steps page toolbar, click the New Step button. The design
step Details dialog box is displayed.
4. In the Step Name field, type a name for the test step.
5. In the Description field, type the instructions for this step.
6. In the Expected Result field, type a description of the expected result for
this step. In addition, specify detailed instructions that testers can use to
verify the result.
7. Click the OK button. The test steps are displayed on the Design Steps
page. A footprint icon appears next to the test name in the Test Plan tree.
This icon indicates that the steps are defined for the test.
How to Design Test Steps
 Prerequisites – Tests, and basic test information, are defined in the Test
Plan tree.
 Create test steps – Describe the steps a tester must perform to run a test.
A test step includes the actions to perform on your application, the input
to enter, and the expected results.
 Call a template test (optional): – To include commonly used instructions
in your test, for example Log in to the application, you can call a template
test from within your test that includes common instructions.
 Generate an automated test (optional) – After you have created steps for
a manual test, you can generate a test script skeleton in which you can
write scripts to run the test as an automated test
 Results – The design steps that you add appear in the Design Steps tab.
The first time you add design steps to a test, a footprint icon is displayed
in the Test Plan tree next to the test icon, indicating that steps were
defined for the test.
Considerations for Designing Test Steps
When designing test steps, be sure to define all application operations to
completely test the application. To ensure that you clearly and accurately
capture all of the actions required to complete an operation:
 Write the test steps in active voice. When you use active voice, the person
executing the test gets clear instructions about how to perform the test
steps.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |8

 Use one action per step and clearly state whether the tester or the
application performs the action.
 Ensure that you do not leave out a step.
 Use consistent terminology throughout the test.
 Validate that the fields indicated in the test exist and are labeled the same
way as they are labeled in the system being tested.
 Specify the pass and fail conditions for the test.

Calling a Test

You can build test steps to include calls to other tests. This enables you
to modularize and reuse a standard sequence of steps across multiple tests. For
example, the slide above shows that the Define Savings Goal test contains a call
to another test, Calculate Goal.
To call another test as a step within a test, perform the following steps:
1. Click the Design Steps tab of the calling test.
2. On the Design Steps page toolbar, click the Call to Test button. The select
Test dialog box is displayed.
3. Select the test to call and click the OK button. This adds a step in the
current test and labels it as Call <Test_Name>. If you call a test that has
unassigned parameters, the Parameters of Test dialog box are displayed.
You now assign the parameters values.

Test Parameters

A parameter is a variable that can be assigned a value during test

execution. Parameters provide flexibility by enabling each calling test to
dynamically change its values. You use parameters to control test execution by
specifying data values at run time.
When working with a manual test, you can add parameters to the design
steps from within the test or you can add parameters by calling them from other
tests. This is useful if you have common steps you often want to perform as part
of other tests. When working with an automated test, you can define parameters
for a test script from within the test or you can load parameters from a shared
test resource file.
The slide above shows that Step 1 of the Login test uses a parameter for
Username. When another test needs to perform the Login function, it can call
the Login test and assign its own set of values to these parameters. The
parameters defined in the Login test are:
<<<Username>>>
<<<Password>>>
You can use parameters in the Description and Expected Result sections of a test
step.

Defining a Parameter

To define a parameter, perform the following steps:

CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
Page |9

1. From the Test Plan tree, select a test.

2. Click the Design Steps tab.
3. On the Design Steps page toolbar, click the New Step button. The Design
Step Details dialog box is displayed.
4. Place the cursor in the Description field or the Expected Result field of
the step in which you want to define the parameter.
5. Click the Insert Parameter button. The Parameters dialog box is
displayed. Click the New Parameter button. The New Test Parameter
dialog box is displayed.
6. In the Parameter Name field, type a name for the parameter and click the
OK button.
7. Click OK in the Parameters dialog box. The new parameter is added
within the step as <<<parameter_name>>>.
Note: A parameter name cannot include any of the following characters:
~ ,?, ‘, <, or >.
8. Click the OK button to close the Design Step Details dialog box.

Calling a Test with Parameters

When you call a test that contains parameters, you can set the values that
you want to pass to these parameters. The Define Savings Goal test in the slide
above calls the Calculate Goal test and passes specific values to the Calculate
Goal test.
To call a test and pass values to its parameters, perform the following steps:
1. From the Test Plan tree, select the calling test.
2. Click the Design Steps tab of the calling test.
3. Click the Call to Test button. The Select Test dialog box is displayed.
4. Select the test that you want to call.
Note: If you check the Show Only Template Tests checkbox, only
template tests are displayed in the Select Test dialog box. Template tests
are test designs that contain steps and parameters that are generally
reusable across different tests. However, it is not necessary to convert a
test to a template before you can call it from other tests.
5. Click the OK button. The Called Test Parameters dialog box is displayed.
6. Type the values that you want to pass to the parameters in the called test.
7. Click the OK button to add a new step that contains the call to the selected
test and the values that need to be passed to the test parameters.

Editing the Values of Called Parameters

You can edit the values that you assigned to parameters even after you
define a test call. For example, you can still edit the test step in the slide above
to change the values that it assigns to the parameters of the Calculate Goal test.
To edit the value of a called parameter, perform the following steps:
1. Right-click the calling step and click Called Test Parameters.... The called
Test parameters dialog box is displayed.
2. Click the Actual Value column of a parameter and type a new value.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
P a g e | 10

3. Click the OK button to update the test call to display the new value.

Creating Template Tests

You can copy and use any existing manual test as the basis for creating a
new manual test, but marking a manual test as a template test gives it special
designation. While a template test is no different from any other manual test in
composition or function, ALM can use the designation in dialog boxes which
have the Show Only Template Tests checkbox.
To configure a test as a template test, perform the following steps:
1. From the Test Plan tree, right-click a manual test.
2. Select mark as template test.
When you select the Show Only Template Tests checkbox in a dialog box,
manual tests without the template designation will be filtered from the list of
available tests.

Generating a Test Script

A test script contains the actions that must be performed during test
execution. To automate the test, you can generate an automated test script from
the manually defined test steps. Based on these test steps, ALM creates an
automated template test script for the automated testing tool of your choice.
Automating a test allows unattended execution of the test at high speed. It also
makes the test reusable and repeatable. For example, you automate functional,
benchmark, unit, stress, and load tests, as well as tests requiring detailed
information about applications.
To convert design steps into a test script, perform the following steps:
1. Click the Design Steps tab.
2. On the Design Steps page toolbar, click the Generate Script button. A
drop-down menu is displayed.
3. Select the automated testing tool that you want to use to record the
business process and complete the test.
4. When the script is generated, the Test Script tab is displayed with an
asterisk.
5. Click the Test Script tab to view the test script.
Note: After you generate the test script, the manual test icon in the Test
Plan tree is replaced with an icon corresponding to the automated test
that you selected. To open and modify the test script directly from the
testing tool for which it was created, click the Launch button on the Test
Script page.
Considerations for Test Automation
Frequency of Execution
Tests that will run with each new version of your application are good
candidates for automation. These include sanity tests that check basic
functionality across an entire application. Each time there is a new version of
the application, you run these tests to check the stability of the new version,
before proceeding to more in-depth testing.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
P a g e | 11

Tests that use multiple data values for the same operation (data-driven
tests) are also good candidates for automation. Running the same test
manually—each time with a different set of input data—can be tedious and
ineffective. By creating an automated data-driven test, you can run a single test
with multiple sets of data.
Stress/Load Testing
You should also automate tests that are run many times (stress tests) and
tests that check a multi-user client/server system (load tests). For example,
suppose a test must be repeated a thousand times. Running the test manually
would be extremely impractical. In this case, you can create a test that runs a
thousand iterations.
When Not to Automate Tests
Generally, the more user involvement a test requires, the less appropriate it
is to automate. The following describes test cases that should not be automated:
 Usability tests—tests providing usage models that check how easy the
application is to use
 Tests that you only have to run once
 Tests that you need to run immediately
 Tests based on user intuition and knowledge of the application
 Tests with no predictable results

Test Configurations

You can design tests that run according to different use-cases, each with
different sets of data. Each use-case is called a test configuration. Values for the
test configurations are supplied from within your ALM project or from an
external data resource.
The following is an overview of test configurations:
 A test configuration is a set of definitions that describe a specific test use-
case.
 You can associate different sets of data for each test configuration.
 Working with test configurations enables you to run the same test under
different scenarios.
 When creating a test, by default, ALM creates a single test configuration.
This test configuration is created with the same name as the test.
 Using the Test Configurations tab of the Test Plan module, you can create
as many additional test configurations as needed.
 You associate a test configuration with data defined in the Parameters
tab of the Test Plan module. You can associate different data with each
test configuration.

Defining Test Configurations

To define test configurations, perform the following steps:

1. In the Test Plan tree, select a test and click the Test Configuration tab.
2. Select the existing configuration and click the Test Configuration Details
button.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
P a g e | 12

3. In the Details tab, change the name to a configuration name and click the
OK button.
4. In the Data tab, enter the actual value for each parameter by clicking the
dropdown in the Actual Value column for each parameter name.
5. To create a new test configuration, click the New Test Configuration
button. The New Test Configuration dialog box is displayed.
6. Enter the name for the new test configuration and click the OK button.
7. In the Data tab, enter the actual value for each parameter by clicking the
dropdown in the Actual Value column for each parameter name.

Adding Configurations to Requirements Coverage

To add a test configuration to requirements coverage, perform the following

steps:
1. In the Test Plan module, select a test with multiple test configurations.
2. Click the Req Coverage tab.
3. Click the Select Req button. The Requirement tree is displayed at right.
4. Select the appropriate requirement and click the Add to Coverage button.
The Add Configuration Coverage dialog box is displayed.
5. To select specific configuration(s), select the configurations and click the
OK button. If you do not select any configuration, the requirement is
covered by all the configurations.
6. Click the OK button.

Generating a Live Analysis Graph from the Test Plan

You can generate a live analysis graph from the Test Plan module. A live
analysis graph provides a visual overview of all the tests within a folder in the
Test Plan tree. When you update a test in the test folder, the data change is
reflected in the graph. In addition, the layout and settings of the graph are
preserved when you select another test folder in the Test Plan module. This
feature enables you to view the same graphical analysis of different folders
without the need to recreate graphs.
To generate a live analysis graph, perform the following steps:
1. From the Test Plan tree, select a test subject folder.
2. Click the Live Analysis tab.
Note: The Live Analysis tab is divided into two panes, each of which can
display a graph.
3. Click the Add Graph link in the pane in which you want to display the
graph. The Graph Wizard: Step 1 Of 2 dialog box is displayed.
Note: If you already have two graphs displayed and want to create a new
graph, delete one of the existing graphs. To delete a graph, perform the
following steps:
a. Click the Remove Graph button located at the top of the graph you
want to delete.
b. Click the Yes button to confirm. The graph is deleted from the
selected pane and the Add Graph link is displayed.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
P a g e | 13

c. Click the Add Graph link. Under the graph type, select the type of
graph that you want to generate. You can generate the following
types of graphs:
 Summary – Displays the number of tests that are present in the
selected test subject folder.
 Progress – Displays the number of tests that are present in the
selected test subject folder at specific points during a period of
time.
 Trend – Displays the history of changes to specific fields in the
Test Plan module for a specified time interval.
4. Click the Next button.
5. The Graph Wizard: Step 2 of 2 dialog box is displayed. In the Group By
drop-down menu, select how you want the test to be grouped in the
graph and click the Next button.
6. In the X-Axis drop-down menu, select the field that you want to use for
the X-axis.
7. Click the Finish button. The graph is displayed in the panel that you
selected.

Modifying the Appearance of a Live Analysis Graph

After you generate a live analysis graph, you can modify the appearance of graph
according to your requirements. For example, you can change the field that you
want to use for the X-axis.
To modify the appearance of a live analysis graph, perform the following steps:
1. Within the pane in which the graph is located, click Set Graph
Appearance. The Graph Appearance dialog box is displayed. In the Graph
Appearance dialog box, the Titles tab is clicked by default, and the values
for the Graph Title, Y-Axis Title, and X-Axis Title fields are displayed. You
can modify these values. Click the Reset Titles button to get back the
original titles.
2. Click the Appearance tab. Use the General section to choose the Default
Layout, Legend Position, 3D Graph, and Vertical X-Axis Labels. Use the
Colors section to modify the color for legends.
3. Click the Bar Parameters tab to modify the position and style of marks
that appear on the graph.
4. Click the OK button to close the Graph Appearance dialog box.
CS-6302 APPLICATION LIFECYCLE MGT
TEST PLANNING
P a g e | 14

References and Supplementary Materials

Books and Journals

Micro. Customized Application Lifecycle Management 12.0 Essentials

Student Guide
Hewlett-Packard Development Company, L.P.
http://hp.com/software/education

Markov, Georgi and Druzhinina, Olga; 2011; Towards an industrial ALM

(Application Lifecycle) Tool Integration; Blekinge Institute of Technology,
School of Computing