TestDirector User`s Guide - Professional Development Resources

Transcription

TestDirector®
User’s Guide
Version 7.6
TestDirector User’s Guide, Version 7.6
This manual, and the accompanying software and other documentation, is protected by U.S. and international copyright laws, and may be used only in accordance with the accompanying license agreement. Features of the software, and of other products and services of Mercury Interactive
Corporation, may be covered by one or more of the following patents: U.S. Patent Nos. 5,701,139;
5,657,438; 5,511,185; 5,870,559; 5,958,008; 5,974,572; 6,138,157; 6,144,962; 6,205,122; 6,237,006;
6,341,310; and 6,360,332. Other patents are pending in the U.S. and other countries.
The Mercury Interactive logo, Astra, Astra QuickTest, Astra SiteManager, Astra SiteTest, Freshwater Software, Global SiteReliance, LoadRunner, Open Test Architecture, SiteRunner, Sitescope, SiteSeer,
TestDirector, TestRunner, TestSuite, WebTest, WinRunner and XRunner are registered trademarks in the United States and select foreign countries.
ActionTracker, ActiveScreen, ActiveTest, ActiveTune, ActiveTest SecureCheck, ActiveWatch, Astra FastTrack, Astra LoadTest, Change Viewer, Conduct, ContentCheck, Dynamic Scanner, FastTrack,
LinkDoctor, LoadRunner TestCenter, Mercury Interactive, POPS on Demand, ProTune, QuickTest,
SiteReliance, TestCenter, Topaz, Topaz ActiveAgent, Topaz AIMS, Topaz Console, Topaz Delta, Topaz Diagnostics, Topaz Observer, Topaz Open DataSource, Topaz Prism, Topaz Rent-a-POP, Topaz
Weathermap, Turboload, Twinlook, Visual Testing, Visual Web Display and WebTrace are trademarks
of Mercury Interactive in the United States and/or select foreign countries.
All other company, brand and product names are registered trademarks or trademarks of their respective holders. Mercury Interactive Corporation disclaims any responsibility for specifying which marks are owned by which companies or which organizations.
Mercury Interactive Corporation
1325 Borregas Avenue
Sunnyvale, CA 94089 USA
Tel: (408) 822-5200
Toll Free: (800) TEST-911, (866) TOPAZ-4U
Fax: (408) 822-5300
© 1994 - 2002 Mercury Interactive Corporation, All rights reserved
If you have any comments or suggestions regarding this document, please send them via e-mail to
[email protected].
TDUG7.6/02
Table of Contents
Welcome to TestDirector .....................................................................ix
Using This Guide ..................................................................................ix
TestDirector Documentation Set...........................................................x
Online Resources ..................................................................................xi
Typographical Conventions............................................................... xii
P A R T I : T E ST D I R EC T O R B A S IC S
Chapter 1: Introduction ........................................................................3
The Test Management Process ..............................................................4
Specifying Requirements ......................................................................5
Planning Tests ......................................................................................6
Running Tests .......................................................................................8
Tracking Defects ...................................................................................9
Working with Project Databases ........................................................10
User Privileges .....................................................................................11
Exporting Documents from Microsoft Word .....................................11
Exporting Documents from Microsoft Excel .....................................12
Chapter 2: Getting Started .................................................................13
Starting TestDirector............................................................................13
The TestDirector Window ...................................................................16
The TestDirector Toolbar ....................................................................18
Changing Passwords ...........................................................................19
Changing User Properties ...................................................................20
Clearing History .................................................................................21
Chapter 3: Working with TestDirector Data.......................................23
About Working with TestDirector Data ..............................................23
Arranging Columns ............................................................................25
Filtering Records .................................................................................27
Sorting Records ...................................................................................36
Refreshing and Clearing Settings .......................................................38
Saving Data to a File ...........................................................................38
iii
TestDirector User’s Guide
Chapter 4: Adding Attachments ........................................................39
About Adding Attachments ................................................................39
Attaching a File ...................................................................................42
Attaching a URL .................................................................................42
Attaching a Snapshot .........................................................................43
Attaching System Properties ...............................................................44
Attaching an Image from the Clipboard ............................................45
Managing Attachments ......................................................................45
Chapter 5: Working with Favorite Views ............................................47
About Working with Favorite Views ...................................................47
Adding Favorite Views ........................................................................48
Organizing Favorite Views .................................................................49
P A RT I I : R EQ U I R EM E N T S S P EC I F IC A T I O N
Chapter 6: The Requirements Specification Workflow ......................53
Defining the Testing Scope .................................................................54
Creating the Testing Requirements Outline .......................................55
Defining Requirements .......................................................................56
Analyzing your Requirements Specification .......................................56
Chapter 7: The Requirements Module at a Glance ............................57
The Requirements Module ..................................................................57
The Requirements Menu Bar ..............................................................59
The Requirements Toolbar .................................................................60
The Requirements Tree .......................................................................62
Chapter 8: Developing the Requirements Tree..................................65
About the Requirements Tree ............................................................65
Creating a Requirements Tree ............................................................66
Finding Requirements in the Tree ......................................................68
Viewing the Requirements Tree ..........................................................69
Viewing Requirement History ............................................................71
Mailing Requirements ........................................................................72
Viewing Associated Defects ................................................................74
Modifying the Requirements Tree ......................................................76
Creating Tests from Requirements .....................................................79
iv
Table of Contents
P A R T I I I : T ES T P L A N N I N G
Chapter 9: The Test Plan Workflow ....................................................87
Defining Testing Strategy ....................................................................88
Defining Test Subjects .........................................................................88
Planning Tests .....................................................................................89
Creating Requirements Coverage........................................................89
Designing Test Steps............................................................................90
Automating Tests.................................................................................90
Analyzing Your Test Plan ....................................................................91
Chapter 10: The Test Plan Module at a Glance ..................................93
The Test Plan Module..........................................................................93
The Test Plan Menu Bar .....................................................................95
The Test Plan Toolbar .........................................................................95
The Test Grid ......................................................................................96
Chapter 11: Developing the Test Plan Tree......................................101
About the Test Plan Tree ...................................................................101
Creating a Test Plan Tree ..................................................................103
Adding Tests to a Test Plan Tree ......................................................104
Viewing the Test Plan Tree................................................................108
Associating Defects with a Test ........................................................110
Mailing Tests .....................................................................................111
Finding Tests in the Tree ..................................................................114
Sorting a Test Plan Tree ....................................................................115
Modifying a Test Plan Tree................................................................117
Chapter 12: Linking Tests to Requirements......................................119
About Linking Tests to Requirements ..............................................119
Linking Requirements to a Test .......................................................122
Linking Tests to a Requirement .......................................................125
Linking Requirements and Tests Coverage .......................................128
Chapter 13: Building Tests ................................................................129
About Building Tests .........................................................................129
Designing Test Steps .........................................................................130
Calling a Manual Test with Parameters ...........................................132
Managing Test Steps..........................................................................136
Chapter 14: Creating Automated Tests ............................................141
About Creating Automated Tests .....................................................141
Generating Automated Test Templates.............................................143
v
Chapter 15: Working with System Tests .........................................145
About Working with System Tests ....................................................145
Adding System Tests to a Test Plan Tree ...........................................146
Defining a System Test ......................................................................147
Running a System Test ......................................................................148
Viewing System Test Results .............................................................149
PA RT I V: T E S T E X EC U T I O N
Chapter 16: The Test Lab Workflow .................................................153
Creating Test Sets ..............................................................................154
Scheduling Test Runs ........................................................................154
Running Tests Manually ...................................................................154
Running Tests Automatically ............................................................155
Analyzing Test Results.......................................................................155
Chapter 17: The Test Lab Module at a Glance .................................157
The Test Lab Module ........................................................................158
The Test Lab Menu Bar .....................................................................159
The Test Lab Toolbars........................................................................160
The Execution Grid ..........................................................................161
The Execution Flow ..........................................................................164
Chapter 18: Creating Test Sets .........................................................169
About Creating Test Sets ...................................................................169
Adding a Test Set ..............................................................................171
Adding Tests to a Test Set .................................................................173
Setting the Test Set Notifications .....................................................175
Setting the Test Set On Failure Rules ...............................................177
Managing Test Sets ...........................................................................179
Chapter 19: Scheduling Test Runs ....................................................185
About Scheduling Test Runs ............................................................185
Scheduling a Test Run ......................................................................188
Modifying a Test Run Schedule.........................................................191
Arranging Tests Sequentially ............................................................193
Finding Tests ....................................................................................194
Viewing the Execution Flow Diagram ..............................................195
Chapter 20: Running Tests Manually................................................197
About Running Tests Manually.........................................................197
Running a Test Manually .................................................................198
Editing the Test Steps .......................................................................203
Resuming a Manual Test Run ...........................................................203
vi
Table of Contents
Chapter 21: Running Tests Automatically .......................................205
About Running Tests Automatically .................................................205
Running a Test Automatically...........................................................206
Viewing the Execution Log ..............................................................210
Setting Up Hosts for Remote Test Execution ...................................212
Ordering Tests in the Execution Grid ..............................................216
Finding and Replacing Values in the Execution Grid ......................217
Chapter 22: Viewing Test Results .....................................................219
About Viewing Test Results ...............................................................219
Viewing Details of a Test Run ..........................................................221
Viewing Attachments to a Test Run .................................................223
Comparing Results of All Runs .........................................................223
Viewing Configuration of a Test Run ..............................................225
Viewing Test Run Events ..................................................................228
Viewing Test Run History .................................................................229
P A R T V : DE F EC T TR A CK IN G
Chapter 23: The Defect Tracking Workflow .....................................233
Adding Defects ..................................................................................234
Reviewing New Defects .....................................................................234
Repairing Open Defects.....................................................................234
Testing a New Application Build.......................................................235
Analyzing Defect Data.......................................................................235
Chapter 24: The Defects Module at a Glance...................................237
The Defects Module ..........................................................................237
The Defects Menu Bar ......................................................................239
The Defects Toolbar ..........................................................................239
The Defects Grid ...............................................................................241
Chapter 25: Adding and Tracking Defects .......................................243
About Adding and Tracking Defects .................................................243
Adding New Defects .........................................................................244
Matching Defects ..............................................................................247
Updating Defects ...............................................................................250
Finding and Replacing Values ..........................................................252
Viewing Defect History ....................................................................254
Mailing Defects .................................................................................255
Viewing an Associated Test ..............................................................257
Deleting Defects ................................................................................259
vii
PA RT VI : T E S T DI R E C T O R A N A LY SI S
Chapter 26: Generating Reports ......................................................263
About Generating Reports.................................................................263
Available Reports ...............................................................................264
Creating Reports ...............................................................................271
Customizing Reports .........................................................................272
Adding Sub-Reports ...........................................................................275
Deleting Sub-Reports .........................................................................276
Chapter 27: Generating Graphs........................................................277
About Generating Graphs .................................................................277
TestDirector Graph Types..................................................................278
Creating Graphs ................................................................................297
Customizing Graph Content ............................................................299
Customizing the Graph’s Appearance .............................................305
Customizing the Graph Description ................................................306
Chapter 28: Generating Project Documents ....................................307
About Using the Document Generator ............................................308
Launching the Document Generator ...............................................310
Setting Formatting Instructions .......................................................311
Specifying Project Data ....................................................................315
Generating a Project Document .......................................................332
P A RT V I I : A P P E N D I X Appendix A: Working with VAPI-XP .................................................335
About Working with VAPI-XP .........................................................336
Creating VAPI-XP Test Scripts ..........................................................336
Editing VAPI-XP Test Scripts ............................................................345
Using the VAPI-XP API .....................................................................350
Running VAPI-XP Tests in Debug Mode ..........................................354
Running VAPI-XP Tests in Test Mode ..............................................355
Debugging VAPI-XP Test Scripts ......................................................357
Index..................................................................................................361
viii
Welcome to TestDirector
Welcome to TestDirector, Mercury Interactive’s Web-based test management
tool. TestDirector helps you organize and manage all phases of the
application testing process, including specifying testing requirements,
planning tests, executing tests, and tracking defects.
Using This Guide
This guide describes how to use TestDirector to manage the application
testing process for your application.
It contains seven parts:
Part I
TestDirector Basics
Provides an overview of TestDirector’s features and methodology.
Part II
Requirements Specification
Describes how to define testing requirements by building a requirements
tree.
Part III
Test Planning
Describes how to plan the testing process, from building a test plan tree to
creating tests.
Part IV
Test Execution
Describes how to create test sets, execute manual and automated tests, and
review test results.
ix
Part V
Defect Tracking
Describes how to report application defects to a TestDirector project and
keep track of the repair process until the defects are resolved.
Part VI
TestDirector Analysis
Describes how you can monitor the testing and defect tracking process by
creating reports, graphs, and project documentation.
Part VII Appendix
Describes how to work with the VAPI-XP testing tool.
TestDirector Documentation Set
In addition to this guide, TestDirector comes with the following printed
documentation:
TestDirector Installation Guide explains how to install TestDirector and the
client database software needed to connect TestDirector to project databases.
TestDirector Tutorial is a self-paced guide teaching you how to use
TestDirector to manage the software testing process.
TestDirector Administrator’s Guide explains how to customize projects
using the Project Customization window and how to create and maintain
projects using the Project Administration utility.
TestDirector Open Test Architecture Guide explains how to use
TestDirector’s open test architecture to integrate your own configuration
management, defect tracking, and home-grown testing tools with a
TestDirector project. It includes a complete reference to TestDirector’s new
COM-based API.
x
Welcome to TestDirector
Online Resources
TestDirector includes the following online resources:
Read Me First provides last-minute news and information about
TestDirector.
What’s New in TestDirector describes the newest features in the latest
versions of TestDirector.
Books Online displays the complete documentation set in .PDF format.
Online books can be read and printed using Adobe Acrobat Reader 5.0
which can be downloaded from the Adobe Web site
(http://www.adobe.com/products/acrobat/readstep2.html).
TestDirector Online Help provides immediate answers to questions that arise
as you work with TestDirector. It describes menu commands and dialog
boxes, and shows you how to perform TestDirector tasks. Check Mercury
Interactive’s Customer Support Web site
(http://support.mercuryinteractive.com) for updates to TestDirector help files.
Technical Support Online uses your default Web browser to open Mercury
Interactive’s Customer Support Web site. The URL for this Web site is
http://support.mercuryinteractive.com. This site enables you to browse the
knowledge base and add your own articles, post to and search user
discussion forums, submit support requests, download patches and updated
documentation, and more.
Support Information presents Mercury Interactive’s Customer Support Web
site and home page, the e-mail address for requesting information, and a list
of Mercury Interactive’s offices around the world.
Mercury Interactive on the Web uses your default Web browser to open
Mercury Interactive’s home page. This site provides the most up-to-date
information on Mercury Interactive and its products. This includes new
software releases, seminars and trade shows, customer support, educational
services, and more. The URL for this Web site is
http://www.mercuryinteractive.com.
xi
Typographical Conventions
This book uses the following typographical conventions:
xii
1, 2, 3
Bold numbers indicate steps in a procedure.
➤
Bullets indicate options and features.
>
The greater than sign separates menu levels (for
example, File > Open).
Stone Sans
The Stone Sans font indicates names of interface
elements in a procedure that you perform actions
upon (for example, “Click the Run button.”).
Bold
Bold text indicates function names.
Italics
Italic text indicates variable names, or introduces a
new term.
Helvetica
The Helvetica font is used for examples and statements
that are to be typed in literally.
<>
Angle brackets enclose a part of a URL address that
needs to be typed in.
...
In a line of syntax, an ellipsis indicates that more items
of the same format may be included.
Part I
TestDirector Basics
2
1
Introduction
Welcome to TestDirector, Mercury Interactive’s Web-based test management
tool. You access TestDirector over the Internet or a corporate intranet, via a
Web browser.
Application testing is a complex process involving the development and
execution of thousands of tests. Often, tests are required for multiple
hardware platforms, multiple configurations (computers, operating systems,
and browsers) and multiple application versions. Managing all aspects of the
testing process can be time-consuming and difficult.
TestDirector simplifies and organizes test management by giving you
systematic control over the testing process. It helps you create a framework
and foundation for your testing workflow.
TestDirector helps you maintain a project database of tests that cover all
aspects of your application’s functionality. Every test in your project is
designed to fulfill a specified testing requirement of your application. To
meet the various goals of a project, you organize the tests in your project
into unique groups. TestDirector provides an intuitive and efficient method
for scheduling and executing test sets, collecting test results, and analyzing
the data.
TestDirector also features a sophisticated system for tracking application
defects, enabling you to monitor defects closely from initial detection until
resolution. By linking TestDirector to your e-mail system, defect tracking
information can be shared by all application development, quality
assurance, customer support, and information systems personnel.
TestDirector offers integration with Mercury Interactive testing tools
(WinRunner, LoadRunner, QuickTest Professional, Astra QuickTest,
QuickTest Professional for MySAP.com Windows Client, Astra LoadTest,
3
TestDirector User’s Guide • TestDirector Basics
XRunner, Visual API, and Visual API-XP) as well as with third-party and
custom testing tools, requirement and configuration management tools,
and modeling applications. TestDirector’s ability to communicate seamlessly
with the testing tool of your choice provides you with a complete solution
to fully automated application testing.
TestDirector guides you through the requirements specification, test
planning, test execution, and defect tracking phases of the testing process.
By integrating all the tasks involved in application testing, it helps ensure
that your customers receive the highest quality applications.
The Test Management Process
Test management with TestDirector involves four phases:
Specify
Requirements
Plan Tests
Execute Tests
Track Defects
Specify Requirements: Analyze your application and determine your
testing requirements.
Plan Tests: Create a test plan, based on your testing requirements.
Execute Tests: Create test sets and perform test runs.
4
Chapter 1 • Introduction
Track Defects: Report defects detected in your application and track how
repairs are progressing.
Throughout each phase, you can analyze data by generating detailed reports
and graphs.
Specifying Requirements
Analyze your application and determine your testing requirements.
Define Testing
Scope
Create
Requirements
Detail
Requirements
Analyze
Requirements
Define Testing Scope: Examine application documentation in order to
determine your testing scope—test goals, objectives, and strategies.
Create Requirements: Build a requirements tree to define your overall testing
requirements.
Detail Requirements: For each requirement topic in the requirements tree,
create a list of detailed testing requirements. Describe each requirement,
assign it a priority level, and add attachments if necessary.
5
Analyze Requirements Specification: Generate reports and graphs to assist
in analyzing your testing requirements. Review your requirements to ensure
they meet your testing scope.
Planning Tests
Create a test plan, based on your testing requirements.
Define
Testing
Strategy
Define Test
Subjects
Define Tests
Create
Requirements
Coverage
Design Test
Steps
Automate
Tests
Analyze Test
Plan
6
Define Testing Strategy: Examine your application, system environment,
and testing resources in order to determine your testing goals.
Define Test Subjects: Divide your application into modules or functions to
be tested. Build a test plan tree to hierarchically divide your application into
testing units, or subjects.
Define Tests: Determine the types of tests you need for each module. Add a
basic definition of each test to the test plan tree.
Create Requirements Coverage: Link each test with a testing
requirement(s).
Design Test Steps: Develop manual tests by adding steps to the tests in your
test plan tree. Test steps describe the test operations, the points to check, and
the expected outcome of each test. Decide which tests to automate.
Automate Tests: For tests that you decide to automate, create test scripts
with a Mercury Interactive testing tool, or a custom or third-party testing
tool.
Analyze Test Plan: Generate reports and graphs to assist in analyzing test
planning data. Review your tests to determine their suitability to your
testing goals.
7
Running Tests
Create test sets and perform test runs.
Create Test Sets
Schedule Runs
Run Tests
Automatically
Run Tests
Manually
Analyze Test
Results
Create Test Sets: Define groups of tests to meet the various testing goals in
your project. These might include, for example, testing a new application
version or a specific function in an application. Determine which tests to
include in each test set.
Schedule Runs: Schedule test execution and assign tasks to application
testers.
Run Tests: Execute the tests in your test set automatically or manually.
Analyze Test Results: View the results of your test runs in order to
determine whether a defect has been detected in your application. Generate
reports and graphs to help analyze these results.
8
Tracking Defects
Report defects detected in your application and track how repairs are
progressing.
Add Defects
Review New
Defects
Repair Open
Defects
Test New
Build
Analyze
Defect Data
Add Defects: Report new defects detected in your application. Quality
assurance testers, developers, project managers, and end users can add
defects during any phase in the testing process.
Review New Defects: Review new defects and determine which ones should
be fixed.
Repair Open Defects: Correct the defects that you decided to fix.
Test New Build: Test a new build of your application. Continue this process
until defects are repaired.
9
Analyze Defect Data: Generate reports and graphs to assist in analyzing the
progress of defect repairs, and to help determine when to release the
application.
Working with Project Databases
When you create a TestDirector project, you need to store and manage the
data generated and collected by TestDirector. Each project is supported by a
database that stores project information.
TestDirector projects are repositories that contain requirements, tests, test
sets, test runs, defects, project documentation, and customization
information. A TestDirector user needs constant access to this data in order
to be able to work on a application testing project.
Use the following database applications to store and manage TestDirector
information:
➤ Microsoft Access
➤ Sybase (TestDirector Enterprise Edition only)
➤ Microsoft SQL (TestDirector Enterprise Edition only)
➤ Oracle (TestDirector Enterprise Edition only)
For more information on creating and managing TestDirector projects, refer
to the TestDirector Administrator’s Guide.
10
User Privileges
TestDirector enables you to manage user access to a project. By creating a list
of authorized users and assigning each user a password and user group, you
control the kinds of additions and modifications each user makes to the
project. The user group determines the privileges that the user has within
TestDirector. TestDirector includes a privileges and permissions mechanism
that enables you to create rules for specific fields in a project.
For detailed information on the user groups available in TestDirector, and
on assigning passwords and privileges, refer to the TestDirector
Administrator’s Guide.
Exporting Documents from Microsoft Word
You can export existing test documents or requirements in Microsoft Word
directly to the requirements tree or test plan tree. To use the Microsoft Word
export feature, you must first download the Microsoft Word add-in.
To download the Microsoft Word add-in:
1 From the TestDirector Options window, click the Add-ins Page link. The
TestDirector Add-ins page opens.
2 Click the More TestDirector Add-ins link. The More TestDirector Add-ins
page opens.
3 Under Microsoft Add-ins, click the Microsoft Word link. The Microsoft
Word Add-in page opens.
4 Click the Microsoft Word Add-in User’s Guide link for instructions on using
the Microsoft Word add-in.
5 Click the Download Add-in link to begin installing the Microsoft Word addin.
For more information on the TestDirector Add-ins page, refer to the
TestDirector Installation Guide.
11
Exporting Documents from Microsoft Excel
You can export existing test documents, requirements, or defects in
Microsoft Excel to your TestDirector project. To use the Microsoft Excel
export feature, you must first download the Microsoft Excel add-in.
To download the Microsoft Excel add-in:
1 From the TestDirector Options window, click the Add-ins Page link. The
TestDirector Add-ins page opens.
2 Click the More TestDirector Add-ins link. The More TestDirector Add-ins
page opens.
3 Under Microsoft Add-ins, click the Microsoft Excel link. The Microsoft Excel
Add-in page opens.
4 Click the Microsoft Excel Add-in User’s Guide link for instructions on using
the Microsoft Excel add-in.
5 Click the Download Add-in link to begin installing the Microsoft Excel addin.
For more information on the TestDirector Add-ins page, refer to the
12
2
Getting Started
This chapter introduces TestDirector and explains how to begin.
This chapter describes:
➤ Starting TestDirector
➤ The TestDirector Window
➤ The TestDirector Toolbar
➤ Changing Passwords
➤ Changing User Properties
➤ Clearing History
Starting TestDirector
You can launch TestDirector on your workstation from your Web browser.
To start TestDirector:
1 Open your Web browser and type your TestDirector URL
(http://[Server name]/[virtual Directory name]/default.htm). Contact your
system administrator if you do not have the correct path.
13
The TestDirector Options window opens.
Note: If you cannot start TestDirector, contact your system administrator to
ensure that TestDirector has been installed on your company Web server.
For more information, refer to the TestDirector Installation Guide.
2 Click the TestDirector link.
The first time you run TestDirector, the software is downloaded to your
computer. Subsequently, TestDirector automatically carries out a version
check. If it detects a newer version, it downloads it to your machine.
Note: For information on the components that are downloaded to your
computer when you run TestDirector, refer to the TestDirector Installation
Guide.
14
Chapter 2 • Getting Started
Once the TestDirector version has been checked and updated if necessary,
the TestDirector Login window opens.
3 In the Domain list, select a domain.
You can select the default domain called DEFAULT. If you are not sure which
domain to select, contact your TestDirector administrator.
Note: The DEFAULT domain is the only available domain in the TestDirector
Standard Edition.
4 In the Project list, select a project. If the project list is empty, refer to the
TestDirector knowledge base (http://support.mercuryinteractive.com) and
search using the keyword "empty project list".
If the TestDirector demonstration project was installed on the TestDirector
server, you can select the TestDirector_Demo project (make sure that you
select DEFAULT in the Domain list). The project helps introduce you to
TestDirector and includes sample requirements, tests, test sets, test runs, and
defects. For more information, refer to the TestDirector Tutorial.
15
5 In the User ID box, type or select your user name. If you do not know your
user name, contact your system administrator. Note that the User ID list is
client machine-dependent, so you need to type your user name the first
time you log in to TestDirector.
6 In the Password box, type in the password assigned to you by your system
administrator. (If you are the first person to log in as admin, you do not
need a password the first time you log in.)
To change your assigned password, see “Changing Passwords,” on page 19.
7 Click the Login button. TestDirector opens and displays the module
(Requirements, Test Plan, Test Lab, and Defects) in which you last worked
during your previous TestDirector session. To customize the module names,
see the TestDirector Installation Guide.
8 To exit and return to the TestDirector Login window, click the Logout
button located on the upper-right side of the window.
The TestDirector Window
When you open a project, the TestDirector main window opens and displays
the module in which you were last working. In the title bar, TestDirector
displays the project name and your user name.
Project name
User name
TestDirector has four modules:
➤ Requirements: Specify testing requirements. This includes defining what
you are testing, defining requirement topics and items, and analyzing the
requirements.
➤ Test Plan: Develop a test plan. This includes defining goals and strategy,
dividing your plan into categories, developing tests, automating tests where
beneficial, linking tests with requirements, and analyzing the plan.
➤ Test Lab: Run tests on your application and analyze the results.
16
➤ Defects: Add defects, determine repair priorities, repair open defects, and
analyze the data.
Tip: You can navigate between the modules using shortcut keys. Use
Ctrl+Shift+1 to access the Requirements module, Ctrl+Shift+2 to access the
Test Plan module, etc.
All the TestDirector modules have the following elements:
➤ The TestDirector toolbar, located directly above the TestDirector project
name. If the toolbar is not visible, click the Show Toolbar button. For more
information on the TestDirector toolbar, see “The TestDirector Toolbar,” on
page 18.
➤ The menu bar, located directly below the TestDirector project name, displays
the names of menus from which you select commands.
➤ The module toolbar, located below the menu bar, contains buttons for
frequently-used commands in the current TestDirector module.
➤ A Tools button, located on the upper-right side of the window, enabling you
to change your user password and other user properties, change the
language direction for a user in a project from left to right or right to left,
clear the history data, view version information for each TestDirector client
component, and open the Document Generator. For more information on
the Document Generator, see Chapter 28, “Generating Project Documents.”
To customize the Tools menu, see the TestDirector Installation Guide.
➤ A Help button, located on the upper-right side of the window, enabling you
to access TestDirector online resources. To customize the Help menu, see the
17
The TestDirector Toolbar
The common TestDirector toolbar is accessible from all TestDirector
modules and contains the following buttons:
Navigation Buttons
Back: Navigates back to your previous location in TestDirector.
Forward: If you have navigated back, enables you to navigate forward.
Home: Logs out and takes you to the TestDirector Login window.
Spelling Buttons
Check Spelling: Checks the spelling for the selected word or text box. If
there are no errors, a confirmation message opens. If errors are found, the
Spelling dialog box opens and displays the word together with replacement
suggestions.
Spelling Options: Opens the Spelling Options dialog box, enabling you to
configure the way TestDirector checks spelling.
Thesaurus: Opens the Thesaurus dialog box and displays a synonym,
antonym, or related word for the selected word. You can replace the selected
word or look up new words.
Defect Button
Add Defect: Opens the Add Defect dialog box, enabling you to add a new
defect. For more information, see Chapter 25, “Adding and Tracking
Defects.”
Help Button
Help: Opens the Online Help and displays the help topic for the current
context.
18
Changing Passwords
You can change your password for accessing a TestDirector project.
Note: The administrator can change and override a user’s password. For
more information, refer to the TestDirector Administrator’s Guide.
To change a password:
1 On the upper-right side of the window, click the Tools button and choose
Change Password. Alternatively, click the Change Password link in the
Project Customization window. The Change Password for [user] dialog box
opens.
2 In the Old Password box, type your old password.
3 In the New Password box, type the new password.
4 In the Retype New Password box, retype the new password.
5 Click OK to close the Change Password dialog box.
19
Changing User Properties
You can change your user properties, including full name, e-mail address,
phone number, and description. Note that the e-mail information is
important because it enables you to receive defects, requirements, and test
set notifications directly to your mailbox.
Note: The administrator can change and override a user’s properties. For
To change user properties:
Change User Properties. Alternatively, click the Change User Properties link
in the Project Customization window. The Properties of [user] dialog box
opens.
2 Edit the following user properties: Full Name, EMail, Phone, Description.
3 Click OK to save your changes.
20
Clearing History
When you customize your TestDirector project, you can instruct
TestDirector to preserve a log of values for the system and user fields in your
Requirement, Test, and Defect entities. The history data that is generated is
displayed in the History tabs of the Requirements, Test Plan, and Defects
modules. For more information on setting history for a TestDirector field,
refer to the TestDirector Administrator’s Guide.
Once you no longer want to store history data, TestDirector allows you to
delete this data from your TestDirector project. For example, if you have
successfully run the test sets you created, you may want to clear the test
history from your TestDirector project.
You can choose to clear all history data, or you can select a specific entity or
field whose history you want to clear. In addition, you can instruct
TestDirector to delete history data up to and including a specific date.
TestDirector clears the data displayed in the History tab of the
corresponding module(s).
Note: By default, only a user with TestDirector administrator permissions
can clear history. User permissions can be customized. For more information
on permissions, refer to the TestDirector Administrator’s Guide.
To clear history:
Clear History. The Clear History dialog box opens.
21
2 In the Entity box, select the entity whose history you want to delete. To
delete history data for the Requirement, Test, and Defect entities, select All.
3 In the Field box, select the field whose history you want to delete. To delete
history data from all fields, select All.
4 In the Until Date box, select a date. TestDirector deletes data up to and
including the date selected.
5 Click OK.
22
3
Working with TestDirector Data
You can view and modify the data in your project using TestDirector grids
and trees.
➤ Arranging Columns
➤ Filtering Records
➤ Advanced/Cross Filtering Records
➤ Sorting Records
➤ Refreshing and Clearing Settings
➤ Saving Data to a File
About Working with TestDirector Data
TestDirector organizes and displays data in grids or trees:
Tree/Grid
Description
Requirements Tree
Available in the Requirements module. Displays the
testing requirements for a TestDirector project. For more
information, see Chapter 8, “Developing the
Requirements Tree.”
Test Plan Tree
Available in the Test Plan module. Displays the tests in a
TestDirector project, grouped by subjects. For more
information, see Chapter 11, “Developing the Test Plan
Tree.”
23
Tree/Grid
Description
Test Grid
Available in the Test Plan module by choosing
View > Test Grid. Displays all the tests in a TestDirector
project. For more information, see Chapter 10, “The Test
Plan Module at a Glance.”
Design Steps Grid
Available in the Test Plan module. Displays the steps of a
test. For more information, see “Building Tests,” on
page 129.
Test Sets Tree
Available in the Test Lab module. Displays the test sets—a
group of tests that you run in order to achieve a specific
testing goal— in a TestDirector project. For more
information, see Chapter 18, “Creating Test Sets.”
Execution Grid
Available in the Test Lab module. Displays all the tests in a
test set. For more information, see Chapter 17, “The Test
Lab Module at a Glance.”
Defects Grid
Available in the Defects module. Displays the defects in a
TestDirector project. For more information, see
Chapter 25, “Adding and Tracking Defects.”
When working with TestDirector grids and trees, you can arrange columns,
filter records according to conditions, set sorting priorities, refresh and clear
filter and sort settings, and save data to a file. Note that as TestDirector grids
and trees vary in the type of content they display, the activities described in
this chapter do not always apply to all grids and trees.
Note: You can save your grid settings, such as sorting and filters, as a favorite
view. For more information, see Chapter 5, “Working with Favorite Views.”
24
Chapter 3 • Working with TestDirector Data
Arranging Columns
You can customize data by specifying the order in which columns appear,
and by changing column size. Your column settings will continue to appear
the next time you open the project.
Setting Column Order
You determine which columns appear in TestDirector and the order in
which they appear using the Select Columns dialog box. For example, you
can set Subject as the first column in the Test Grid.
To determine column appearance and order:
1 Click the Select Columns button. The Select Columns dialog box opens.
Available Columns lists columns not currently displayed. Visible Columns lists
columns currently displayed.
2 Choose column names and click the arrow buttons (> and <) to move them
between Available Columns and Visible Columns. Click the double arrow
buttons (>> and <<) to move all the columns from one list to the other. Note
that you can also drag the column names between lists.
25
3 In Visible Columns, set the order in which columns appear by using the Up
and Down arrows. Note that you can also drag the column names up or
down.
4 To set non-scrolling columns, specify the number of non-scrolling columns
you want to set in Fixed Columns. Starting from the leftmost column, the
number of columns you specify will be set as non-scrolling. Non-scrolling
columns remain stationary when you scroll horizontally. These columns are
shaded. (Note that this option is not available in the Requirements module.)
5 Click OK to close the dialog box and apply the new column order.
Tip: You can also rearrange columns by placing the mouse pointer in the
column heading and holding down the left mouse button. Drag the column
to its new location and release the button.
Resizing Columns
You can resize columns using the mouse. Click on the right edge of a
column heading and drag to adjust the width. Note that you can only resize
columns that are not fixed (non-scrolling).
26
Filtering Records
You can filter TestDirector data to display only those records meeting the
criteria that you define. You can assign a single item (such as “Failed”) or a
logical expression (such as “Passed Or Failed”) to a filter. Only records
meeting all the criteria of the filter appear in the grid or tree.
You can also define multiple filters. For example, you can define the Status
filter as “Failed” and the Tester filter as “David Or Mark”. TestDirector
displays only failed test runs performed by David or Mark.
To define a filter:
1 Click the appropriate Set Filter/Sort button. The Filter dialog box opens and
displays the Filter tab.
27
2 To set a filter condition for a specific column, click the corresponding Filter
Condition box. Click the Browse button. The Select Filter Condition dialog
box opens.
3 Define the filter condition. If applicable, select items from the list. You can
add operators to create a logical expression. For more information on logical
expressions, see “Defining Filter Conditions” on page 30.
4 Click OK to close the Select Filter Condition dialog box.
5 To add cross filters, click the Advanced link. For more information, see
“Advanced/Cross Filtering Records,” on page 31.
6 Click OK to close the Filter dialog box.
28
TestDirector applies the filter(s) and displays the filter description. For a grid,
TestDirector also displays the condition in the grid filter box, which appears
under each column name.
Filter
description
Grid filter box
for column
Designer
with
condition set
to “michael”
Tip: For a grid, you can also define a filter by using the grid filter box. To
display grid filter boxes, choose View > Grid Filters. If the filter box is empty,
a filter is not currently applied to the column. Type directly into the box, or
click the box to display the Browse button which opens the Select Filter
Condition dialog box.
Note: If you are working in the test plan tree or test sets list, you can save
filter and sort information and reload the tree or list as needed. Click the
Save button to save a filter, click the Load button to load a previously saved
filter, and click the Organize button to rename, save as, and delete filters. If
you are working in any other section in TestDirector, see Chapter 5,
“Working with Favorite Views” to save your filter information as a favorite
view.
29
Defining Filter Conditions
To define a filter condition, click the appropriate Set Filter/Sort button. In
the Filter dialog box, click the Browse button for the field you want to
define. The Select Filter Condition dialog box opens.
The following table defines the logical operators found in the Select Filter
Condition dialog box and gives examples of how to use them.
Logical
Operators
30
Description
And
Used where two conditions are selected, and both conditions
must apply. For example, to show all test names with the words
flight and departure in the Plan: Test Name column, select *flight*
And *departure*.
Or
Used where two or more conditions are selected, and either
condition can apply. For example, to display defects found by
user_x and user_y, and user_z in the Detected By column, select
user_x Or user_y Or user_z in the Select Filter Condition dialog
box.
()
Used for conditions of type. For example, to show defects
detected by all users except user_a or user_f in the Detected by
column, select Not (user_a OR user_f) in the Select Filter
Condition dialog box.
Not
Used in cases where the logical opposite of the condition must
apply. For example, to display defects found by all users except
user_x in the Detected By column, select NOT user_x in the
Select Filter Condition dialog box.
>
Used to display details greater than the chosen value. For
example, to display all defects that must be fixed in eight or
more days in the Estimated Fix Time column, select > 8 in the
Select Filter Condition dialog box.
<
Used to display details less than the chosen value. For example,
to display all defects with a priority of less than 3 in the Priority
column, select < 3 in the Select Filter Condition dialog box.
Logical
Operators
Description
>=
Used to display details greater than or equal to a chosen value.
For example, to display all defects of a priority of 3 or higher in
the Priority column, select >= 3 in the Select Filter Condition
dialog box.
<=
Used to display details less than or equal to a chosen value. For
example, to display all defects of a priority of 2 or higher in the
Priority column, select >= 2 in the Select Filter Condition dialog
box.
=
Used to display details that are equal to the chosen value. For
example, to display all defects with a priority of 5 in the Priority
column, select = 5 in the Select Filter Condition dialog box.
The following should also be considered when defining a filter condition:
➤ Some items that appear in hierarchical lists contain sublists. These items are
preceded by a folder. To choose an item from a sublist, double-click the
folder and click the item.
➤ When defining a condition for a user, you can specify the current user
(select [CurrentUser]), or an entire user group (for example, [Developer]).
➤ If you type an item with more than one word, it must be enclosed in quotes.
For example, to search for the test Login Boundary, in the Condition box,
type the following: "login boundary"
➤ If you only want to type part of the item, use an asterisk (*). For example, to
search for all tests with the word Login, in the Condition box, type the
following: *login*
➤ To search for all tests that begin with the words Insert New in the Condition
box, type the following: "insert new*"
➤ To specify an empty column, type the following: ""
➤ To specify a non empty column, type the following: not "
Advanced/Cross Filtering Records
When defining a filter, you can also include a cross filter. This is an advanced
second filter on an associated item such as associated requirements, tests,
31
test sets, or defects. For example, in the test plan tree, you can define the
cross filter for associated test sets as “Open”. In addition to any other filters
you may have set for the tests in the test plan tree, TestDirector only
displays tests that belong to an open test set.
The following table summarizes the cross filters available in each
TestDirector module:
Module
Cross Filter
Requirements
(available from
Reports only)
• Associated Defects: Filters the requirements by defects
Test Plan
• Associated Test Sets: Filters the tests by test sets that
associated with covered tests.
• Associated Tests: Filters the requirements by covered tests.
contain the tests.
• Associated Requirements: Filters the tests by covered
requirements.
• Associated Defects: Filters the tests by associated defects.
Test Lab - Test
Sets list
• Associated Defects: Filters the test sets by defects
associated with contained tests.
• Associated Tests: Filters the test sets by contained tests.
Test Lab Execution Grid
• Associated Requirements: Filters the test instances by tests
that cover selected requirements.
• Associated Defects: Filters the tests by associated defects.
Defects
• Associated Test Sets: Filters the defects by associated test
sets.
• Associated Requirements: Filters the defects by tests that
cover selected requirements.
• Associated Tests: Filters the defects by associated tests.
32
To define a cross filter:
1 Click the appropriate Set Filter/Sort button. The Filter dialog box opens and
displays the Filter tab.
Advanced link
For more information on defining a filter, see “Filtering Records,” on
page 27.
33
2 Click the Advanced link to display the cross filter options.
34
3 Under Filter by, select an advanced filter check box. For example, select
“Associated Test Sets”. Then click the corresponding link. The Cross Filter:
Associated [Filter] dialog box opens.
4 Define the cross filter, using the same rules you would to define a filter. For
more information, see “Filtering Records,” on page 27.
5 Click OK to save your changes and close the Cross Filter dialog box. In the
Filter dialog box, under Filter by, TestDirector displays the cross filter(s) you
defined.
6 Click OK to save your changes and close the Filter dialog box.
35
Sorting Records
By default, records appear in TestDirector according to the order in which
they were added.
When you set sorting priorities, TestDirector displays records according to
the ASCII sort order of the records. The ASCII sort order considers records
beginning with a space or character before considering those beginning
with numbers. It then considers uppercase letters, and finally, lowercase
letters.
For example, if the Tester column in the Test Grid is assigned the highest
sort priority, records are sorted in the ASCII sort order according to the
names appearing in the Tester column. If Test Name is assigned the next
highest priority, test records assigned the same name in the Tester column
are then sorted in the ASCII sort order according to their test name.
Note: Records are arranged in the hierarchical order defined in the test plan
tree—and not in alphabetical order—only if the records are sorted according
to Subject.
To sort records:
1 Click the appropriate Set Filter/Sort button. The Filter dialog box opens.
36
2 Click the Sort tab.
Available Fields contains the names of all the fields you can display. Sorted
Fields contains the names of the fields currently assigned a sorting priority.
3 Choose field names and click the arrow buttons (> and <) to move a name
between Available Fields and Sorted Fields. Click the double arrow buttons
(>> and <<) to move all the names from one list to the other. You can also
drag the field names between lists.
4 In Sorted Fields, set the order in which fields appear by using the up and
down arrows. Note that you can also drag the field names up or down.
5 To set a sorted field in an ascending or descending order, select a field in
Sorted Fields and click a Sort Direction button.
6 Click OK to apply the sort order.
37
Note: If you are working in the test plan tree or test sets list, you can save
filter and sort information and reload the tree or list as needed. Click the
Save button to save a filter, click the Load button to load a previously saved
filter, and click the Organize button to rename, save as, and delete filters. If
you are working in any other section in TestDirector, see Chapter 5,
“Working with Favorite Views” to save your filter information as a favorite
view.
Refreshing and Clearing Settings
You can refresh and clear the filter and sort settings applied to TestDirector
data.
➤ To refresh the data in a grid or tree, click the Set Filter/Sort arrow and
choose Refresh, or click the Refresh Filter/Sort button.
➤ To clear all the filters and sorting priorities in a grid or tree, click the Set
Filter/Sort arrow and choose Clear, or click the Clear Filter/Sort button.
Saving Data to a File
You can save the contents of a grid as a text file, Microsoft Excel spreadsheet,
Microsoft Word document, or HTML document.
To save data to a file:
1 Right-click the grid and choose Save As.
2 Select a file format: Text File, Excel Sheet, Word Document or HTML
Document. The Save Grid Result As dialog box opens.
3 In the Save in box, choose a location for the file.
4 In the File name box, type a name for the file.
5 Click Save.
38
4
Adding Attachments
You can associate an attachment with a requirement, subject folder, test, test
step, test set, test run, or defect.
➤ Attaching a File
➤ Attaching a URL
➤ Attaching a Snapshot
➤ Attaching System Properties
➤ Attaching an Image from the Clipboard
➤ Managing Attachments
About Adding Attachments
Throughout the testing process, you can add attachments to help illustrate
your work. You can attach a file, URL, snapshot of your application, an
image from the Clipboard, or system information.
39
You manage attachments using the Attachments dialog box.
The following table describes how to open the Attachments dialog box in
each TestDirector module:
40
To add an
attachment to a...
In the module
Procedure:
requirement
Requirements
Select a requirement from
the requirements tree and
click the Attachments
button, or choose View >
Attachments.
subject or test
Test Plan - test plan tree view
Select a subject folder or
test from the test plan tree,
and click the Attachments
tab.
Chapter 4 • Adding Attachments
To add an
attachment to a...
In the module
Procedure:
design step
Test Plan - test plan tree view
Select a test from the test
plan tree, and click the
Design Steps tab. Select a
step, and click the
Attachments button.
test
Test Plan - Test Grid view
Select a test from the Test
Grid, and click the
Attachments button.
test set
Test Lab
Select a test set and click
the Test Set Properties tab.
Click the Attachments link.
test step
Test Lab - Manual Test Run
During a manual test run,
click the Exec Steps
button. Select a step, and
click the Attachments
button.
test run
Test Lab - Execution Grid or
Execution Flow
In the Test Run Properties
dialog box, click the
Attachments tab.
defect
Defects
Select a defect from the
Defects Grid, and click the
Attachments button.
41
Attaching a File
TestDirector enables you to attach a file.
To attach a file:
1 In the Attachments dialog box, click the File button. The Open dialog box
opens.
2 Choose a file name and click Open.
The file name appears in the Attachments list, together with the size and
date modified. An icon for the application associated with the file appears
next to the file name.
3 In the Description box, add any comments related to the attached file.
Attaching a URL
TestDirector enables you to attach a Uniform Resource Locator (URL). This
can be any valid URL scheme such as HTTP, FTP, Gopher, News, Mailto, and
File.
To attach a URL:
1 In the Attachments dialog box, click the URL button. The Attach URL dialog
box opens.
2 In the URL box, type a valid URL and click OK.
The URL appears in the Attachments list. An icon for your default Web
browser appears next to the URL.
3 In the Description box, add any comments related to the attached URL.
42
Attaching a Snapshot
TestDirector enables you to attach images of your application.
To attach a snapshot:
1 In the Attachments dialog box, click the Snapshot button. The Snapshot
dialog box opens.
2 Drag the camera icon onto an object that you want to capture. The captured
image is displayed in the Snapshot dialog box.
3 You can change the magnification level of the captured image.
➤ Click Zoom Out or Zoom In to reach the desired magnification level.
➤ Click Normal to return to the standard level.
4 Click Attach.
TestDirector assigns the image a unique file name with a .jpg extension. The
file name appears in the Attachments list, with an image icon next to it. The
size of the file and the date on which it was modified are also displayed.
5 In the Description box, add any comments related to the attached snapshot.
43
Attaching System Properties
TestDirector enables you to attach information about your computer.
To attach system properties:
1 In the Attachments dialog box, click the System Info button. The System
Information dialog box opens.
2 To attach information from a single tab, click a tab and click the Current
Topic button.
44
3 To attach information from all tabs, click All Topics.
TestDirector assigns the information a unique file name with a .tsi
extension. The file name appears in the Attachments list, with an image
icon next to it. The size of the file and the date on which it was modified are
also displayed.
4 In the Description box, add any comments related to the attached text file.
Attaching an Image from the Clipboard
TestDirector enables you to attach an image that you copied to the
Clipboard.
To attach an image from the Clipboard:
1 Copy an image to the Clipboard.
2 In the Attachments dialog box, click the Clipboard button.
TestDirector assigns the image a unique file name with a .jpeg extension. The
file name appears in the Attachments list, with an image icon next to it. The
size of the file and the date on which it was modified are also displayed.
Managing Attachments
You can view, modify, and delete an attachment in the Attachments dialog
box.
Viewing Attachments
You can view an attachment in the Attachments list.
To view an attachment:
1 In the Attachments list, select an attachment. The corresponding
description is displayed underneath in the Description box.
2 Double-click the attachment, or click the Open button. The attachment
opens in the application associated with it. For example, a URL opens in
your default Web browser.
45
Modifying Attachments
You can modify an attachment in the Attachments list.
Note: When you open an attachment in the associated application,
TestDirector copies the attachment to the local directory of your client
machine. After making changes, you need to save the attachment twice.
First, you save it locally in the application in which you opened it. Then, in
TestDirector, you click the Save button to copy the local copy of the
attachment to your TestDirector project.
To modify an attachment:
1 Double-click an attachment in the Attachments list. A local copy of the
attachment opens in the application associated with it.
2 Modify the attachment.
3 Save the attachment in your application. Note that this saves the local copy
of your attachment.
4 Close the attachment.
5 In TestDirector, click the Save button in the Attachments dialog box. This
saves your local copy to the TestDirector project.
Deleting Attachments
You can delete an attachment from the Attachments list.
To delete an attachment:
1 In the Attachments list, select the attachment to delete. To select more than
one attachment, use the Ctrl key.
2 Click the Delete Selected button, and click Yes to confirm.
46
5
Working with Favorite Views
A favorite view is a view of a TestDirector window with the settings you have
applied to it. TestDirector lets you save favorite views and reload them as
needed.
➤ Adding Favorite Views
➤ Organizing Favorite Views
About Working with Favorite Views
You determine the way a TestDirector window looks by selecting certain
settings for it. You can save favorite views of the Test Grid, Execution Grid,
Defects Grid, all TestDirector reports and graphs, and the Document
Generator. For example, these settings may include applying a filter to grid
columns, sorting fields in a report, or setting a graph appearance. You can
save a favorite view for future use and then load it whenever appropriate.
You save favorite views either in a public folder or in a private folder. Views in
the public folder are accessible to all users. Views in the private folder are
accessible only to the person who created them.
To load a favorite view in a TestDirector window, select it from the Favorite
list.
47
Note: In the Execution Grid, working with favorite views is slightly different
to what is described in this chapter. Instead of a Favorites button, you use
commands from the menu bar: Select View > Favorites to display the
favorite view commands. Select Add to add a new view, View to load an
existing view, and Organize to organize your views.
Note: Some Favorite Views commands are accessible only to certain user
groups. User group privileges are determined by the system administrator.
For more information, refer to the TestDirector Administrator’s Guide.
Adding Favorite Views
You can add a view to the Favorite list.
To add a view:
1 Click the Favorites arrow and choose Add to Favorites. The Add Favorite
dialog box opens.
48
Chapter 5 • Working with Favorite Views
2 In the Name box, type a view name.
3 Under Location:
➤ Select Private to add the view name to your private folder. Favorite views
in this folder can only be viewed by you.
➤ Select Public to add the view name to a common folder. Favorite views in
this folder can be accessed by all users.
The favorite views that already exist in the folder you selected are displayed
in the Existing Favorites box.
4 Click OK. The new view name is added to the Favorite list.
Organizing Favorite Views
You can organize the Favorite list by deleting views and changing their
properties.
Click the Favorites button and choose Organize Favorites to open the
Organize Favorites dialog box.
49
Changing the Properties of a View
You can change the properties of a view that appears in the Favorite list.
To change the properties of a view:
1 In the Organize Favorites dialog box, select a view from the list and click
Properties. The Properties dialog box opens.
2 In the Name box, type a new name for the view.
3 Under Location:
➤ Select Private to add the view name to your private folder. It can only be
viewed by you.
➤ Select Public to add the view name to a common folder. It can be
accessed by all users.
4 Click OK.
5 Click OK to close the Organize Favorites dialog box.
Deleting a View
You can delete a favorite view from the Favorite list.
To delete a view:
1 In the Organize Favorites dialog box, select a view name from the list and
click Delete.
2 Click OK to confirm.
3 Click OK to close the Organize Favorites dialog box.
50
Part II
Requirements Specification
52
6
The Requirements Specification
Workflow
You begin the application testing process by specifying testing requirements.
Requirements describe in detail what needs to be tested in your application
and provide the test team with a foundation on which the entire testing
process is based.
By defining requirements, you can plan and manage tests that are more
focused on business needs. Requirements are then linked to tests and defects
to provide complete traceability and aid the decision-making process.
This chapter describes how you use TestDirector’s Requirements module to
specify testing requirements. The requirements specification workflow
consists of the following:
Define Testing
Scope
Create
Requirements
Detail
Requirements
Analyze
Requirements
53
TestDirector User’s Guide • Requirements Specification
Before you begin using TestDirector, make sure you have a project in which
to place your testing data. For information on creating projects, refer to the
TestDirector Administrator’s Guide.
Defining the Testing Scope
The test team begins the testing process by gathering all available
documentation on the application under test, such as marketing and
business requirements documents, system requirements specifications, and
design documents.
Use these documents to obtain a thorough understanding of the application
under test and determine your testing scope — test goals, objectives, and
strategies.
You should ask the following questions when determining your testing
scope:
➤ What is the main purpose and direction of the application?
➤ What are the major features of the application?
➤ What is the relative importance of each element in the application
functionality?
➤ What are the critical or high-risk functions of the application?
➤ What are your testing priorities?
➤ Do your customers/end-users agree with your testing priorities?
➤ What are your overall quality goals?
54
Chapter 6 • The Requirements Specification Workflow
Creating the Testing Requirements Outline
Quality Assurance managers use the testing scope to determine the overall
testing requirements for the application under test. They define requirement
topics and assign them to the QA testers in the test team. Each QA tester
uses TestDirector to record the requirement topics they are responsible for.
Requirement topics are recorded in the Requirements module by creating a
requirements tree. The requirements tree is a graphical representation of your
requirements specification, displaying the hierarchical relationship between
different requirements.
For example, consider a flight reservation application that lets you manage
flight scheduling, passenger bookings, and ticket sales. The QA manager
may define your major testing requirements as: login operations, database
operations, send fax operations, check security capabilities, graph and
reports operations, UI checking operations, and help. For the complete
example, refer to the TestDirector_Demo project.
For more information on creating a requirements tree, see Chapter 8,
“Developing the Requirements Tree.”
55
Defining Requirements
For each requirement topic, a QA tester creates a list of detailed testing
requirements in the requirements tree. For example, the requirement topic
Application Security may be broken down into the following requirements:
Requirement
topic
Requirement
children
Each requirement in the tree is described in detail, and can include any
relevant attachments. The QA tester assigns the requirement a priority level
which is taken into consideration when the test team creates the test plan.
Analyzing your Requirements Specification
QA managers review the requirements, ensuring that they meet the testing
scope defined earlier. They assign the requirement a Reviewed status once it
is approved.
To help review the requirements, you can generate TestDirector reports and
graphs. For more information, see Chapter 26, “Generating Reports,” and
Chapter 27, “Generating Graphs.”
You can then use the requirements as a basis for your test plan. The tests you
create during the test plan phase should cover these requirements. For more
information on requirements and tests coverage, see Chapter 12, “Linking
Tests to Requirements.” These tests are also associated with defects, thereby
providing complete traceability throughout the testing process.
56
7
The Requirements Module at a Glance
This chapter introduces the key elements in TestDirector’s Requirements
module.
➤ The Requirements Module
➤ The Requirements Menu Bar
➤ The Requirements Toolbar
➤ The Requirements Tree
The Requirements Module
You specify requirements in TestDirector by clicking the Requirements tab.
You can display the Document View or Coverage View of the requirements
tree.
Note: You can also import requirements to your TestDirector project from
Microsoft Word, Excel, or other third-party requirements management
tools. To import requirements, you must first install the appropriate
TestDirector add-in. For more information, refer to the TestDirector
Installation Guide.
57
By default, the Requirements module displays the requirements tree in
Document View.
Requirements
menu bar
Document View
Requirements
toolbar
Requirements
tree
Description tab
History tab
You can also display the requirements tree in Coverage View. This view
enables you to add and modify tests coverage for your requirements more
easily. For more information on coverage, see Chapter 12, “Linking Tests to
Requirements.”
Requirements
menu bar
Coverage View
Requirements
toolbar
Requirements
tree
Tests Coverage
tab
Details tab
58
Chapter 7 • The Requirements Module at a Glance
The Requirements module contains the following key elements:
➤ Requirements menu bar, with drop-down menus of Requirements module
commands.
➤ Requirements toolbar, with buttons of commands commonly used when
creating and modifying the requirements tree.
➤ View box, enabling you to display the requirements tree in Document View
or Coverage View.
➤ Requirements tree, a graphical representation of your testing requirements.
For more information, see “The Requirements Tree,” on page 62.
➤ Description tab, displaying comments about the currently selected
requirement. Available only in Document View. Click the Show arrow to
display the description pane.
➤ History tab, displaying a list of changes made to the currently selected
requirement.
➤ Tests Coverage tab, a list of the tests that address the requirement currently
selected on the requirements tree. Available only in Coverage View.
➤ Details tab, a description of the requirement currently selected on the
requirements tree. Available only in Coverage View.
The Requirements Menu Bar
The Requirements menu bar has the following menus:
➤ The Requirements menu contains commands that enable you to modify
requirements in the tree, generate a test from a requirement, and mail a
requirement.
➤ The View menu contains commands that enable you to set the display of
the requirements tree, find a requirement, and view tests coverage,
associated defects, and attachments.
➤ The Tools menu contains commands that enable you to convert
requirements to tests.
59
➤ The Analysis menu contains commands that enable you to generate
requirements reports and graphs. For more information on requirements
reports, see Chapter 26, “Generating Reports.” For more information on
requirements graphs, see Chapter 27, “Generating Graphs.”
The Requirements Toolbar
The Requirements toolbar has the following buttons:
New Requirement: Adds a new requirement to the requirements tree.
TestDirector adds the requirement underneath the currently selected
requirement at the same hierarchical level.
New Child Requirement: Adds a new requirement to the requirements tree.
TestDirector adds the child requirement underneath the currently selected
requirement at a lower hierarchical level.
Cut: Moves a selected requirement to a new location in the requirements
tree. Used in conjunction with the Paste button.
Copy: Copies a selected requirement to another location in the
requirements tree or a different TestDirector project. Used in conjunction
with the Paste button.
Paste: Pastes a cut or copied requirement in a new location in the
requirements tree.
➤ Click the Paste arrow and choose Paste to paste the requirement
underneath the currently selected requirement, at the same hierarchical
level.
➤ Click the Paste arrow and choose Paste as Child to paste the requirement
underneath the currently selected requirement, at a lower hierarchical
level.
Delete: Deletes the selected requirement from the tree.
60
Refresh Selected: Refreshes the data in the Requirements module.
➤ Click the Refresh Selected button to refresh the currently selected
requirement. Any children of the requirement are also refreshed.
➤ Click the Refresh Selected arrow and choose Refresh All to refresh all
requirements.
Select Columns: Opens the Select Columns dialog box, enabling you to
determine which fields to display in the requirements tree and their order.
For more information, see “Arranging Columns,” on page 25.
Zoom In: Changes the level of detail in the requirements tree.
➤ Click the Zoom In button to zoom in to a specific branch of the
requirements tree.
➤ Click the Zoom In arrow and choose Zoom Out One Level to undo the
previous zoom in command.
➤ Click the Zoom In arrow and choose Zoom Out To Root to zoom out and
redisplay the entire requirements tree.
Find: Opens the Find Requirement dialog box, enabling you to search for a
requirement in the tree.
Mail Requirement: Opens the Send Mail dialog box, enabling you to send a
requirement e-mail to recipients selected from a list, or to any other e-mail
address.
Attachments: Opens the Attachments dialog box, enabling you to add an
attachment to the selected requirement. For more information, see
Chapter 4, “Adding Attachments.”
Tests Coverage: Opens the Tests Coverage dialog box, enabling you to add
tests coverage to the selected requirement. Note that you can also right-click
a requirement and choose Associated Defects to view any defects associated
with a requirement that has tests coverage.
61
The Requirements Tree
TestDirector organizes and displays requirements data in the requirements
tree. Each line in the tree displays a separate requirement record. The
requirements tree can display the following details:
Option
Description
Attachment
Indicates whether the requirement has any attachments.
The value of this field can be either “Y” or “N”.
Author
The user name of the person who created the
requirement. By default, TestDirector inserts the login user
name into this field.
Cover Status
The current status of the requirement. By default, the
status is Not Covered.
A requirement status can be one of the following:
• Not Covered: The requirement has not been linked to
a test.
• Failed: One or more tests covered by the requirement
have an execution status of “Failed”.
• Not Completed: One or more tests covered by the
requirement have an execution status of “Not
Completed”.
• Passed: All the tests covered by the requirement have
an execution status of “Passed”.
• No Run: All the tests covered by the requirement have
an execution status of “No Run”.
You can click a status to open the Tests Coverage dialog
box for the selected requirement. For more information
on coverage, see Chapter 12, “Linking Tests to
Requirements.”
62
Creation Date
The date on which the requirement was created. By
default, the creation date is set to the current server date.
Click the down arrow to display a calendar and select a
different creation date.
Creation Time
The time at which the requirement was created. By
default, the creation time is set to the current server time.
Option
Description
Modified
Indicates the time at which this requirement was last
changed.
Name
The requirement name.
Priority
The priority of the requirement, ranging from low priority
(level 1) to urgent priority (level 5).
Product
The component of the application on which the
requirement is based.
Req ID
A unique alphanumeric ID for the requirement, assigned
automatically by TestDirector. Note that the Req ID is
read-only.
Reviewed
Indicates if the requirement has been reviewed and
approved by the person responsible.
Type
The type of requirement, which can be hardware or
software.
Note: You can change the label of any of the fields in the requirements tree.
You can also add up to 24 user-defined fields to the requirements tree. For
63
64
8
Developing the Requirements Tree
The requirements tree organizes and displays your testing requirements
hierarchically.
➤ Creating a Requirements Tree
➤ Finding Requirements in the Tree
➤ Viewing the Requirements Tree
➤ Viewing Requirement History
➤ Mailing Requirements
➤ Viewing Associated Defects
➤ Modifying the Requirements Tree
➤ Creating Tests from Requirements
About the Requirements Tree
The process of specifying testing requirements can be tedious and timeconsuming. In many cases, the test team records requirements in a wordprocessing or spreadsheet document. This requirements document is
complicated to maintain, difficult to organize and sort, and cannot be
linked with the tests and defects you create based on the requirements.
TestDirector’s Requirements module enables you to easily define and
manage your testing requirements as the first step in the testing process. The
test team records requirements in TestDirector by creating a requirements
65
tree. This is a graphical representation of your requirements specification,
displaying your requirements hierarchically.
Once you have created tests, you can link requirements to tests which may
also be associated with defects. In this way, you can keep track of your
testing needs at all stages of the testing process. If a testing requirement
changes, you can immediately identify which tests and defects are affected,
and who is responsible. You can group and sort requirements in the tree,
monitor task allocation and progress of requirements, and generate detailed
reports and graphs.
Note: This chapter assumes you are using the Requirements module’s
Document View to create a requirements tree. For information on the
Coverage View, see Chapter 12, “Linking Tests to Requirements.”
Creating a Requirements Tree
You specify requirements by creating a requirements tree.
To create a requirements tree:
1 Click the New Requirement button on the Requirements module toolbar.
Alternatively, choose Requirements > New Requirement.
Note: If required Requirements fields were defined in the Project
Customization window, the New Requirement dialog box opens. Select
values for the required fields, and click OK.
66
Chapter 8 • Developing the Requirements Tree
TestDirector adds a new requirement to the tree, with the default name New
Requirement.
New requirement
2 Type a name for the new requirement and press Enter. Note that a
requirement name cannot include the following characters: \ ^ *
3 Add details for the requirement. For more information on the available
fields in the requirements tree, see Chapter 7, “The Requirements Module at
a Glance.”
4 In the Description pane, type a description of the requirement.
5 Click the Attachments button, or choose View > Attachments, to add an
attachment to the new requirement. An attachment can be a file, URL,
snapshot of your application, an image from the Clipboard, or system
next to the
information. TestDirector places a clickable attachment icon
requirement name in the requirements tree. For more information, see
6 Click the Tests Coverage button, or choose View > Tests Coverage, to add
tests coverage for the requirement. Tests coverage defines the tests in the test
plan tree that address the requirement and enable you to link your testing
requirements to tests. You can only define tests coverage after you have
created tests during test planning. For more information on tests coverage,
see Chapter 12, “Linking Tests to Requirements.”
67
7 Add additional requirements to the tree:
➤ Click the New Requirement button to add the next requirement
underneath the previous one, at the same hierarchical level.
➤ Click the New Child Requirement button to add the next requirement
underneath the previous one, at a lower hierarchical level.
Finding Requirements in the Tree
You can search for a requirement in the requirements tree, based on the
requirement name or other requirement details.
Note: If you used Zoom In, TestDirector restricts the search to the section of
the tree into which you zoomed. For information on zooming in to the tree,
see “Viewing the Requirements Tree,” on page 69.
To find a requirement:
1 Click the Find button on the toolbar. Alternatively, right-click the
requirements tree and choose Find. The Find Requirement dialog box opens.
2 In the Find in Field box, select the criterion to search for.
3 In the Value to Find box, type or select the value of the field you chose. The
search is not case sensitive.
For example, if the field is “Name”, type the name of the requirement in the
Value to Find box. If the field is “Priority”, select a priority from one to five
from the list in the Value to Find box.
68
4 Click Find. TestDirector attempts to locate the requirement with the
specified value. If the search is successful, the Search Results dialog box
opens and displays a list of possible matches. Select a result from the list and
click the Go To button to highlight the requirement in the requirements
tree.
If the search is unsuccessful, an information box opens.
Viewing the Requirements Tree
You can change the way TestDirector displays the requirements tree. This
includes zooming in and out of the tree, displaying numeration, refreshing
the tree, and expanding and collapsing the branches of the tree.
Zooming the Tree
You can zoom in and zoom out of the requirement topics in the
requirements tree. This enables you to change the level of detail that the
tree displays.
To zoom in:
1 Select a requirement topic in the requirements tree.
2 Click the Zoom In button on the toolbar. Alternatively, right-click the
requirement and choose Zoom In.
The requirements tree only displays the selected requirement topic and
includes a heading with the hierarchical path of the requirement topic.
To zoom out:
To reverse a zoom in action, you can either zoom out one level or zoom out
completely.
➤ Click the Zoom In arrow and choose Zoom Out One Level to undo the
previous zoom in command.
➤ Click the Zoom In arrow and choose Zoom Out To Root to zoom out
completely and display the entire requirements tree.
69
Displaying Numeration
Choose View > Numeration to assign hierarchical numbers to each
requirement in the tree. As you make changes to the tree, TestDirector
automatically renumbers the requirements. Note that the numbers are not
related to the unique Req ID assigned to each requirement. By default, the
requirements are displayed in numerated order.
Refreshing the Tree
You can refresh the data in the Requirements module.
➤ To quickly refresh a requirement, select the requirement and click the
Refresh Selected button. Any children of the requirement are also refreshed.
➤ To refresh all requirements, click the Refresh Selected arrow and choose
Refresh All.
Expanding and Collapsing the Tree
You can expand and collapse the branches in the requirements tree. This
enables you to change the level of detail that the tree displays.
To expand and collapse the tree:
➤ To expand a branch in the tree, click the Expand
sign to the left of the
branch name. To expand all the levels in a branch, right-click the branch
name and choose Expand.
➤ To collapse a branch in the tree, click the Collapse
branch name. To collapse all the levels in a branch, right-click the branch
name and choose Collapse.
70
Viewing Requirement History
You can view a list of changes made to any requirement in the requirements
tree.
To view the history of changes to a requirement:
1 In the requirements tree, select a requirement.
2 Click the History tab. The history of all the fields is displayed in a grid.
For each change to the requirement, the grid displays the date of the
change, the name of the person who made the change, and the new value.
3 You can specify which fields will be displayed in the grid. In the Field list,
select a field name to view changes made only to that field.
For information on preserving the history of changes made to a field, see the
71
Mailing Requirements
You can send an e-mail about a requirement to other users in your
TestDirector project. This enables you to routinely inform development and
quality assurance personnel about the status of your testing requirements.
Note: By default, TestDirector sends e-mails in HTML format (except if you
are working with the Windows MAPI protocol). To instruct TestDirector to
send e-mails as plain text instead, you need to edit the MAIL_FORMAT
parameter in the Site Config tab in the Site Administrator. For more
information, refer to the TestDirector Administrator’s Guide.
To mail a requirement:
1 In the requirements tree, select a requirement and click the Mail
Requirement button. The Send Mail dialog box opens.
72
2 Type a valid e-mail address. Alternatively, click the To button or Cc button
to select users. The Select Recipients dialog box opens.
Select the users or user groups to which you want to send the e-mail, and
click OK. Note that you can view user properties by right-clicking a user and
choosing Properties. For more information on defining user properties, refer
3 In the Subject box, type a subject for the e-mail.
4 Choose whether you want to include the Attachments, History, and/or Tests
Coverage of the requirement.
5 In the Additional comments box, add any comments you may have.
73
6 To check the spelling in the dialog box:
➤ Click the Check Spelling button to check the spelling for the selected
word or text box. If there are no errors, a confirmation message opens. If
errors are found, the Spelling dialog box opens and displays the word
together with replacement suggestions.
➤ Click the Spelling Options button to open the Spelling Options dialog
box, enabling you to configure the way TestDirector checks spelling.
➤ Click the Thesaurus button to open the Thesaurus dialog box and display
a synonym, antonym, or related word for the selected word. You can
replace the selected word or look up new words.
7 Click Custom to view and edit the complete e-mail text.
8 Click Send to send the e-mail.
Viewing Associated Defects
You can view the defects associated with a selected requirement in the
requirements tree. In order for a requirement to have an associated defect, it
must have tests coverage (see Chapter 12, “Linking Tests to Requirements”).
The linked test then needs to be associated with a defect, either during test
planning (see “Associating Defects with a Test,” on page 110) or during a
manual test run (see “Running a Test Manually,” on page 198).
74
To view associated defects, select View > Associated Defects, or right-click a
requirement in the requirements tree and choose Associated Defects. The
Associated Defects dialog box opens.
75
Modifying the Requirements Tree
You can rename, copy, move, or delete requirements in the requirements
tree.
Renaming a Requirement
You can rename a requirement in the requirements tree.
To rename a requirement:
1 Select a requirement from the requirements tree.
2 Click the requirement. Alternatively, right-click the requirement and choose
Rename.
3 Edit the requirement name. Note that a requirement name cannot include
the following characters: \ ^ *
4 Press Enter.
Copying a Requirement
You can copy a requirement in the requirements tree. When you copy a
requirement topic, the Requirements module also copies any children of the
requirement topic.
Note: You can copy a requirement to a different TestDirector project.
To copy a requirement:
1 Select a requirement to copy in the requirements tree.
2 Click the Copy button. Alternatively, right-click the requirement and choose
Copy.
3 Select a requirement in the requirements tree.
76
4 You can paste the copied requirement at the same hierarchical level or at a
lower hierarchical level:
➤ To paste the requirement underneath the selected requirement, at the
same hierarchical level, click the Paste arrow and choose Paste.
Alternatively, right-click the requirement and choose Paste > Paste.
Note that if you paste a requirement that has the same name as an
existing requirement, TestDirector automatically adds _Copy to the end
of the requirement’s name.
➤ To paste the requirement underneath the selected requirement, at a lower
hierarchical level, click the Paste arrow and choose Paste as Child.
Alternatively, right-click the requirement and choose Paste > Paste as
Child.
5 Click Yes to confirm.
Moving a Requirement
You can move a requirement to a different location in the requirements tree.
When you move a requirement topic, the Requirements module also moves
any children of the requirement topic.
To move a requirement:
1 Select a requirement to move in the requirements tree.
2 Click the Cut button. Alternatively, right-click the requirement and choose
Cut.
3 Select a requirement in the requirements tree.
77
4 You can paste the cut requirement at the same hierarchical level or at a
lower hierarchical level:
➤ To paste the requirement underneath the selected requirement, at the
same hierarchical level, click the Paste button and choose Paste.
Alternatively, right-click the requirement and choose Paste > Paste.
➤ To paste the requirement underneath the selected requirement, at a lower
hierarchical level, click the Paste button and choose Paste as Child.
Alternatively, right-click the requirement and choose Paste > Paste as
Child.
Tip: You can also move a requirement to a new location in the requirements
tree by dragging it.
Deleting a Requirement
You can delete a requirement from the requirements tree. Deleting a
requirement topic also deletes any children of the requirement topic.
To delete a requirement:
1 Select a requirement from the requirements tree.
2 Click the Delete button or choose Requirements > Delete. Alternatively,
select the requirement, and press the Delete button on the keyboard.
78
Creating Tests from Requirements
Once you have created the requirements tree, you use the requirements as a
basis for defining the tests in your test plan tree and running tests in a test
set. Note that you must have the necessary permissions in order to create
tests.
There are two methods you can use to create tests from requirements:
➤ Convert Requirements to Tests: Convert requirements to tests in a specified
subject in the test plan tree. You can convert selected requirements or all
requirements in the requirements tree. This method, using the Convert to
Tests wizard, assists you when designing your test plan tree. See “Converting
Requirements to Tests,” on page 79.
➤ Generate a Test from Requirements: Convert requirements to a test in a
specified subject in the test plan tree and a specified test set in the Test Lab
module. This method, using the Generate Test dialog box, enables you to
quickly run a test when analyzing your requirements. See “Generating a Test
from Requirements,” on page 83.
Converting Requirements to Tests
Use the Convert to Tests wizard to convert requirements to tests in a
specified subject in the test plan tree.
To convert requirements to tests:
1 You can convert a specific requirement or all requirements in the tree:
➤ To convert all requirements, choose Tools > Convert to Test > Convert All.
➤ To convert a specific requirement, select the requirement in the
requirements tree and choose Tools > Convert to Test > Convert Selected.
79
The Step 1 dialog box opens.
2 Choose an automatic conversion method:
➤ Select Convert lowest child requirements to design steps to convert all
lowest level child requirements to design steps, the next level up to tests,
and all levels above to subjects.
➤ Select Convert lowest child requirements to tests to convert all lowest
level child requirements to tests and all levels above to subjects.
➤ Select Convert all requirements to subjects to convert all selected
requirements to subjects.
3 Click Next to begin converting the requirements. To cancel the conversion
process and return to the Step 1 dialog box, click the Stop button in the
80
progress bar. When the conversion process is complete, the results are
displayed in the Step 2 dialog box.
Note: If you are converting a single requirement, the wizard skips this dialog
box.
4 To view the wizard legend, click the Legend link.
5 For each converted item, you can do the following:
➤ Select the item and click the Exclude button, or right-click the item
and choose Exclude, to exclude the item from the test plan tree.
➤ Select the item and click the
Subject button, or right-click the item
Subject, to change the item to a subject in the test plan
and choose
tree. Children can then be either subjects or tests. Note that subject
names must be unique.
81
➤ Select the item and click the Test button, or right-click the item and
choose Test, to change the item to a test in the test plan tree. Children
are then converted to steps. Note that test names must be unique.
➤ Select the item and click the Step button, or right-click the item and
choose Step, to change the item to a step in the test plan tree.
Children are then converted to a step description.
➤ Select the item and click the Desc. button, or right-click the item and
choose Desc., to change the item to a step description in the test plan
tree. Children are then converted to indented description text.
6 Clear the Auto Complete Children check box if you do not want the wizard
to assist you when you make changes. If this option is selected and you
change the level of a parent, for example, from a subject to a test, the wizard
changes the level of all the children, for example, from tests to test steps.
7 Click Next. The Step 3 dialog box opens.
8 In the Destination Subject Path, click the browse button to select a subject
from your test plan tree in the Select a Destination Subject dialog box.
82
Alternatively, type a new subject name. By default, TestDirector places the
test in the Temporary Tests folder in the Test Plan module.
9 Click Finish. To stop the conversion process and return to the Step 3 dialog
box, click the Stop button in the progress bar.
10 Click OK in the Information dialog box to close the Convert to Tests wizard
or view the error messages that have been generated.
Generating a Test from Requirements
Use the Generate Test dialog box to convert requirements to a test in a
specified subject in the test plan tree and a specified test set in the Test Lab
module.
To generate a test from requirements:
1 Right-click a requirement in the requirements tree and choose
Generate Test. The Generate Test dialog box opens.
2 In the Subject box, select a subject from your test plan tree or type a new
subject name. By default, TestDirector places the test in the Temporary Tests
folder in the Test Plan module.
3 In the Test Name box, type a name for the new test. By default, TestDirector
assigns the new test the same name as the requirement.
83
4 If you do not want TestDirector to create design steps, clear the Create
Design Steps check box. If this option is selected, TestDirector adds a step to
the test for each child requirement.
5 Check Add Test to Test Set to instruct TestDirector to add the test to a test
set in the Test Lab module. In the Test Set list, select a test set or type a new
test set name.
6 Click OK.
84
Part III
Test Planning
86
9
The Test Plan Workflow
Developing a clear and concise test plan is an essential requirement for
successful application testing. A good test plan enables you to assess the
quality of your application at any point in the testing process.
This chapter describes how you develop a test plan with TestDirector’s Test
Plan module. Developing a test plan consists of the following:
Define Testing
Strategy
Define Test
Subjects
Define Tests
Create
Coverage
Design Test
Steps
Automate
Tests
Analyze Test
Plan
87
TestDirector User’s Guide • Test Planning
Defining Testing Strategy
Outline a strategy for achieving your testing requirements, as defined in the
Requirements module. Ask yourself two basic questions:
How should you test your application?
➤ Which testing techniques will you use (stress tests, security tests,
performance and load tests, etc.)?
➤ How will you handle defects (severity classification, authorization to open
and close defects, etc.)?
What resources do you require?
➤ What resources do you require in order to test (personnel, hardware, etc.)?
➤ When will the various tasks be completed?
For example, consider a flight reservation application that lets you manage
flight scheduling, passenger bookings, and ticket sales. Testing will require
designing 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.
Defining Test Subjects
Consider the hierarchical relationship of the functions in your application.
Divide the functions into subjects and build a test plan tree representing
your application’s functionality.
The test plan tree is a graphical representation of your test plan. It is a
hierarchical list of tests organized according to topic, which describes the set
of tests you will implement in order to meet your quality requirements. For
example, the flight reservation application could require that you include
Create Order, Delete Order, Open Order, and Update Order as test subjects.
For a complete description and illustration of how to create a test plan tree,
see Chapter 11, “Developing the Test Plan Tree.”
88
Chapter 9 • The Test Plan Workflow
Planning Tests
Plan tests for each subject in your test plan tree. Decide which types of tests
to create for each subject, such as sanity level tests or regression tests. (For an
explanation of these test types, see Chapter 18, “Creating Test Sets.”) Then
create the tests and assign them to a branch of the test plan tree. For
example, in the flight reservation application, you could include the
following tests under the subject Create Order: Change Date, Change From
Location, Change To Location, Insert New Order, and Verify Insertion.
You can associate a test with specific defects. This is useful, for example,
when a new test is created specifically for a known defect. By creating an
association, you can determine if the test should be run based on the status
of the defect.
For information on planning tests, see Chapter 11, “Developing the Test
Plan Tree.”
Creating Requirements Coverage
Link each test in the test plan tree with a requirement or requirements in
the requirements tree. By defining requirements coverage for a test, you can
keep track of the relationship between the tests in your test plan and your
original testing requirements. For example, in the flight reservation
application, the tests in the subject Create Order cover the requirements in
the requirements topic Check Creation of New Order.
In addition, because tests are associated with defects, tests coverage provides
complete traceability from requirements specification to defect tracking.
For information on requirements coverage, see Chapter 12, “Linking Tests to
Requirements.”
89
Designing Test Steps
Design the tests in your test plan tree. Create test steps describing the
operations to perform, points to check, and expected results. After you
define the test steps, decide whether to perform the test manually or
automate it.
For manual tests you define steps, execute them on your application, and
record the results of each one. Use manual tests in cases where the test
requires a response by the tester. Manual tests include usability tests, onetime tests, tests that need to be run immediately, tests requiring knowledge
of the application, and tests without predictable results.
For example, in the flight reservation application, tests that check if a dialog
box is user-friendly require user response. Therefore, you could make these
tests manual.
For information on designing test steps, see Chapter 13, “Building Tests.”
Automating Tests
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.
After designing test steps, you can decide which tests to automate. Factors
influencing test automation include frequency of execution, volume of data
input, length of execution time, and complexity.
For automated tests, you can first design test steps and automate them by
generating a test template. The test template can be WinRunner, QuickTest
Professional, Astra QuickTest, QuickTest Professional for MySAP.com
Windows Client, Astra LoadTest, LoadRunner, XRunner, Visual API, or
Visual API-XP.
90
Chapter 9 • The Test Plan Workflow
For example, in the flight reservation application, you can automate a test
that checks whether the login mechanism works. After adding test steps,
you create a test template. Then, using WinRunner, you complete the
automated test script.
For more information on creating automated tests, see Chapter 14,
“Creating Automated Tests.”
Note: You can also create automated system tests to instruct TestDirector to
provide system information for a machine, capture a desktop image, or
restart a computer. For more information, see Chapter 15, “Working with
System Tests.”
Analyzing Your Test Plan
Review your test plan to determine how well it meets the goals that you
defined at the beginning of the testing process. Then, analyze your test plan
by generating TestDirector reports and graphs. See Chapter 26, “Generating
Reports” and Chapter 27, “Generating Graphs.”
For example, you can create a report that displays design step data for each
test in a test plan tree. You can then use this report to help you determine
your test design priorities.
In order to best ensure success of the testing process, it is recommended that
you analyze your test plan throughout the testing process. Review the plan,
and determine whether or not it matches your testing goals. Make
adjustments to your test plan accordingly.
91
92
10
The Test Plan Module at a Glance
This chapter introduces the key elements in TestDirector’s Test Plan module.
➤ The Test Plan Module
➤ The Test Plan Menu Bar
➤ The Test Plan Toolbar
➤ The Test Grid
The Test Plan Module
You design tests in TestDirector by clicking the Test Plan tab.
Test Plan
menu bar
Test Plan
toolbar
Test Plan Tree
tabs:
Details
Design Steps
Test Script
Attachments
Reqs Coverage
93
The Test Plan module contains the following key elements:
➤ Test Plan menu bar, with drop-down menus of Test Plan module commands.
➤ Test Plan toolbar, with buttons of commands commonly used when creating
and modifying the test plan tree.
➤ Test Plan Tree, a graphical representation of your test plan. For more
information, see Chapter 11, “Developing the Test Plan Tree.”
➤ Details tab, a description of the subject folder or test currently selected on
the test plan tree. For more information, see Chapter 11, “Developing the
Test Plan Tree.”
➤ Design Steps tab, a list of test steps explaining how to execute the test
currently selected on the test plan tree. The tab includes a steps icon
if
the selected test has design steps. For more information, see Chapter 13,
“Building Tests.”
➤ Test Script tab, the TSL test script for the test currently selected on the test
plan tree. The tab includes a test script icon
if the selected test has a test
script. For more information, see Chapter 14, “Creating Automated Tests.”
➤ Attachments tab, a list of attachments that provide additional information
for the test currently selected on the test plan tree. The tab includes an
if the selected test has any attachments. For more
attachments icon
information, see Chapter 4, “Adding Attachments.”
➤ Reqs Coverage tab, a list of the requirements that the test currently selected
if the
on the test plan tree meets. The tab includes a coverage icon
selected test has requirements coverage. For more information, see
Chapter 12, “Linking Tests to Requirements.”
Tip: Right-click a test in the test plan tree and choose Go to Test in Test Set.
TestDirector opens the Test Lab module and highlights the selected test.
94
Chapter 10 • The Test Plan Module at a Glance
The Test Plan Menu Bar
The Test Plan menu bar has the following menus:
➤ The Planning menu contains commands that enable you to manage the
folders and tests in the tree. For more information, see Chapter 11,
“Developing the Test Plan Tree.”
➤ The View menu contains commands that enable you to set the display in
the test plan tree (for more information, see Chapter 3, “Working with
TestDirector Data”), open the Test Grid, and add associated defects.
planning reports and graphs. For more information on planning reports, see
Chapter 26, “Generating Reports”. For more information on planning
graphs, see Chapter 27, “Generating Graphs.”
The Test Plan Toolbar
The Test Plan toolbar has the following buttons:
New Folder: Adds a new subject folder to the test plan tree.
New Test: Adds a new test to the test plan tree.
Delete: Deletes the selected folder or test from the tree. If you delete a folder,
TestDirector moves all the tests to the Unattached folder in the test plan
tree. If you delete a test, TestDirector deletes the test and the test script
permanently.
Refresh Selected: Refreshes the selected section of the test plan tree. To
refresh all the tests in the test plan tree, select the Subject folder.
Filter/Sort: Includes the following options:
➤ Set: Opens the Filter dialog box, enabling you to filter and sort the tests
in the test plan tree.
➤ Refresh: Refreshes the test plan tree so that it displays the most up-todate tests based on the filters and sort order you have selected.
95
➤ Clear: Clears any filters or sorting that you have applied to the test plan
tree.
For more information on filtering and sorting tests, see Chapter 3, “Working
with TestDirector Data.”
Find Folder/Test: Opens the Find Folder/Test dialog box, enabling you to
search for a folder or test in the tree.
Sort Folders: Opens the Sort Folders in Test Plan Tree dialog box, enabling
you to custom sort the folders in the test plan tree. By default, folders are
sorted by name.
Mail Selected Test(s): Opens the Send Mail dialog box, enabling you to send
an e-mail of the selected test(s) to recipients selected from a list, or to any
other e-mail address(es).
The Test Grid
The Test Grid displays all the tests in a TestDirector project. Each row
displays a separate test record. Each column represents a separate data item.
To view the Test Grid, choose View > Test Grid.
Test Grid
toolbar
Grid filter
Description
tab
History tab
96
You can view and modify test information in the Test Grid. For example,
you can copy several automated tests and paste them in another project, or
you can delete several tests at once. In addition, you can save the grid
information in several formats, including a text file, Word document, HTML
document, and an Excel spreadsheet.
The Test Grid contains the following key elements:
➤ Test Grid toolbar, with buttons of commands commonly used when creating
and modifying the Test Grid. See “The Test Grid Toolbar,” on page 97.
➤ Grid filter, displaying the filter that is currently applied to a column. For
more information, see “Filtering Records,” on page 27.
➤ Description tab, displaying a description of the selected test in the Test Grid.
➤ History tab, displaying the changes made to a test. For each change, the grid
displays the field name, date of the change, name of the person who made
the change, and the new value.
The Test Grid Toolbar
The Test Grid toolbar has the following buttons:
Copy Selected Tests: Copies the selected test(s) to a Test Grid or test plan
tree in the same project or a different project. Used in conjunction with the
Paste button.
Paste: Pastes a copied test in a new location in the Test Grid or test plan tree.
Set Filter/Sort: Opens the Filter dialog box, enabling you to filter and sort
the tests in the Test Grid. For more information, see Chapter 3, “Working
with TestDirector Data.”
Clear Filter/Sort: Clears any filters or sorting that you have applied to the
Test Grid.
Refresh Filter/Sort: Refreshes the Test Grid so that it displays the most up-todate tests based on the filters and sort order you have selected.
determine which columns to display in the grid and their order. For more
information, see “Arranging Columns,” on page 25.
97
Find Test: Includes the following options:
➤ Find: Opens the Find dialog box, enabling you to search for a test in the
Test Grid. Select the field in which you want to search, and enter the
value you want to find. Note that if you have applied filters to the Test
Grid, the search is restricted to the tests currently displayed.
➤ Find Next: Finds the next occurrence of the last search you performed.
➤ Replace: Opens the Find/Replace dialog box, enabling you to search for a
specific field value in the Test Grid and replace the value.
Go to Test in Test Plan Tree: Closes the Test Grid and displays the selected
test in the test plan tree.
Attachments: Opens the Attachments dialog box, enabling you to add an
attachment to the selected test. For more information, see Chapter 4,
“Adding Attachments.”
Delete Selected Test(s): Deletes the selected test(s) from the Test Grid.
Mail Selected Test(s): Opens the Send Mail dialog box, enabling you to send
an e-mail of the selected test(s) to recipients selected from a list, or to any
other e-mail address(es).
Favorites: Includes the following options:
➤ Add to Favorites: Opens the Add Favorite dialog box, enabling you to
save a view and add it to your Favorite list.
➤ Organize Favorites: Opens the Organize Favorites dialog box, enabling
you to manage the Favorite list by renaming, saving as, and deleting
views.
For more information on favorite views, see Chapter 5, “Working with
Favorite Views.”
98
Test Grid Columns
The Test Grid displays the following test planning data columns:
Column
Description
Creation Date
The date on which the test was created. By default, the
creation date is set to the current server date. Click the
down arrow to display a calendar and select a different
creation date.
Description
Describes the test.
Designer
The user name of the person who designed the test.
Estimated DevTime
The time estimated to design and develop the test.
Execution Status
The execution status of the test. Execution status can
be one of the following: Failed, No Run, Not
Completed, Passed.
Modified
The date and time of the last change to the test.
Path
The test’s file system path on the server side (relative
to the test repository).
Status
The planning status of the test. The default status is
Design.
Steps
The number of steps in the test.
Subject
The subject folder in the test plan tree in which the
test resides.
Template
Indicates whether the test is a test template. The value
in this column can be “Y” or “N”.
Test Name
The name of the test.
Type
The type of test. For example, manual or WinRunner.
99
Note: You can change the label of any of the fields in the Test Grid. You can
also add user-defined fields to the Test Grid. For more information, refer to
the TestDirector Administrator’s Guide.
100
11
Developing the Test Plan Tree
The test plan tree organizes and displays your tests hierarchically, according
to test subjects.
➤ Creating a Test Plan Tree
➤ Adding Tests to a Test Plan Tree
➤ Viewing the Test Plan Tree
➤ Associating Defects with a Test
➤ Mailing Tests
➤ Finding Tests in the Tree
➤ Sorting a Test Plan Tree
➤ Modifying a Test Plan Tree
About the Test Plan Tree
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 a test plan tree.
This is a graphical representation of your test plan, displaying your tests
according to the hierarchical relationship of their functions.
After you define subjects in the tree, you decide which tests to create for
each subject and add them to the tree. At this stage, you define basic
information about the test, such as its name, status, and the designer. You
can also attach a file, URL, application snapshot or system information to
101
illustrate a test. Afterwards, you define the test steps—a detailed description
of how to execute the test and evaluate the results.
During the testing process, you may need to modify your test plan. You can
update the test plan tree at any time.
There are a number of methods for organizing your test plan by subject. For
example, you could define subjects according to:
➤ application functionality—such as editing, file operations, and reporting
➤ type of testing—such as functional, user interface, performance, and load
Suppose you are testing a flight reservation application that lets you manage
flight scheduling, passenger bookings, and ticket sales. (For the complete
example, refer to the TestDirector_Demo project.) You might define the
following subjects for the test plan tree:
Notice how the Mercury Tours Site and Itinerary subjects contain additional
subject folders. These folders further categorize the tests in the test plan tree
by creating additional levels of subjects.
102
Chapter 11 • Developing the Test Plan Tree
Once you have built the basic structure of your plan, you create tests and
assign them to each subject. For example, in the test plan tree shown above,
you might assign tests to the Reservation Details subject folder as follows:
Note: Developing and editing a test plan tree requires appropriate user
permissions. For more information, see the TestDirector Administrator’s Guide.
Creating a Test Plan Tree
You define a hierarchical framework for your test plan by creating a test plan
tree.
To create a test plan tree:
1 Click the New Folder button, or choose Planning > New Folder. The New
Folder dialog box opens.
2 In the Folder Name box, type a name for the subject. Note that a folder
name cannot include the characters \ or ^. Click OK.
The new subject folder appears under the Subject entry in the test plan tree.
3 In the Description tab, type a description of the subject.
103
4 Click the Attachments tab to add an attachment to the new folder if
necessary. An attachment can be a file, URL, snapshot of your application,
an image from the Clipboard, or system information. For more information,
see Chapter 4, “Adding Attachments.”
5 Create as many additional subjects at the main level as you want.
6 Choose a main subject folder from the test plan tree to create a subfolder
underneath it.
7 Click New Folder and repeat steps 2 to 6.
Adding Tests to a Test Plan Tree
Once you have created a test plan tree containing the main test subjects,
you are ready to create tests. Each test should have a distinct objective, such
as verifying a specific function or system requirement. The tests you define
should be based on the goals you set at the beginning of the testing process.
For example, in the flight reservation application, you could define a test
called Login Boundary that checks the login procedure. You could place this
test under the subject Security.
Tip: You can instruct TestDirector to automatically create tests based directly
on your testing requirements in the Requirements module. For more
information, see “Creating Tests from Requirements,” on page 79.
To add new tests:
1 Choose a subject folder in the test plan tree.
104
2 Click the New Test button, or choose Planning > New Test. The Create New
Test dialog box opens.
3 Select a test type from the Test Type list. You can select the following test
types:
Test Type
Description
MANUAL
A TestDirector manual test.
WR-AUTOMATED
A test that will be executed by WinRunner, Mercury
Interactive’s functional testing tool for Microsoft Windows
applications.
VAPI-TEST
A test that will be executed by Visual API, TestDirector’s API
execution tool that enables you to create and run
C Scripts.
LR-SCENARIO
A scenario that will be executed by LoadRunner, Mercury
Interactive’s load testing tool.
QUICKTEST-TEST
A test that will be executed by QuickTest Professional,
Mercury Interactive’s functional enterprise testing tool; or
Astra QuickTest, Mercury Interactive’s functional enterprise
testing tool for the Web.
ALT-TEST
A test that will be executed by Astra LoadTest, Mercury
Interactive’s load testing tool for Web applications.
ALT-SCENARIO
A scenario that will be executed by Astra LoadTest, Mercury
Interactive’s load testing tool for Web applications.
QTSAP-TESTCASE
A test that will be executed by QuickTest Professional for
MySAP.com Windows Client, Mercury Interactive’s
functional testing tool for MySAP.com applications using
Windows 95, Windows 98, Windows 2000, and Windows NT
4.0.
105
Test Type
Description
XRUNNER
A test that will be executed by XRunner, Mercury
Interactive’s automated testing tool for X Windows
applications.
VAPI-XP-TEST
A test that is created using Visual API-XP, TestDirector’s open
test architecture API testing tool. For more information, see
Appendix A, “Working with VAPI-XP.”
Note: This test type is not available in the TestDirector
Standard Edition.
SYSTEM-TEST
A test that instructs TestDirector to provide system
information, capture a desktop image, or restart a computer.
For more information, see Chapter 15, “Working with
System Tests.”
Note: The following test types are only available if you have installed the
appropriate add-in from the TestDirector Add-ins page: QUICKTEST-TEST,
ALT-TEST, XRUNNER, and QTSAP-TESTCASE. For more information on
installing add-ins, see the TestDirector Installation Guide.
4 In the Test Name box, type a name for the test, and click OK. Note that a
test name cannot include the following characters: \ / : " ^ ? < > | *
A QuickTest Professional or an Astra QuickTest test cannot include the
following additional characters: + =
Note: If required test fields were defined in the Project Customization
window, the Required Fields dialog box opens. Select values for the required
fields, and click OK.
The new test appears in the test plan tree under the subject folder you
selected. In the Details tab, the name is added to the Test Name box.
106
5 Enter the following test details in the Details tab:
Option
Description
Creation Date
The date on which the test was created. By default, the creation
date is set to the current server date. Click the down arrow to
display a calendar and select a different creation date.
Status
The current status of the test. The default status is Design. Click
the down arrow to select a different status from the list.
Designer
The person who designed the test. By default, TestDirector
displays the login user name. Click the down arrow to select a
different user name.
Test Name
The name of the test. Note that the Test Name is read-only.
Description
Describes the test.
Note: You can change the label of any of the test detail fields. You can also
add up to 24 user-defined fields to the test details. For more information,
6 Click the Attachments tab to add an attachment to the new test if necessary.
An attachment can be a file, URL, snapshot of your application, an image
from the Clipboard, or system information. For more information, see
7 Click the Reqs Coverage tab to define requirements coverage. For more
information, see Chapter 12, “Linking Tests to Requirements.”
8 Click the Design Steps tab to define steps for the test. For more information,
see Chapter 13, “Building Tests.”
107
Viewing the Test Plan Tree
Use the test plan tree to review the overall structure of your test plan and to
view the tests assigned to each subject.
A test plan tree can include the following test icons:
Manual test
WinRunner test
WinRunner batch test
For more information on creating and working with
WinRunner batch tests, refer to the WinRunner User’s Guide.
Visual API test
LoadRunner scenario
QuickTest Professional or Astra QuickTest test
Astra LoadTest test
Astra LoadTest scenario
QuickTest Professional for MySAP.com Windows Client test
108
Visual API-XP test
(not available in the TestDirector Standard Edition)
System test
XRunner test
Vuser Script test
Template test
Steps have been defined for the test
To view tests in the test plan tree:
By default, the test plan tree displays only the highest level subjects in the
subject hierarchy.
➤ To expand a branch in the tree, click the Expand
branch name. To expand all the branches in the tree, right-click the test
plan tree and choose Expand Folder.
➤ To collapse a branch in the tree, click the Collapse
branch name. To collapse all the branches in the tree, right-click the test
plan tree and choose Collapse Folder.
➤ To view tests associated with a particular subject, double-click a subject
folder .
➤ To refresh a test in the tree, select the test and click the Refresh Selected
button. To refresh all the tests in the test plan tree, select the Subject folder
and click Refresh Selected.
➤ Click the Set Filter/Sort button to filter and sort the tests appearing in the
test plan tree. For more information, see Chapter 3, “Working with
TestDirector Data.” Any currently applied filters or sorting orders are
displayed under the test plan tree toolbar.
Note: To view all the tests in a TestDirector project at once, choose
View > Test Grid.
109
Associating Defects with a Test
You can associate the tests in your test plan with specific defects. This is
useful, for example, when a new test is created specifically for a known
defect. By creating an association, you can determine if the test should be
run based on the status of the defect. Note that any requirements covered by
the test are also associated with the defect.
To associate defects with a test:
1 Select a test in the test plan tree and choose View > Associated Defects, or
right-click the test and choose Associated Defects. The Associated Defects
dialog box opens.
110
2 To add an associated defect, click the Associate button. The Associate Defect
dialog box opens.
3 Type a Defect ID or click the Select button to select from a list of available
defects.
4 Click OK. The defect is added to the list.
5 Click Refresh to update the associated defects list.
6 Click Columns to customize the appearance and order of defect fields. For
more information on arranging columns, see “Arranging Columns,” on
page 25.
7 To remove an associated defect from the list, select the defect and click
Remove. Click Yes to confirm.
8 Click Close.
Mailing Tests
You can send an e-mail about a test to other users in your TestDirector
project. This enables you to routinely inform development and quality
assurance personnel about the status of your tests.
111
To mail a test:
1 In the test plan tree or Test Grid, select a test and click the Mail Selected
Test(s) button. The Send Mail dialog box opens.
112
4 Choose whether you want to include the Attachments, History, and/or
Design Steps of the test.
6 To check the spelling in the dialog box:
113
7 To edit the e-mail, and send it as plain text instead of HTML format, click
Custom.
Finding Tests in the Tree
You can search for a folder or test in the test plan tree. If you have applied
filters to the test plan tree, note that the Test Plan module restricts the
search to the test plan tree currently displayed.
To find a folder or test:
1 Click the Find Folder/Test button on the toolbar. To restrict the search to a
specific folder in the tree, choose the folder first and then click the button.
The Find Folder/Test dialog box opens and displays the folder name in the
Find In box. If you are searching the entire tree, the folder name is Subject.
2 In the Value To Find box, type the name (or part of the name) of the folder
or test. Note that the search is not case sensitive.
3 Check Include Tests to instruct TestDirector to search for folders and tests.
4 Click Find.
TestDirector attempts to locate the folder or test. If the search is successful,
the Search Results dialog box opens and displays a list of possible matches.
Select a result from the list and click the Go To button to highlight the
folder or test in the test plan tree.
114
Note: You can also search for a test in the Test Grid, using the Find dialog
box. Instead of searching a folder, you select a field in which you want to
search, and enter the value you want to find. Note that you can select
whether you want your search to be case sensitive, yield an exact match,
and/or use wildcards.
Sorting a Test Plan Tree
By default, subjects appear in a test plan tree in alphabetical order (by
name). You can sort the folders in the test plan tree and create a custom sort
according to your needs.
Note: Only a user with administrator permissions can create a custom sort.
For more information on assigning user group permissions, refer to the
To sort a test plan tree:
1 Click the Sort Folders button on the toolbar. The Sort Folders in Test Plan
Tree dialog box opens.
By default, Sort Folders by Name is selected.
115
2 To create a custom sort, select Custom Sort.
3 Click a subject folder on the left side of the dialog box. The subfolders
appear on the right side.
4 Choose a subfolder on the right side of the dialog box and click the Up or
Down arrow buttons to set the sorting priority for your test plan tree. You
can also drag the subfolder up or down.
5 Click Close to apply the sort order to your test plan tree.
Note: For information on sorting tests in the Test Grid, see “Sorting
Records” on page 36.
116
Modifying a Test Plan Tree
You can rename or delete subject folders and tests in the test plan tree.
Renaming a Folder or Test
You can rename a folder or test.
To rename a folder or test:
1 Select an item from the test plan tree.
2 Click the item. Alternatively, right-click the item and choose Rename.
3 Edit the item name and press Enter or click another location.
Deleting a Folder or Test
You can delete a folder or test from the test plan tree. If you delete a folder,
TestDirector moves all the tests to the Unattached folder in the test plan
tree. If you delete a test, TestDirector deletes the test and the test script
permanently.
To delete a folder:
1 Select a folder from the test plan tree.
2 Click the Delete button, or choose Planning > Delete. Alternatively,
right-click the folder and choose Delete. The Confirm Delete Folder dialog
box opens.
117
3 Select Delete folders only or Delete folders and tests.
4 Click Yes.
To delete a test:
1 Select a test from the test plan tree.
2 Click the Delete button, or choose Planning > Delete. Alternatively,
right-click the test and choose Delete.
Note: You can also delete tests in the Test Grid.
118
12
Linking Tests to Requirements
It is essential that the tests in your test plan meet your original testing
requirements. You create requirements coverage by linking each test in the test
plan tree to one or more requirements in the requirements tree.
➤ Linking Requirements to a Test
➤ Linking Tests to a Requirement
➤ Linking Requirements and Tests Coverage
About Linking Tests to Requirements
The testing process begins by defining your testing requirements in the
requirements tree (see Chapter 8, “Developing the Requirements Tree”). In
the planning stage, you build a test plan tree based on these testing
requirements (see Chapter 11, “Developing the Test Plan Tree”). In order to
keep track of the relationship between your requirements and tests, you add
links between them in TestDirector. As the tests are also linked to defects,
this helps ensure compliance with your testing requirements throughout
the testing process. If a testing requirement changes, you can immediately
identify which tests and defects are affected, and who is responsible.
In the Test Plan module, you create requirements coverage by selecting
requirements to link to a test. Alternatively, in the Requirements module,
you create tests coverage by selecting tests to link to a requirement. A test can
cover more than one requirement, and a requirement can be covered by
more than one test.
119
For example, consider the flight reservation application in the
TestDirector_Demo project. Click the Test Plan tab. In the test plan tree,
under Profiling, expand the Registration folder and select the Phone
(Contact Information) test.
The Phone (Contact Information) test verifies that the customer phone
number is not empty. If you click the Reqs Coverage tab, you can see that
this test covers the following requirement topics: Mercury Tours Application,
Profiling, Application Usability, Correct Error Messages, Profile Management,
Registration, and Customer Personal Information.
120
Chapter 12 • Linking Tests to Requirements
You can also view coverage in the TestDirector_Demo project from the other
direction. Click the Requirements tab. In the requirements tree, under
Profile Management, expand the requirement topic Registration and then
select the requirement Customer Personal Information.
The Customer Personal Information requirement ensures that the flight
reservation system includes personal information about the customer. In the
Tests Coverage tab, you can see that this requirement is covered by the
following tests: Registration, First & Last Name (Contact Information), Phone
(Contact Information), Email (Contact Information), and Mailing Information.
121
Linking Requirements to a Test
During test planning, when you select a test in the test plan tree,
TestDirector displays the test’s requirements coverage in the Reqs Coverage
tab. The coverage grid lists the requirements that are covered by the selected
test. You can add and delete requirements in the coverage grid.
Selected
test
Coverage
grid
Tip: Right-click the coverage grid and choose Show Full Path to display the
location of the requirements in the requirements tree.
The coverage grid contains the following columns:
122
Column
Description
Requirement
The requirement name.
Reviewed
Indicates if the requirement has been reviewed and
approved by the person responsible.
Description
Describes the requirement.
Adding Requirements Coverage
To add requirements coverage to a test, you select a requirement(s) from the
requirements tree.
To add requirements coverage:
1 In the test plan tree, select a test.
2 Click the Reqs Coverage tab.
3 Click the Select Requirements button to show the requirements tree on the
right.
Coverage
grid
Requirements
tree
4 To search for a specific requirement in the tree, type the name (or part of the
name) of the requirement in the Find box and click the Find button. If the
search is successful, TestDirector highlights the requirement in the tree.
5 To refresh a requirement in the tree, select the requirement and click the
Refresh Selected button. To refresh all requirements in the tree, right-click
the requirements tree and choose Refresh > Refresh All.
6 Select a requirement or requirement topic to add to the coverage.
123
If you want coverage to include the requirement’s children, select the
Include Child Requirements into Test Coverage check box.
7 Click the Add to Coverage button. The requirement(s) is added to the
coverage grid.
Tip: You can also define requirements coverage by dragging a requirement
or requirement topic in the requirements tree to the coverage grid.
8 Click the Close button to hide the requirements tree.
Removing Requirements Coverage
You can delete a requirement(s) from a test’s requirements coverage.
To delete requirements coverage from a test:
1 In the test plan tree, select a test.
2 Click the Reqs Coverage tab.
3 Select a requirement(s) from the coverage grid to delete.
4 Click the Remove From Coverage button, and click Yes to confirm.
124
Linking Tests to a Requirement
You can also link tests and requirements using the Requirements module in
TestDirector.
Note: This chapter assumes you are using the Requirements module’s
Coverage view to create tests coverage.
When you select a requirement in the requirements tree, TestDirector
displays the requirement’s tests coverage in the Tests Coverage tab. The
coverage grid lists the tests that cover the selected requirement. You can
view, add, and delete tests in the coverage grid.
Coverage
grid
Selected
requirement
125
The coverage grid contains the following columns:
Column
Description
Name
The test name and a test type icon.
Status
The current execution status of the test.
Execution Date
The date on which the test was last run.
Designer
The name of the test’s designer.
Viewing the Tests Coverage Grid
You can filter the coverage grid, and show or hide full coverage.
➤ To filter the coverage grid by status type, select a status from the Status Filter
list. For example, you can select to view only tests that have passed. Select
All to clear the filter.
➤ To show the tests coverage of all the children of the requirement as well,
check the Full Coverage check box. By default, full coverage is not
displayed.
Adding Tests Coverage
To add tests coverage to a requirement, you select a test(s) from the test plan
tree.
To add tests coverage to a requirement:
1 In the requirements tree, select a requirement. The Tests Coverage tab
displays the coverage grid for the selected requirement.
126
2 In the Tests Coverage tab, click the Select Tests button to show the test plan
tree on the right.
Coverage
grid
Test plan
tree
3 To search for a specific test in the tree, type the name (or part of the name)
of the test in the Find box and click the Find button. If the search is
successful, TestDirector highlights the test in the tree.
4 To refresh a test in the tree, select the test and click the Refresh Selected
button. To refresh all the tests in the test plan tree, select the Subject folder
and click Refresh Selected.
5 Select a test or test folder to add to the requirement’s tests coverage. Click
the Add To Coverage button. The test(s) is added to the coverage grid.
Tip: You can also define tests coverage by dragging a test or test folder in the
test plan tree to the coverage grid.
6 Click the Close button to hide the test plan tree.
127
Removing Tests Coverage
You can delete a test(s) from a requirement’s tests coverage.
To delete tests coverage from a requirement:
2 Select a test(s) from the coverage grid to delete.
3 Click the Remove From Coverage button and click Yes to confirm.
Linking Requirements and Tests Coverage
You can open a requirement listed in the Test Plan module’s Reqs Coverage
tab in the Requirements module. You can also open a test listed in the
Requirements module’s Tests Coverage tab in the Test Plan or Test Lab
modules.
To link to a requirement in the requirements tree:
1 Select a test in the test plan tree, and click the Reqs Coverage tab.
2 In the Requirement column, click the requirement you want to view in the
requirements tree. Alternatively, right-click the requirement, and choose
Find in Requirements Tree.
To link to a test in the test plan tree or a test set:
2 To open a test in the test plan tree, right-click the test in the coverage grid,
and choose Go to Test in Test Plan Tree.
3 To open a test in the Test Lab module, right-click the test in the coverage
grid, and choose Go to Test in Test Set.
128
13
Building Tests
After you create a test plan tree, you are ready to develop the tests by
designing test steps.
➤ Designing Test Steps
➤ Calling a Manual Test with Parameters
➤ Managing Test Steps
About Building Tests
You build tests in the Test Plan module by defining test steps: detailed, stepby-step instructions on how to execute a test. A step includes the actions to
be performed on your application, the input to be entered, 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.
You can create test steps for both manual and automated tests. For a manual
test, you complete test planning and design once you finish creating the
steps. Using your plan, you can begin execution immediately. Automated
tests require that you create an automated test script using a Mercury
Interactive testing tool, or a custom or third-party testing tool.
129
If you decide to automate a test, TestDirector can create an automated test
template based on the test steps you have defined. After evaluating your test
design, you decide whether to automate a test. For further information, see
Chapter 14, “Creating Automated Tests.”
You design steps for a test using the Design Steps tab.
Designing Test Steps
You add steps to a test using the Design Step Editor.
To create a test step:
1 Choose a test in the test plan tree, and click the Design Steps tab.
130
Chapter 13 • Building Tests
2 Click the New Step button or right-click in the Design Steps tab and choose
New Step. The Design Step Editor opens.
The Test Plan module displays a step name in the Step Name box. The
default name is the sequential number of the test step (Step 1 if you are
adding steps to a test for the first time). You can change the name by typing
a different name in the box.
3 Type a Description and Expected Result for the test step. Enter data for any
user-defined field.
4 To insert a parameter, click the Insert Parameter button. For more
information on parameters, see “Calling a Manual Test with Parameters,” on
page 132.
5 To add additional steps, click the New Step button. The next sequential
number appears in the Step Name box.
6 Click Close to close the Design Step Editor and add the step(s).
131
Note: TestDirector saves the steps when you exit the Design Steps tab, not
after each step is added. If you are adding a large amount of text, you can
right-click and choose Save Steps to manually save as you go.
The test steps appear in the Design Steps tab. In the test plan tree, a
footprint appears next to the test icon, indicating that steps were defined
for the test.
7 You can associate an attachment with a test step. An attachment can be a
file, URL, snapshot or system information. To add an attachment to a test
step, select a step and click the Attachments button. For more information,
see Chapter 4, “Adding Attachments.”
Note: You can copy steps from an existing test. For more information, see
“Copying Steps,” on page 138.
Calling a Manual Test with Parameters
In your test design steps, you can include a call to a manual test. When you
run the test, the test steps include the steps from the called test as part of the
test. This is useful, for example, if you have template tests that you want to
reuse in different tests.
In order to increase the flexibility and power of a test, you can add
parameters to the test and to the tests that call it. A parameter is a variable
that replaces a fixed value and can be assigned a value from outside the test
in which it is defined. You can change the value of a parameter in a test
according to the test that is calling it, or for different instances of a test in a
test set.
132
For example, you can create a template test “Login_Template” which logs in
a user with a specific password when you start your application. You need to
call this test at the beginning of each test. In some cases, you will want to
log in as a regular user while in others, you will need to log in as the
administrator. You can therefore create two parameters, <<user name>> and
<<password>>, and change the value according to the type of test that is
calling “Login_Template”. If the most common login is a regular user, you
can set the default values for the parameters to a regular user name and
password.
This section includes the following parts:
➤ Creating a Template Test
➤ Adding a Parameter
➤ Calling a Test with Parameters
Creating a Template Test
You can define any manual test in the test plan tree as a template test. A
template test generally includes parameters and is called by different tests.
Note: Setting a test as a template test is used for filtering purposes only. You
do not need to set a test as a template test in order to be able to call it or add
parameters.
To create a template test:
Right-click a test in the test plan tree, and choose Template Test. A box is
added around the manual test icon to indicate that it is now a template test.
133
Adding a Parameter
You can add a parameter to the description or expected results of a manual
test step.
To add a parameter:
1 In the Design Steps tab, place the cursor in the Description box or Expected
Results box of the step to which you want to add the parameter.
2 Click the Insert Parameter button. The Parameter Properties dialog box
opens.
3 Type a Parameter Name, and click OK. The new parameter is added to the
step using the syntax <<parameter name>>.
Calling a Test with Parameters
You can assign a value to a parameter when you add a call to the manual test
containing the parameter in your design steps.
To call a test with parameters:
1 In the Design Steps tab, click the New Call to Test button. The Select a Test
dialog box opens.
134
2 By default, only template tests are displayed. If you want to choose a test
that is not a template test, clear Show only Template Tests.
3 To search for a specific test in the tree, type the name (or part of the name)
of the test in the Find box and click the Find button. If the search is
successful, TestDirector highlights the test in the tree.
4 To refresh a test in the tree, select the test and click the Refresh Selected
button.
5 Select the manual test with parameters that you want to call. A dialog box
opens, displaying the parameters contained in the test you are calling.
6 In the Value column, type or change the value for each parameter, and click
OK.
7 Click OK in the Select a Test dialog box. The call is inserted as a link in your
design steps, and the values assigned to the parameters in the called test are
displayed.
135
Note: If you do not assign values to parameters when creating a test call,
you will be prompted to do so when you create a test to call your test call,
when you add your test to a test set, or when you run your test.
8 To edit the values you assigned to the parameters in the called test, rightclick the test call and select Called test parameters. Type the new values you
want to assign to the test parameters in the Called Test Parameters dialog
box, and click OK.
9 To use two different parameter values for the same test, create two separate
test calls, assigning two different values to the parameter in the called test.
Managing Test Steps
You can edit, reorder, delete, copy, or renumber the steps in a test. You can
also find and replace text in a step.
Editing Test Steps
You can edit existing test steps or add new ones.
To modify test steps:
136
2 Double-click a step, or select a step and click the Edit Step button. The
Design Step Editor opens.
You can proceed through the steps in a test using the browse buttons:
➤ Click the First Step button to display the first step in the test, or the
Previous Step button to display the preceding step.
➤ Click the Next Step button to display the subsequent step in the test, or
the Last Step button to display the final step in the test.
Tip: You can navigate between steps in the Design Step Editor using shortcut
keys. Use Alt+Home to access the first step, Alt+Left to access the previous
step, Alt+Right to access the next step, and Alt+End to access the last step.
3 Edit step descriptions and expected results by typing in the Description and
Expected Result areas.
137
4 Click the New Step button to add a step after the currently selected step.
5 Click Close to close the Design Step Editor and save your changes.
Reordering Test Steps
You can change the order of the steps in a test.
To reorder test steps:
2 Select the first column (shaded a gray color) of the step you want to move.
The mouse pointer changes to a plus (+) sign.
3 Click and drag the step to the desired position.
Deleting Test Steps
You can remove steps from a test record.
1 In the Design Steps tab, choose the step that you want to delete. To delete
more than one step, press the Ctrl or Shift key and select the first column
(shaded a gray color) of the steps.
2 Click the Delete Selected Steps button. Alternatively, right-click and choose
Delete Selected.
Copying Steps
You can copy design steps from another test in the same project or a
different project.
To copy design steps:
1 Choose the test in the test plan tree from which you want to copy steps, and
click the Design Steps tab.
2 Select the step you want to copy. To copy more than one step, press the Ctrl
or Shift key and select the first column (shaded a gray color) of the steps.
3 Click the Copy Selected Steps button, or right-click and choose Copy
Selected.
138
4 Choose the test to which you want to copy the steps, and click the Design
Steps tab.
5 Click the Paste Steps button, or right-click and choose Paste.
Renumbering Steps
You can renumber your steps after you add, delete, or reorder steps in a test.
2 Click the Renumber Steps button.
Finding and Replacing Step Text
You can search for specific text in the test steps in the Design Steps tab. For a
single step, you can also find and replace specific text in the Design Steps
Editor.
To Find Text in the Design Steps tab:
1 In the Design Steps tab, click the Find Text button. The Find dialog box
opens.
2 In the Find in Field box, select the criterion to search for.
3 In the Value to Find box, select the value of the field you chose.
4 To distinguish between uppercase and lowercase characters, select the Case
Sensitive check box.
5 To search for an exact value, select the Exact Match check box.
6 Click Find Next. TestDirector attempts to locate any steps with the specified
value. If the search is successful, the step is highlighted. If the search is
unsuccessful, an information box opens.
139
To Find and Replace Text in the Design Steps Editor:
1 In the Design Steps Editor, click the Find/Replace Text button. The Replace
dialog box opens.
2 In the Find what box, type the text for which you want to search.
3 To replace the specified text, type the text you want to use as replacement
text in the Replace with box.
4 To search for an exact value, select the Match case check box.
5 Click Find Next. TestDirector attempts to locate the text. If the search is
unsuccessful, an information box opens.
6 Click Replace to replace the first occurrence of the text, or Replace All to
replace all occurrences of the text.
140
14
Creating Automated Tests
Once you have designed test steps, you can use them as a template for
creating an automated test script.
➤ Generating Automated Test Templates
About Creating Automated Tests
Test planning involves deciding which tests to automate. If you choose to
automate tests that you designed with the Test Lab module, you can
generate test scripts and complete them using WinRunner, LoadRunner,
QuickTest Professional, Astra QuickTest, QuickTest Professional for
MySAP.com Windows Client, Astra LoadTest, XRunner, Visual API, or Visual
API-XP.
141
Consider the following issues when deciding whether to automate a test.
Frequency of Execution
Tests that will run with each new version of your application are good
candidates for automation. These include sanity tests which check basic
functionality across an entire application. Each time there is a new version
of the application, you would run these tests to check the stability of the
new version, before proceeding to more in-depth testing.
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
It is also recommended that you 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 has to be repeated a thousand times.
Running the test manually would be extremely impractical. Using
WinRunner, you could create a loop to run a thousand iterations of the test.
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.
142
Chapter 14 • Creating Automated Tests
Generating Automated Test Templates
Once you have created steps for a test, you can generate an automated test
template. A test template is a test script that you can use as a framework for
an automated test.
To generate an automated test template:
1 In the test plan tree, choose the manual test that you want to automate.
2 Click the Design Steps tab and click the Generate Script button.
3 Choose an automated test type to convert to:
Test
Icon
Test Type
Description
WR-AUTOMATED
A test that will be executed by WinRunner,
Mercury Interactive’s functional testing tool for
Microsoft Windows applications.
VAPI-TEST
A test that will be executed by Visual API,
TestDirector’s API execution tool that enables you
to create and execute C Scripts.
LR-SCENARIO
A scenario that will be executed by LoadRunner,
Mercury Interactive’s load testing tool.
QUICKTEST_TEST
A test that will be executed by QuickTest
Professional, Mercury Interactive’s functional
enterprise testing tool; or Astra QuickTest, Mercury
Interactive’s functional enterprise testing tool for
the Web.
ALT-TEST
A test that will be executed by Astra LoadTest,
Mercury Interactive’s load testing tool for Web
applications.
ALT-SCENARIO
A scenario that will be executed by Astra LoadTest,
Mercury Interactive’s load testing tool for Web
applications.
143
Test
Icon
Test Type
Description
QTSAP-TESTCASE
A test that will be executed by QuickTest
Professional for MySAP.com Windows Client,
Mercury Interactive’s functional testing tool for
MySAP.com applications using Windows 95,
Windows 98, Windows 2000, and Windows NT
4.0.
XRUNNER
A test that will be executed by XRunner, Mercury
Interactive’s automated testing tool for X Windows
applications.
VAPI-XP-TEST
A test that is created by Visual API-XP,
TestDirector’s open test architecture API testing
tool. For more information on VAPI-XP tests, see
Appendix A, “Working with VAPI-XP.”
Note: This test type
is not available in
the TestDirector
Standard Edition.
Note: The following test types are only available if you have installed the
appropriate add-in from the TestDirector Add-ins page: QUICKTEST-TEST,
ALT-TEST, XRUNNER, and QTSAP-TESTCASE. For more information on
installing the add-in, see the TestDirector Installation Guide.
The Test Plan module uses the steps of the selected test to create an
automated test template. In the test plan tree, note that the manual test
icon
next to the test you just automated is now replaced with the
automated test icon.
4 Click the Test Script tab to view the test template. Note that if the test is a
WinRunner test, you can attach a different test script to the test by clicking
the Copy From button. The Select Test dialog box opens, enabling you to
select a WinRunner test from the file system.
5 To display your test template in the testing tool for which it is created, click
the Launch button. You can now modify your test accordingly.
144
15
Working with System Tests
Using system tests, you can instruct TestDirector to provide system
information for a machine, capture a desktop image, or restart a computer.
➤ Adding System Tests to a Test Plan Tree
➤ Defining a System Test
➤ Running a System Test
➤ Viewing System Test Results
About Working with System Tests
You can run a system test in order to retrieve a machine’s system
information, view a captured desktop image of a test run on a machine, or
restart a computer. For example, in the Test Set Properties tab, you can
instruct TestDirector to run a system cleanup test that will restart the
machine on which an automated test failed. Alternatively, you can create a
system test to retrieve information about a machine’s resource usage before
or after a test run.
You create a system test by adding a system test to the test plan tree,
defining the test, and adding the test to a test set.
145
Note: To run a system test, you must first install the System Test Remote
Agent Add-in on the machine where the test is to be run. For more
information on TestDirector Add-ins, refer to the TestDirector Installation
Guide.
When running a system test, TestDirector creates the following steps:
➤ For System Information: “SysInfo”
➤ For Capturing a Desktop Image: “Snapshot”
➤ For Restarting a Machine: “Reboot Start” and “Reboot Finish”
You can view details for each of these steps after your system test has
finished running. You can also view the system information that has been
retrieved—such as CPU, memory, and processes running on the machine—
and an image of the machine executing the system test.
Adding System Tests to a Test Plan Tree
You begin creating a system test by adding it to your test plan tree.
To add a system test to a test plan tree:
1 Choose a subject folder in the test plan tree.
2 Click the New Test button, or choose Planning > New Test. The Create New
Test dialog box opens.
3 In the Test Type box, select SYSTEM-TEST.
4 In the Test Name box, type a name for the test, and click OK.
146
Chapter 15 • Working with System Tests
Note: If required test fields were defined in the Project Customization
window, the Required Fields dialog box opens. Select values for the required
fields, and click OK.
The new system test, with the system test icon, appears in the test plan tree
under the subject folder you selected.
5 You can choose to add details and attachments to the test, and define
requirements coverage. For information, see Chapter 11, “Developing the
Test Plan Tree.”
Defining a System Test
Once you have added your system test to the test plan tree, you can define a
test script for the test.
To define a system test:
1 Select the system test you created from the test plan tree, and click the Test
Script tab.
147
2 Select Collect system information to instruct TestDirector to collect machine
system information—such as CPU, memory, and processes running on the
machine—when running a system test.
3 Select Capture desktop image to instruct TestDirector to add an attachment
displaying a snapshot of the computer’s desktop, when running a system
test.
4 Select Restart the computer to instruct TestDirector to restart the machine
when running a system test.
Note: You must enable auto login on the machine where the test is to be run
in order for TestDirector to restart the machine. To enable auto login, select
Start > Programs > TestDirector SystemTest Agent > SystemTest Agent
(configuration). In the Auto Restart Settings dialog box, enter the user
name, password, and domain of the machine on which the test is to be run.
5 Click the Save button to save your system test settings.
After you define your system test in the Test Plan module, you can choose to
add the test to a test set in the Test Lab module. For information on creating
test sets, see Chapter 18, “Creating Test Sets.”
Running a System Test
Once you have defined your system test and added it to a test set in the Test
Lab module, you can instruct TestDirector to run the test. You can run the
system test on your own computer, or on multiple remote host machines
connected to your network.
For more information on running tests, see Chapter 21, “Running Tests
Automatically.”
148
Chapter 15 • Working with System Tests
Viewing System Test Results
You can view the results of your system test in the Test Lab module.
To view system test results:
1 In the Execution Grid, double-click your system test, or select the test and
click the Test Run Properties button. In the Execution Flow tab, right-click
the system test and choose Test Run Properties. The Test Run Properties
dialog box opens, displaying the All Runs tab.
You can view the ID, status, execution date, and execution time for the
following steps that are created during a system test run:
➤ For System Information: “SysInfo”
➤ For Capturing a Desktop Image: “Snapshot”
➤ For Restarting a Machine: “Reboot Start” and “Reboot Finish”
149
2 To view the system information that was collected—such as CPU, memory,
and processes running on the machine—click the Collected System Info
link.
3 To view the captured desktop image of test execution on the machine, click
the Captured Desktop Image link.
150
Part IV
Test Execution
152
16
The Test Lab Workflow
Running tests is the core of the testing process. As your application
constantly changes, you run the manual and automated tests in your
project in order to locate defects and assess quality.
This chapter describes how you run tests using TestDirector. Executing tests
consists of the following stages:
Create Test Sets
Schedule Runs
Run Tests
Automatically
Run Tests
Manually
Analyze Test
Results
153
TestDirector User’s Guide • Test Execution
Creating Test Sets
Start by creating test sets and choosing which tests to include in each set. A
test set is a group of tests in a TestDirector project database designed to
achieve specific testing goals. In the sample flight reservation application,
for example, you could create a set of sanity tests that checks the basic
functionality of the application. You could include tests that check the login
mechanism, and tests that open, create, and fax orders (flight reservations).
For more information, see Chapter 18, “Creating Test Sets.”
Scheduling Test Runs
TestDirector enables you to control the execution of tests in a test set. You
can set conditions, and schedule the date and time for executing your tests.
You can also set the sequence in which to execute the tests. For example,
you can determine that you want to run test2 only after test1 has finished,
and run test3 only if test1 passed.
For more information, see Chapter 19, “Scheduling Test Runs.”
Running Tests Manually
Once you have defined test sets, you can begin executing the tests. 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 application’s
actual results match the expected output.
For example, suppose you are testing the process of booking a flight in the
sample flight reservation application. You open the application, create a
new order, and book a flight, following the instructions detailed by the test
steps.
For more information, see Chapter 20, “Running Tests Manually.”
154
Chapter 16 • The Test Lab Workflow
Running Tests Automatically
Once you have defined test sets, you can begin executing the tests. You can
select all the tests in a test set, or specific tests. Your selection can include
both automated and manual tests.
When you run an automated test, TestDirector opens the selected testing
tool automatically, runs the test, and exports the test results to TestDirector.
When you run a manual test, an e-mail is sent to a designated tester,
requesting him or her to run the manual test.
For more information, see Chapter 21, “Running Tests Automatically.”
Note: You can also run an automated system test to provide system
information, capture a desktop image, or restart a computer. For more
information on running system tests, see Chapter 15, “Working with System
Tests.”
Analyzing Test Results
Following a test run, you analyze test results. Your goal is to identify failed
steps and to determine whether a defect has been detected in your
application, or if the expected results of your test need to be updated. You
can validate test results regularly by viewing run data and by generating
TestDirector reports and graphs. For more information, see Chapter 26,
“Generating Reports” and Chapter 27, “Generating Graphs.”
For more information on understanding the data that appears in
TestDirector following a test run, see Chapter 22, “Viewing Test Results.”
155
156
17
The Test Lab Module at a Glance
This chapter introduces the key elements in TestDirector’s Test Lab module.
➤ The Test Lab Module
➤ The Test Lab Menu Bar
➤ The Test Lab Toolbars
➤ The Execution Grid
➤ The Execution Flow
157
The Test Lab Module
You create test sets and perform test runs in TestDirector by clicking the Test
Lab tab.
Test Lab
menu bar
Test Sets
toolbar
Test Sets
Execution Grid
tab
Execution Flow
tab
Test Set
Properties tab
Test Plan
Tree pane
The Test Lab module contains the following key elements:
➤ Test Lab menu bar, displaying drop-down menus of Test Lab module
commands.
➤ Test Sets toolbar, containing buttons of commands commonly used when
creating and modifying test sets.
➤ Test Sets, listing subsets of tests in a project.
➤ Execution Grid tab, displaying test data in a grid. For more information, see
“The Execution Grid,” on page 161.
➤ Execution Flow tab, displaying test data in a diagram. For more information,
see “The Execution Flow,” on page 164.
➤ Test Set Properties tab, displaying the current test set details, attachments,
notifications, and on failure instructions. For more information, see
Chapter 18, “Creating Test Sets.”
158
Chapter 17 • The Test Lab Module at a Glance
➤ Test Plan Tree pane, displaying the test plan tree in the right window pane to
enable you to add tests to a test set. Note that you can also select Req Test
Coverage to view tests according to the requirements to which they are
linked.
Tip: Right-click a test in the Execution Grid or Execution Flow, and choose
Go to Test in Test Plan Tree to open the Test Plan module and highlight the
selected test in the test plan tree.
The Test Lab Menu Bar
The Test Lab menu bar has the following menus:
➤ The Execution menu contains commands that enable you to run tests, find
tests, arrange tests sequentially, view test run properties, and select tests.
➤ The Test Sets menu contains commands that enable you to manage your
test sets.
the Execution Grid and the Execution Flow.
➤ The Hosts menu contains a command that enables you to add hosts and set
host groups.
execution reports and graphs. For more information on execution reports,
see Chapter 26, “Generating Reports.” For more information on execution
graphs, see Chapter 27, “Generating Graphs.”
159
The Test Lab Toolbars
In the Test Lab module, you can use the Test Sets Toolbar and Test Plan Tree
Toolbar. In addition, you can use the toolbars in the Execution Grid tab and
Execution Flow tab.
Test Sets Toolbar
The Test Sets toolbar has the following buttons. For more information on
test sets, see Chapter 18, “Creating Test Sets.”
New Test Set: Opens the New Test Set dialog box, enabling you to create a
new test set. The test set name is added to the Test Sets list in the left
window pane.
Delete: Removes a test set from the Test Sets list in the left window pane.
Filter/Sort: Includes the following options:
➤ Set: Opens the Filter dialog box, enabling you to filter and sort the Test
Set list.
➤ Refresh: Refreshes the Test Set list so that it displays the most up-to-date
test sets based on the filters you have selected.
➤ Clear: Clears any filters or sorting that you have applied to the Test Set
list.
Test Plan Tree Toolbar
To display the test plan tree in the right window pane, click the Select Tests
button.
The test plan tree toolbar has the following buttons:
Add Tests to Test Set: Adds test(s) to a test set.
Refresh Test Plan Tree: Refreshes the test plan tree.
Find: Searches for a specific test in the tree. If the search is successful,
TestDirector highlights the test in the tree.
Close: Closes the test plan tree in the right window pane.
160
Note: Select View > Req Test Coverage to display the tests coverage of your
requirements in the right window pane, instead of the test plan tree. The
same toolbar is available.
The Execution Grid
TestDirector organizes and displays your test data in a grid. Each line in the
Execution Grid displays a separate test record.
Execution
Grid toolbar
Grid filter
Last Run Results
pane
The Execution Grid tab contains the following key elements:
➤ Execution Grid toolbar, containing buttons of commands commonly used
when executing and viewing tests. See “The Execution Grid Toolbar,” on
page 162.
➤ Grid filter, displaying the filter that is currently applied to a column. To
display grid filters, choose View > Grid Filters.
➤ Last Run Results pane, displaying the results of the last test run. Click the
Show arrow to display the last run results pane.
161
➤ Favorite views, enabling you to Add a view of the Execution Grid to your
Favorites list, View a selected item in the Favorites list, and Organize the
Favorites list. Choose View > Favorites to access the favorite views
commands. For more information on favorite views, see Chapter 5,
“Working with Favorite Views.”
The Execution Grid Toolbar
The Execution Grid toolbar has the following buttons:
Select Tests: Displays the test plan tree in the right window pane. You use
the test plan tree to select tests to add to a test set. Note that you can also
select Req Test Coverage to view tests according to the requirements to
which they are linked.
Run: If you select a manual test, opens the Manual Run dialog box to run
the test. If you select an automated test, opens the Execution dialog box to
run the test. Click the Run arrow and choose Run Manually to run an
automated test manually.
Run Test Set: Opens the Execution dialog box to run the test set. Test sets
can include both manual and automated tests.
the Test Set list.
Test Set list.
Refresh Filter/Sort: Refreshes the Test Set list so that it displays the most upto-date test sets based on the filters you have selected.
determine which columns to display in the Execution Grid and their order.
For more information, see “Arranging Columns,” on page 25.
Test Run Properties: Opens the Test Run Properties dialog box to display the
properties of the selected test.
Remove Test(s) from Test Set: Removes the selected test(s) from the test set.
162
Execution Grid Columns
The Execution Grid displays the following columns, grouped into test
planning data (Plan:) and test run data:
Column
Description
Exec Date
The date on which the test was last executed.
Modified
The date and time of the last change to the test in the
Execution Grid.
Plan: Creation Date
The date on which the test was created. By default, the
creation date is set to the current server date.
Plan: Description
Describes the test.
Plan: Designer
The user name of the person who designed the test.
Plan: Estimated
DevTime
The time estimated to design and develop the test.
Plan: Execution Status
The status of the last test run. Execution status can be
one of the following: Failed, No Run, Not Completed,
Passed.
Plan: Modified
The date and time of the last change to the test in the
Test Plan module.
Plan: Path
The test’s file system path on the server side (relative
to the test repository).
Plan: Status
The planning status of the test. The default status is
Design.
Plan: Steps
The number of steps in the test.
Plan: Subject
The subject folder in the test plan tree in which the
test resides.
Plan: Template
Indicates whether the test is a test template. The value
in this column can be “Y” or “N”.
Plan: Test Name
The name of the test.
Plan: Type
The type of test. For example, manual or WinRunner.
Planned Exec Date
The date on which it was planned to execute the test.
163
Column
Description
Planned Exec Time
The time at which it was planned to execute the test.
Planned Host Name
The name or IP address of the machine to run the test.
Status
The current execution status of the test. Execution
status can be one of the following: Failed, No Run, Not
Completed, Passed.
Test Version
The version number of the test.
Tester
The user name of the person who last executed the
test.
Time
The time at which the test was last executed.
Note: You can change the label of any of the fields in the Execution Grid.
You can also add user-defined fields to the Execution Grid. For more
The Execution Flow
TestDirector organizes and displays your test data as a diagram. The
Execution Flow tab enables you to control the way your tests are executed.
You can specify when and under what conditions you want a test to be
executed.
164
For more information on the Execution Flow tab, see Chapter 19,
“Scheduling Test Runs.”
Execution
Flow toolbar
Execution Flow
diagram
The Execution Flow tab contains the following key elements:
➤ Execution Flow toolbar, containing buttons of commands commonly used
when scheduling test executions. See “The Execution Flow Toolbar,” on
page 166.
➤ Execution Flow diagram, displaying tests with conditions in a diagram. See
“The Execution Flow Diagram,” on page 167.
165
The Execution Flow Toolbar
The Execution Flow toolbar has the following buttons:
Select Tests: Displays the test plan tree in the right window pane. You use
the test plan tree to select tests to add to a test set.
Run: If you select a manual test, opens the Manual Run dialog box to run
the test. If you select an automated test, opens the Execution dialog box to
run the test. Click the Run arrow and choose Run Manually to run an
automated test manually.
Run Test Set: Opens the Execution dialog box to run the test set. Test sets
can include both manual and automated tests.
Find Tests: Opens the Find Test dialog box, enabling you to find a test in the
Execution Flow.
Remove Test(s) from Test Set: Removes the selected test(s) from its test set.
Layout: Rearranges the tests in a hierarchical layout, enabling you to clearly
view dependencies between different tests.
Fit In Window: Redisplays the diagram to fit the window. Click the Fit in
Window arrow to select a magnification option.
Zoom In: Increases the magnification level so that you can view a section of
the Execution Flow more closely.
Zoom Out: Decreases the magnification level so that you can view more of
the Execution Flow.
Drag Time Dependency To Flow: Drag the Drag Time Dependency To Flow
button to a test on the Execution Flow. The default time dependency is the
TestDirector server’s current date and time.
166
The Execution Flow Diagram
The Execution Flow diagram shows the date and time of your test execution,
conditions for your test execution, and the order in which you want your
tests to be executed.
Test set
No condition
arrow
WinRunner test
Condition arrow
Time dependency
The Execution Flow diagram includes the following elements:
➤ Test Set, indicating the test set scheduled for execution.
➤ Test, indicating a test scheduled for execution.
➤ No condition arrow, indicating a test with no conditions.
➤ Condition arrow, indicating a test with conditions.
➤ Time Dependency, indicating a test is date or time-dependent.
167
168
18
Creating Test Sets
You can organize test execution by creating test sets. A test set contains a
subset of the tests in your project. You run a test set in order to achieve a
specific testing goal.
➤ Adding a Test Set
➤ Adding Tests to a Test Set
➤ Setting the Test Set Notifications
➤ Setting the Test Set On Failure Rules
➤ Managing Test Sets
About Creating Test Sets
You run different test sets to address various testing goals throughout the
stages of the quality assurance process. Test sets can include both manual
and automated tests. You can also include the same test in different test sets.
When you run the tests, results are stored separately for the different test
instances.
To decide which test sets to create, think about the testing goals you defined
at the beginning of the testing process. Consider issues such as the current
state of the application and the addition or modification of new features.
169
Following are examples of general categories of test sets you can create:
➤ Sanity set. Checks the entire application at a basic level—focusing on
breadth, rather than depth—in order to verify that it is functional and
stable. This set includes fundamental tests that contain positive checks,
validating that the application is functioning properly. For example, in the
flight reservation application, you could test whether the application opens,
and whether a date can be typed in the Date of Flight text box.
➤ Normal set. Tests the system in a more in-depth manner than the sanity set.
This set can include both positive and negative checks. Negative tests
attempt to crash an application in order to demonstrate that the application
is not functioning properly.
➤ Advanced set. Tests both breadth and depth. This set covers the entire
application, and also tests the application’s advanced options. You can run
this set when there is ample time for testing.
➤ Regression set. Verifies that a change to one part of the application did not
prevent the rest of the application from functioning. A regression set
includes sanity tests for testing the entire application, as well as in-depth
tests for the specific area that was modified.
➤ Function set. Tests a subsystem of an application. This could be a single
feature or a group of features. For example, in the flight reservation
application, a function set could test all activities related to faxing an order,
including selecting the Fax command from a menu, entering a fax number,
previewing, and sending the fax.
170
Chapter 18 • Creating Test Sets
Adding a Test Set
You can add a test set to your project.
To add a test set:
1 Click the New Test Set button or choose Test Sets > New Test Set. The New
Test Set dialog box opens.
2 In the Test Set Name box, type a name for the test set. Note that a test set
name can not include the following characters: \ ^ , "
3 In the Description box, type a description of the test set.
4 Click OK. The test set name is added to the Test Sets list in the left window
pane.
171
5 Click the Test Set Properties tab and select the Details link. Alternatively,
choose Test Sets > Test Set Details.
6 In Open Date, select a date from the calendar. By default, TestDirector
displays the server’s current date.
7 In Close Date, select the planned closing date for the test set.
8 In Status, set the status of the test set to Open or Closed.
9 Click the Attachments link to add an attachment to the test set. An
attachment can be a file, URL, snapshot of your application, an image from
the Clipboard, or system information. For more information on
attachments, see Chapter 4, “Adding Attachments.”
10 Click the Notifications link to instruct TestDirector to send an e-mail to
specified users if certain events occur. For more information, see “Setting the
Test Set Notifications,” on page 175.
11 Click the On Failure link to set rules for the automated tests in the test set in
the event of a test failure. For more information, see “Setting the Test Set On
Failure Rules,” on page 177.
172
Adding Tests to a Test Set
Once you have defined a test set, you can add copies of tests from the
project to the test set.
To add tests to a test set:
1 Select a test set from the Test Sets list.
2 In the Execution Grid tab or Execution Flow tab, click the Select Tests
button. The right window pane displays the test plan tree.
3 Select a folder or test to add to the test set. Note that if you select a folder,
TestDirector adds all the tests in the folder to the test set.
4 Click the Add Tests to Test Set button.
Tip: You can also add tests by dragging a folder or test in the test plan tree to
the Execution Grid or Execution Flow.
173
5 If any of the tests you are adding are already in the test set, the Create Test
Instance dialog box opens.
The list displays the tests that already exist in the test set and how many
instances there are. Select the tests you still want to add to the test set and
click Create.
6 If the test you are adding has unassigned parameters, the Parameters dialog
box opens, enabling you to assign values to the parameters. For more
information on parameters, see “Calling a Manual Test with Parameters,” on
page 132.
The test(s) are added to the Execution Grid or Execution Flow.
7 Click the Close button.
174
Setting the Test Set Notifications
You can instruct TestDirector to send an e-mail to a specified user if any of
the following events occur for a test set:
➤ Any test in the test set fails.
➤ A test in the test set fails due to reasons other than the test logic itself.
Environmental failure could include, for example, function calls not
returning, access violations, version incompatibility between application
components, a missing dll, inadequate permissions, and many other
reasons.
➤ The test set finishes.
To set the test set notifications:
175
2 Click the Test Set Properties tab and select the Notifications link.
Alternatively, choose Test Sets > Notifications.
3 Select one or more events for the test set.
4 To specify who should receive the e-mail, type a valid e-mail address.
Alternatively, click the To button. The Select Recipients dialog box opens.
Note that you can select individual users or an entire user group. Click OK.
For more information on defining user properties, refer to the TestDirector
Administrator’s Guide.
5 In the Message box, type a message for the e-mail.
176
Setting the Test Set On Failure Rules
You can set on failure rules for a test set which instruct TestDirector in the
event that an automated test in the test set fails. This includes instructions
on how many times the test should be rerun, and the clean up test that
should be run before the test is rerun. For any automated test in the test set,
you can change the default on failure rules.
To set the test set on failure rules:
2 Click the Test Set Properties tab and select the On Failure link. Alternatively,
choose Test Sets > On Failure.
3 To set the test set on failure rule, select the first check box and specify the
number of times an automated test should be rerun.
4 To include a clean up test, select the second check box and click the browse
button to select the clean up test from the test plan tree in the Select Clean
Up Test dialog box.
177
5 If you wish to change these rules for any tests in the test set, click the
Settings per test link. The Test Set On Test Failure Rules dialog box opens.
For any test in the test set, you can change the default on failure rules. Click
OK to confirm.
Note: You can also use the Test Run Properties dialog box to set the on
failure rules for a test in a test set. For more information, see Chapter 22,
“Viewing Test Results.”
6 On the final failure of any test in the test set, you can instruct TestDirector
to:
➤ Do nothing.
➤ Stop the test set.
➤ Run the test set again a specified number of times.
178
Managing Test Sets
During the testing process, you can remove tests from a test set, copy test
sets, rename test sets, or delete test sets. You can also delete test run results
from a test set.
Removing Tests from a Test Set
You can remove tests from a test set.
To remove tests from a test set:
1 Select a test set from the Test Sets list. The tests are displayed in the
Execution Grid or Execution Flow.
2 Select the test that you want to remove.
To delete more that one test in the Execution Grid or Execution Flow, press
the Ctrl or Shift key and select the tests you want to remove.
3 Click the Remove Test(s) From Test Set button.
Copying a Test Set
You can copy a test set to any TestDirector project. Note that test run
information is not copied.
To copy a test set:
2 Right-click the test set and choose Copy Test Set.
3 To paste, right-click and choose Paste Test Set.
179
Renaming a Test Set
You can rename a test set in the Test Sets list. Note that you cannot rename
the default test set.
To rename a test set:
2 Choose Test Sets > Rename Test Set.
3 Edit the test set name and press Enter.
Deleting a Test Set
You can delete a test set from a project. Note that you cannot delete the
default test set.
To delete a test set:
2 Click the Delete button, or choose Test Sets > Delete Test Set.
3 Click OK to confirm.
Resetting a Test Set
Resetting a test set changes the status of all the tests in the test set to “No
Run”. When resetting a test set, you can decide if you want TestDirector to
delete all the test run results as well.
To reset the current test set:
2 Choose Test Sets > Reset Test Set. The Confirm Reset Test Set dialog box
opens.
3 To instruct TestDirector not to delete the test run results for the test set, clear
the Delete all the test run results in test set check box.
180
Purging Runs from a Test Set
You can use the Purge Runs wizard to delete old test run results in your
project.
To delete old test run results from test sets:
1 Choose Test Sets > Purge Runs. The Step 1 dialog box opens, enabling you
to select test sets to purge.
Using the arrows, move the appropriate test set name(s) from the Available
Test Sets box to the Selected Test Sets box.
181
2 Click Next. The Step 2 dialog box opens, enabling you to select the purge
type.
By default, TestDirector deletes all the runs in the selected test sets. To
instruct TestDirector to only delete run steps but keep the overall run details,
select Delete only run steps.
182
3 Click Next. The Step 3 dialog box opens, enabling you to define purge
conditions.
Under Delete runs older than, select a period of time before which you want
to delete test run results (for example, 2 weeks).
In Keep last, select a number of test run results to keep for each test. Note
that this option is available only if you selected Delete runs in the Step 2
dialog box.
183
4 Click Next. The Step 4 dialog box opens, summarizing the deletions you
have chosen to make.
5 Click Purge to confirm.
184
19
Scheduling Test Runs
TestDirector enables you to control the execution of the tests in a test set.
➤ Scheduling a Test Run
➤ Modifying a Test Run Schedule
➤ Arranging Tests Sequentially
➤ Finding Tests
➤ Viewing the Execution Flow Diagram
About Scheduling Test Runs
In the Execution Flow, you can specify a date and time, and set conditions
for executing a test. A condition is based on the results of another specified
test in the Execution Flow. By setting conditions, you can instruct
TestDirector 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.
For example, in the New Order test set, you can determine that test2 will run
only after test1 has finished, test3 will run only if test2 passed, and test2 must
run a day before test3.
185
Unlike the Execution Grid, which displays the tests with only test run
information, the Execution Flow displays the tests with conditions in a
diagram.
Note that you can only schedule test runs in the Execution Flow. A test set is
represented by the Test Set
icon. Each test in the diagram is represented
by a test icon. A dashed line
arrow indicates a test with no
conditions. A solid line
arrow indicates a condition and can be
blue or green. If the solid line is blue, it indicates that the condition status is
set to “Finished”. If the solid line is green, it indicates that the condition is
set to “Passed”.
186
Chapter 19 • Scheduling Test Runs
When a test is time-dependent, a Time Dependency
diagram.
icon is added to the
187
Scheduling a Test Run
The Execution Flow enables you to watch the execution process as it
happens, and controls the way your tests are executed. You can specify
under what conditions you want a test to be executed (execution conditions)
and when (time dependency).
To schedule a test run:
1 In the Execution Flow, double-click a test. Alternatively, right-click a test
and choose Test Run Schedule. The Run Schedule of Test dialog box opens
and displays the Execution Conditions tab.
188
2 To add a condition, click New. The New Execution Condition dialog box
opens.
3 In the Test box, select a test on which you want the current test to be
dependent.
➤ Select Finished (default) to instruct TestDirector to execute the current
test only after the specified test has finished executing.
➤ Select Passed to instruct TestDirector to execute the current test only if
the specified test has finished executing and passed.
4 In the Comments box, add any relevant information regarding the
condition.
5 Click OK. The condition is added to the list.
Tip: You can also add a condition directly in the Execution Flow. Click a test
icon (not the test name) and drag the arrow to another test. By default,
TestDirector sets the condition to “Finished”. To change the condition,
double-click the condition arrow. In the Execution Condition dialog box,
select Passed, and click OK.
189
6 Click the Time Dependency tab to specify when you want the test to be
executed.
7 Select Run At Specified Time, and select a Date and/or Time.
Tip: You can schedule the test run date and time by dragging the Drag Time
button to a test. Double-click the icon to set the
Dependency To Flow
time in the Time Dependency of Test dialog box.
8 Click OK to close the Run Schedule of Test dialog box.
In the Execution Flow, the diagram displays the tests and the conditions.
190
Modifying a Test Run Schedule
You can modify and delete conditions and time dependency information for
a test run schedule.
Editing Execution Conditions
You can edit conditions connected to a test’s run.
To edit an execution condition:
1 In the Execution Flow, double-click a condition arrow. Alternatively, rightclick a condition arrow and choose Execution Condition. The Execution
Condition dialog box opens.
2 Modify any relevant information regarding the condition and click OK.
Deleting Execution Conditions
You can delete a condition connected to a test’s run. You can also delete all
the conditions connected to a specific test.
To delete an execution condition:
1 In the Execution Flow, right-click a condition arrow and choose Remove
Execution Condition.
2 Click Yes to confirm. The arrow is removed from the Execution Flow.
191
To delete all execution conditions for a test:
1 In the Execution Flow, right-click a test and choose Remove Test’s Execution
Conditions.
2 Click Yes to confirm. All connecting arrows are removed from the test in the
Execution Flow.
Editing Time Dependency
You can modify the date and time of a scheduled test run.
To edit time dependency:
1 In the Execution Flow, double-click the Time Dependency
icon
connected to a test. The Time Dependency of Test dialog box opens.
2 Modify the date and/or time, and click OK.
Deleting Time Dependency
You can delete a specified date and/or time set to execute a test.
To delete time dependency:
1 In the Execution Flow, right-click a Time Dependency
a test and choose Remove Time Dependency.
icon connected to
2 Click Yes to confirm. The Time Dependency icon is removed from the
Execution Flow.
192
Arranging Tests Sequentially
In the Execution Flow, you can change the execution order of the tests
displayed in the diagram.
To rearrange the test sequence:
1 Press the Shift key and select two or more tests in the Execution Flow.
2 Choose Execution > Arrange Tests Sequentially, or right-click a test and
choose Arrange Tests Sequentially. The Order Tests dialog box opens.
3 Select a test from the list and click the up or down arrow to change the
position of the test in the sequence.
4 Click OK. An execution condition is added for each sequence change.
193
Finding Tests
You can search for a test in the Execution Flow.
To find a test:
1 Click the Find Test button on the toolbar, or choose Execution > Find Test.
The Find Test dialog box opens.
2 In the Value to Find box, type the name (or part of the name) of the test.
The search is not case sensitive.
3 Click Find.
TestDirector attempts to locate the test. If the search is successful, the Search
Results dialog box opens and displays a list of possible matches. Select a
result from the list, and click the Go To button to highlight the test in the
Execution Flow.
194
Viewing the Execution Flow Diagram
TestDirector includes zooming and layout tools to enable you to change the
way the Execution Flow is displayed. You can also copy the Execution Flow
diagram to the Clipboard.
Layout
Click the Arrange Tests Sequentially button to rearrange the tests in a
hierarchical layout. This enables you to clearly view dependencies between
different tests.
Zoom In
Click the Zoom In button to increase the magnification level of the diagram
to make it appear larger.
Zoom Out
Click the Zoom Out button to reduce the magnification level of the diagram
to make it appear smaller.
Fit In Window
Click the Fit in Window button to redisplay the diagram to fit in the
window. You can also click the down arrow to select a magnification option:
➤ Select a specific magnification level, such as 25%, 50%, 150% or 200%.
➤ Select Normal to display the diagram at 100% magnification.
➤ Select Custom Zoom to specify a zoom level. In the Custom Zoom dialog
box, type a zoom level. Click Zoom to display the zoom level.
Copy to Clipboard
Choose View > Copy to Clipboard to copy the Execution Flow diagram to
the Clipboard as a bitmap.
195
196
20
Running Tests Manually
When you run tests manually, you follow the test steps and perform
operations on the application under test. You pass or fail each step,
depending on whether the application’s actual results match the expected
output. You can run both manual and automated tests manually.
➤ Running a Test Manually
➤ Editing the Test Steps
➤ Resuming a Manual Test Run
About Running Tests Manually
You run tests manually by following the test steps you defined during test
planning:
1 Perform operations on the application under test. Follow the instructions
detailed in the test step descriptions.
2 Compare the actual results with the expected results. When performing the
steps, decide whether the application responds according to the expected
results.
3 Assign a pass or fail status to each step, depending on whether or not the
expected results match the actual results.
4 If a step fails, explain how the application actually responded. A test fails if
one or more steps fail.
You can execute tests more than once in the same set. Each execution is
considered a new test run.
197
After test execution is complete, you can view a summary of test results in
TestDirector. The updated status for each test run appears in the Execution
Grid. Results for each test step appear in the Last Run Results pane. You can
view more detailed results from the Test Run Properties dialog box. For more
information on viewing test results, see Chapter 22, “Viewing Test Results.”
Running a Test Manually
When you run a test manually, you follow the test steps and perform
operations on the application under test. You compare the expected results
with the actual outcome and record the results. You can execute a test as
many times as you want. Test results are stored separately for each run. You
can run both manual and automated tests manually.
Note that while executing a test manually you can modify the test steps. For
more information, see “Editing the Test Steps” on page 203
To run a test manually:
1 In the Execution Grid tab or Execution Flow tab, select the test(s) you want
to run manually.
➤ To run a single manual test, select the test and click the Run button. The
Manual Runner dialog box opens. For more information, see page 199.
➤ To run two or more manual tests, select the tests and click the Run
button. The Manual Test Run dialog box opens.
Select Manual Runner and click OK. The Manual Runner dialog box
opens.
198
Chapter 20 • Running Tests Manually
Note that you can also run manual tests automatically. To do so, select
Execution dialog box. For more information, see “Running a Test
Automatically,” on page 206.
➤ To run an automated test(s) manually, select the test(s), click the Run
arrow, and choose Run Manually. The Manual Runner dialog box opens.
2 Under Run Details, you can edit the following run information:
➤ Run Name: The name of the test run.
➤ Tester Name: The user name of the person who executed the test.
➤ Other Information (if applicable): You can add data for user-defined
fields. For more information, refer to the TestDirector Administrator’s
Guide.
199
3 Click the Operating System Info link to display operating system
information. The Operating System Information dialog box opens.
You can edit the following operating system information:
➤ OS: The operating system on the machine where you perform your test
steps. By default, TestDirector displays the operating system on your
client machine.
➤ Service Pack: The operating system service pack.
➤ Build: The operating system build number.
4 Under Test Details, you can view details of the test. Click More to display
the Test Properties dialog box which includes test details and attachments.
For more information on test properties, see Chapter 11, “Developing the
Test Plan Tree.”
5 To add attachments to the test run, click the Attach to Run button. An
the Clipboard, or system information. For more information on
attachments, see Chapter 4, “Adding Attachments.”
6 To end the run at this point, you can click the End of Run button.
TestDirector saves the test run. To cancel the run completely, click the
Cancel button and click Yes to confirm.
7 Click the Exec Steps button to start the test run.
If the test you are running has unassigned parameters, the Parameters dialog
box opens, enabling you to assign values. For more information on
parameters, see “Calling a Manual Test with Parameters,” on page 132.
Note: You cannot assign multiple values to a parameter during a test run.
200
The Manual Runner: Step Details dialog box opens.
In Filter by, you can filter the steps in the test according to the Status
column.
Tip: You can conveniently read each test step and record the results using
the compact view display of this dialog box. To open this display, click the
Compact View button.
8 If there are no test steps, or if you want to make changes to the steps, you
can edit the test steps before you begin executing them. For more
information, see “Editing the Test Steps,” on page 203.
201
9 To view the values of the test parameters, click the Show Parameters button.
The Parameters dialog box opens. For more information on parameters, see
“Calling a Manual Test with Parameters,” on page 132.
10 Open the application under test and execute the first step.
➤ Click Passed if the actual result is the same as the expected result.
TestDirector adds a green check to the step and changes the step status to
Passed. (To pass all the test steps at once, click the Passed arrow and
choose Pass All.)
➤ If the actual result is different than the expected result, type the actual
result in the Actual box and click the Failed button. TestDirector adds a
red X to the step and changes the step status to Failed. (To fail all the test
steps at once, click the Failed arrow and choose Fail All.)
11 Click Add Defect if you detect an application flaw while running the test.
The Add Defect dialog box opens, enabling you to add the defect.
TestDirector automatically creates an association between the test run and
the new defect. For more information, see “Adding New Defects,” on
page 244 and “Viewing an Associated Test,” on page 257.
12 Click Attachments to add attachments to the test step. To add attachments
to the test run, click the Attachments arrow and choose Attach to Run. For
more information on attachments, see Chapter 4, “Adding Attachments.”
13 Perform the next step.
14 Click the End of Run button when you complete the test run.
202
Editing the Test Steps
While executing a test in the Manual Runner: Step Details dialog box, you
can add, delete, or modify test steps. TestDirector allows you to save your
design steps with the changes you make once you have completed executing
the test.
Note: TestDirector allows you to update changes made to called tests in the
current test run only. The called test will not be affected. For more
information on called tests, see “Calling a Manual Test with Parameters” on
page 132.
To edit a test step:
1 Open the Manual Runner: Step Details dialog box. For more information,
see “Running a Test Manually,” on page 198.
2 Click the Add Step button to add a step. TestDirector adds a new step and
assigns it a default step name. You can enter details about the new step in
the Description box.
3 Click the Delete Selected Steps button to delete a selected step or steps, and
click Yes to confirm.
4 Click the End of Run button to close the dialog box. A message box opens.
5 Click Yes to save the test step changes in test planning. Click No to save the
test step changes in the Run step only.
Resuming a Manual Test Run
If a manual test run was paused during execution, you can continue the run
at a later stage.
203
Note: The Continue Manual Run command continues the last run of the
selected test. If you want to resume running a previous run, click the Test
Run Properties button, select the All Runs tab, choose the test run you want
to resume, and click the Continue button.
To resume a manual test run:
1 In the Execution Grid tab or Execution Flow tab, select the test you want to
resume running.
2 Choose Execution > Continue Manual Run. The Manual Runner dialog box
opens for the selected test.
3 Continue running the test.
204
21
Running Tests Automatically
You can run tests automatically, directly from TestDirector. You can choose
to run tests on your computer or on remote hosts.
➤ Running a Test Automatically
➤ Viewing the Execution Log
➤ Setting Up Hosts for Remote Test Execution
➤ Ordering Tests in the Execution Grid
➤ Finding and Replacing Values in the Execution Grid
About Running Tests Automatically
You can run tests automatically on your computer or on multiple remote
hosts. A host is any computer connected to your network on which a testing
tool has already been installed.
You can select the tests you want to run from the Execution Grid tab or
Execution Flow tab. Note that you can select to run all the tests in the test
set, or specific tests, and that you can include both automated and manual
tests. The selected tests are displayed in the Execution dialog box.
tool automatically, runs the test on your local machine or on remote hosts,
and exports the results to TestDirector.
205
When you run a manual test from the Execution dialog box, an e-mail is
sent to a designated tester, a user responsible for running the test, requesting
him or her to run the manual test on a specified host.
Note: You can also run an automated system test to provide system
information, capture a desktop image, or restart a computer. For more
information on running system tests, see Chapter 15, “Working with System
Tests.”
Running a Test Automatically
tool automatically, runs the test, and exports the test results to TestDirector.
When you run a manual test, an e-mail is sent to a designated tester,
requesting him or her to run the manual test.
You can select to run an entire test set or specific tests. Your selection can
include both automated and manual tests. Your selected tests are displayed
in the Execution dialog box.
206
Chapter 21 • Running Tests Automatically
Note: The following should be considered when running tests on remote
hosts:
➤ To run tests on remote hosts, you must first set up hosts in the Host
Manager dialog box. For more information, see “Setting Up Hosts for
Remote Test Execution,” on page 212.
➤ To run the same test concurrently on multiple remote hosts, add multiple
instances of the test to your test set. For more information, see “Adding
Tests to a Test Set,” on page 173.
➤ To run several test sets concurrently on multiple remote hosts, open a
new Execution dialog box instance for each test set. For more
information, see Steps 1 and 2 in the section below.
➤ To enable TestDirector to run WinRunner tests on a remote host, the
remote host must first grant permission. On the remote host, select the
Allow TestDirector to Run Tests Remotely check box in the Environment
tab in WinRunner’s General Options dialog box. For more information,
refer to the WinRunner User’s Guide.
To run tests automatically:
1 In the Test Sets list, select a test set.
2 You can run all the tests in a test set or select specific tests:
➤ To run a test set, in the Execution Grid tab or Execution Flow tab, click
the Run Test Set button or choose Execution > Run Test Set. The
Execution dialog box opens and displays all the tests in the current test
set.
207
➤ To run a selected test(s), in the Execution Grid tab or Execution Flow tab,
select the test(s), and click the Run button or choose Execution > Run.
The Execution dialog box opens and displays the selected test(s).
3 You can run your tests locally or remotely:
➤ To execute the tests locally, select the Run All Tests Locally check box.
➤ To execute the tests remotely, clear the Run All Tests Locally check box.
For each test, you must then select a host machine. Place the mouse
pointer in the Run on Host grid box and click the browse button. The
Select Host dialog box opens. Under <Any Host>, you can select a host to
run the test. Alternatively, you can select a host group. Note that if you
select a host group, TestDirector runs the test on the first available host in
the group, not on every host in the group.
4 You can set conditions and schedule the date and time for executing your
tests. You can also set the order in which you want your tests to be executed.
For more information, see Chapter 19, “Scheduling Test Runs.”
208
5 To instruct TestDirector to create an execution log file during the test run,
select the Enable Log check box. For more information, see “Viewing the
Execution Log,” on page 210.
6 Click Run to run the selected test(s). Click Run All to run all the tests in the
Execution dialog box.
For an automated test, TestDirector opens the selected testing tool
automatically and runs the test. Test execution commences only when the
selected host becomes available to run tests.
For a manual test, TestDirector notifies a designated tester by e-mail to run
the test. Test execution commences only if you designated a tester for the
test. To designate a tester, locate the test in the Execution Grid tab, place the
mouse pointer in the Tester grid box, and click the arrow button. Select a
name from the list.
TestDirector displays the test execution progress in the Status column.
7 If you need to terminate test execution before it has been completed, click
Stop.
8 If you selected Enable Log before you started the test run (see Step 5), you
can view the Execution Log by choosing Run > View Execution Log. For
more information, see “Viewing the Execution Log,” on page 210.
209
9 After the test run is complete, you can view a summary of test results in
TestDirector. The updated status for each test run appears in the Execution
Grid tab. Results for each test step appear in the Last Run Results pane. You
can view more detailed results from the Test Run Properties dialog box. For
more information on test results, see Chapter 22, “Viewing Test Results.”
10 Click Close to close the Execution dialog box.
Viewing the Execution Log
The Execution Log contains details about the executed tests, such as project
name, user name, and test set name. For each test, the log includes the date
and time of the run, the host, and a description of the run.
Note: You can only view the Execution Log if you selected Enable Log in the
Execution dialog box before you executed the test. For more information,
see Step 5 on page 209.
210
To view the Execution Log:
1 After the test run is complete, choose Run > View Execution Log in the
Execution dialog box. The Execution Log dialog box opens.
2 To specify which test to display in the Execution Log, select a test name in
the Filter Test list. Click the Refresh button.
3 To specify which host to display in the Execution Log, select a host name in
the Filter Host list. Click the Refresh button.
4 Click Close to close the Execution Log.
211
Setting Up Hosts for Remote Test Execution
You can run tests on any host connected to your network. Using the Host
Manager dialog box, you can create a list of available hosts for test
execution. You can also organize hosts into groups to be used for a specific
project.
To open the Host Manager dialog box, in the Test Lab module, choose
Hosts > Host Manager.
212
Setting Hosts
You can use the Host Manager dialog box to create and maintain a list of
hosts to run tests, verify which hosts are available to run tests, and remove
selected hosts from running tests.
Adding Hosts to the List of Available Hosts
You can add a host to the list of available hosts.
To add a host:
1 Choose Hosts > Host Manager. The Host Manager dialog box opens.
If no hosts are displayed in the Available Host list, click the Get Net button.
TestDirector scans the Network Neighborhood directory and inserts each
host found into the project database. To synchronize the hosts in your
project database with the hosts in the Network Neighborhood directory,
click the Get Net arrow and select Synchronize Hosts in the Project with
Hosts in the Network. TestDirector adds hosts found in the Network
Neighborhood directory and deletes hosts that were not found in the
Network Neighborhood directory.
2 To add a new host, click the Add button. The Add Host dialog box opens.
3 In the Host Name box, type the name of the host computer.
4 In the Description box, type a description of the host.
5 Click OK. The host name is added to the list of hosts in the Available Hosts
list.
213
Deleting Hosts from the List of Available Hosts
You can delete a host name from the list of available hosts.
To delete hosts:
1 Select the name of a host (or hosts) that you want to delete from the
Available Hosts list in the Host Manager dialog box.
2 Click the Delete button. A message appears confirming your decision.
3 Click Yes. The host is removed from the Available Hosts list.
Setting Host Groups
You can organize hosts into groups to be used for a specific project. In the
Host Manager dialog box, you can create groups, add hosts to groups,
remove hosts from groups, and delete host groups.
Note: If you specify a host group for remote test execution, TestDirector
runs the test on the first available host, not every host in the host group.
Creating Host Groups
You can create a host group for a TestDirector project.
To create host groups:
1 In the Host Manager dialog box, click the Create button. The New Host
Group dialog box opens.
2 In the Group Name box, type a name for the host group.
214
3 In the Description box, type a description of the host group.
4 Click OK. The new group appears in the Host Group list.
Adding Hosts to a Group
Once you have created a host group, you can add hosts to it.
To add host computers to a group:
1 Select a group from the Host Group list in the Host Manager dialog box.
2 Select names of hosts in the Available Hosts list.
3 Click the Add Host to Host Group button. The selected hosts appear in the
Hosts in Group list.
Removing Hosts from a Group
You can remove hosts from a group.
To remove host computers from a group:
2 Select the host names in the group.
3 Click the Remove Host from Host Group button. The host is removed from
the group.
Deleting Host Groups
You can delete host groups from a TestDirector project.
To delete host groups:
2 Click the Delete button. A message opens confirming your decision.
3 Click Yes. The group is deleted from the list.
215
Ordering Tests in the Execution Grid
You can change the order of the tests in the Execution Grid. TestDirector
runs the tests according to the specified order, grouped by host type. For
example, if you have your tests ordered as test1, test2, and test3, TestDirector
runs test1 and test3 first if they are set to run on the same host, followed by
test2 on a different host.
Note: When determining the order for running tests, TestDirector first
checks the Execution Flow. The order you define in the Execution Grid is
only used if there are no conditions set in the Execution Flow. For more
information on scheduling tests in the Execution Flow, see Chapter 19,
“Scheduling Test Runs.”
To order tests in the Execution Grid:
1 Choose View > Order Tests, or right-click a test and select Order Tests. The
Order Tests dialog box opens.
216
2 Select a test from the list, and click the up or down arrow to change the
position of the test in the sequence.
3 Click OK.
Finding and Replacing Values in the Execution Grid
You can search and replace field values in the Execution Grid.
To find a value:
1 Choose Execution > Find, or right-click a row in the Execution Grid and
select Find. The Find dialog box opens.
2 In the Find in Field box, select the criterion for which you want to search.
3 In the Value to Find box, type or select the value of the field you chose.
6 To include wildcards in your search, select Use Wildcard.
7 Click Find Next. TestDirector attempts to locate any tests with the specified
value. If the search is successful, the test is highlighted in the Execution
Grid. If the search is unsuccessful, an information box opens.
217
To replace a value:
1 Choose Execution > Replace, or right-click a row in the Execution Grid and
select Replace. The Find/Replace dialog box opens.
4 In the Replace with box, type or select a replacement field value.
5 Under Match Criteria:
➤ To distinguish between uppercase and lowercase characters, select Case
Sensitive.
➤ To search for an exact value, select Exact Match.
6 Under Options:
➤ Select From Beginning to start the search from the top of the Defects
Grid.
➤ Select Use Wildcard to incorporate wildcards in the search.
7 To replace the found item and find the next occurrence, click Replace.
8 To replace all occurrences of the search criteria in the Execution Grid, click
Replace All.
218
22
Viewing Test Results
After running tests, you analyze the test results to determine which tests
failed, and which steps caused the failure.
➤ Viewing Details of a Test Run
➤ Comparing Results of All Runs
➤ Viewing Configuration of a Test Run
➤ Viewing Test Run Events
➤ Viewing Test Run History
About Viewing Test Results
After running tests, you can view the results in TestDirector. Test results
consist of the overall pass/fail status of a test and the pass/fail status of each
step in a test. These results help you determine whether a defect was
detected in your application. In some cases, you may decide that a step
failed because the expected results are no longer valid and need to be
updated.
Following the execution of manual and automated tests, you can view
results and general test information (status, tester, execution date, etc.) in
the Execution Grid. Use the Test Run Properties dialog box to view test run
details, compare the results of the most recent test run with previous runs,
manage attachments, view test run configuration information, view
automated test run events, and view a history of test run changes.
219
Note: For information on viewing system test results, see Chapter 15,
“Working with System Tests.”
In addition, you can analyze the progress of a test set by periodically
generating execution reports and graphs. For further information, see
Chapter 26, “Generating Reports,” and Chapter 27, “Generating Graphs.”
To open the Test Run Properties dialog box in the Execution Grid, doubleclick a test in the Execution Grid, or select a test and click the Test Run
Properties button. In the Execution Flow tab, right-click a test and choose
Test Run Properties.
The Test Run Properties dialog box contains the following tabs:
220
Tab Heading
Description
Details
Displays run details of a test. For more information, see
“Viewing Details of a Test Run,” on page 221.
All Runs
Display the results of all test runs. For more information,
see “Comparing Results of All Runs,” on page 223.
Attachments
Displays any attachments to a test. Also includes any
attachments that were added to the test during test
planning. For more information, see Chapter 4, “Adding
Attachments.”
Run Configuration
Displays run configuration information for a test. For
more information, see “Viewing Configuration of a Test
Run,” on page 225.
Run Events
Displays the on failure rules for an automated test. For
more information, see “Viewing Test Run Events,” on
page 228.
History
Displays the history of changes to test run fields. For more
information, see “Viewing Test Run History,” on page 229.
Chapter 22 • Viewing Test Results
Viewing Details of a Test Run
You can view run details of a test in the Details tab.
To view test run details of a test:
1 In the Execution Grid, double-click a test, or select a test and click the Test
Run Properties button. In the Execution Flow tab, right-click a test and
choose Test Run Properties.
The Test Run Properties dialog box opens. Click the Details tab.
221
2 In the Details tab, you can view the following test information:
Option
Description
Description
The description of the test.
Status
The current status of the test. A test status can be one of
the following:
No Run: The test has not been run.
Passed: The test run was successful.
Failed: The test run failed.
Not Completed: The test run was not completed.
Tester
The user name of the person who last executed the test.
Exec Date
The date on which the test was last executed.
Exec Time
The time at which the test was last executed.
Planned Host Name
The name or IP address of the machine on which the test
was planned to run.
Planned Exec Date
The date on which the test was planned to be executed.
Planned Exec Time
The time at which the test was planned to be executed.
Note that if you edit the test information, the changes you make are
reflected in the Execution Grid.
Note: You can change the label of any of the fields in the Details tab. You
can also add user-defined fields to the Details tab. For more information,
3 Click Close to exit the Test Run Properties dialog box.
222
Viewing Attachments to a Test Run
You can view attachments added to a test during test planning (although
you cannot delete these attachments) using the Attachments tab. An
the Clipboard, or system information. If a test includes attachments, the
next to the test in the
Test Lab module places a clickable attachment icon
Execution Grid.
Note that you can also use the Attachments tab to add attachments to a test
run. For more information on attachments, see Chapter 4, “Adding
Attachments.”
Comparing Results of All Runs
TestDirector lets you compare the results of a test run with the results of
previous runs. Using the All Runs tab, you can view run details and step
results for all the runs of a selected test.
223
To view results of all runs for a test:
1 In the Test Run Properties dialog box, click the All Runs tab.
2 To view run records with a certain status, choose a status from the View Runs
list.
3 To filter and sort the run records, click the Set Filter/Sort button. For more
information on filtering and sorting, see Chapter 3, “Working with
TestDirector Data.” If you set a filter, the description is displayed above the
grid.
4 To clear any filters or sorting that you have applied to the run records, click
the Clear Filter/Sort button.
5 To refresh the grid so that it displays the most up-to-date runs based on the
filters you have selected, click the Refresh Filter/Sort button.
224
6 To set column appearance and order in the grid, click the Select Columns
button. For more information on the Select Columns dialog box, see
“Arranging Columns,” on page 25.
7 To remove a run from the grid, choose a Run Name in the grid and click
Delete. Click Yes to confirm.
8 To view the test steps of a run, choose a Run Name in the grid and click
Steps. The Steps of Run dialog box opens and displays the step’s description,
expected results, and actual results. For more information on test steps, see
Chapter 13, “Building Tests.”
9 To view defects associated with a manual run, choose a Run Name in the
grid and click Defects. The Associated Defects dialog box opens.
To add a defect, click the Defects arrow and select Add Defect. For more
information on adding defects, see Chapter 25, “Adding and Tracking
Defects.”
10 To continue running a previous run, select a Run Name in the grid and click
Continue.
Viewing Configuration of a Test Run
You can view the parameters for a manual test or a WinRunner test in the
Run Configuration tab.
Note: You can also use the Run Configuration tab to change a test’s
parameters, however your changes will only be implemented in the next
test run.
225
Viewing Manual Test Parameters
You can view the manual test parameters you set in the Design Steps tab of
the Test Plan module. For information on setting manual test parameters
before a test run, see “Calling a Manual Test with Parameters,” on page 132.
To view manual test parameters:
1 In the Test Run Properties dialog box, click the Run Configuration tab.
2 In the Value column, view the value for each parameter. (To change the
value for a parameter, type a new value in the Value column.)
226
Viewing WinRunner Parameters
You can view the parameters in a WinRunner test from the Run
Configuration tab. For more information on configuring parameters in
WinRunner tests, refer to the WinRunner User’s Guide.
To view WinRunner parameters:
1 In the Test Run Properties dialog box, click the Run Configuration tab.
2 View the WinRunner parameter details.
227
Viewing Test Run Events
You can view the on failure rules for an automated test using the Run Events
tab. The on failure rules govern TestDirector’s behavior in the event that the
test fails. This includes the number of times the test should be rerun, and
the clean up test that should be run before the test is rerun.
Note: If you change the on failure rules in the Run Events tab, your changes
will only be implemented in the next test run.
You can also set on failure rules for a test by selecting Test Set > On Failure
and clicking the Settings per Test link. For more information, see “Setting
the Test Set On Failure Rules” on page 177.
To view test run events:
1 In the Test Run Properties dialog box, click the Run Events tab.
228
2 To set the test on failure rule, select the first check box and specify the
number of times the test should be rerun.
3 To include a clean up test, select the Run clean up test check box and click
the browse button. In the Select Clean Up Test dialog box, select the test
from the test plan tree.
Viewing Test Run History
You can view a list of changes made to the test run fields.
To view the history of changes to a test run:
1 In the Test Run Properties dialog box, click the History tab.
229
For each change to the test run, the grid displays the date of the change, the
name of the person who made the change, and the new value.
2 You can specify which fields will be displayed in the grid. In the Field list,
select a field name to view changes made only to that field.
230
Part V
Defect Tracking
232
23
The Defect Tracking Workflow
Locating and repairing application defects efficiently is essential to the
development process. Defects can be detected and added to your
TestDirector project by users in all stages of the testing process. Using
TestDirector’s Defects module, you can report design flaws in your
application, and track data derived from defect records.
This chapter describes how you track defects. This includes adding defects,
determining repair priorities, repairing open defects, testing a new build of
the application, and analyzing defect data.
Add Defects
Review New
Defects
Repair Open
Defects
Test New
Build
Analyze
Defect Data
233
TestDirector User’s Guide • Defect Tracking
Adding Defects
When you find a defect in the application under test, you submit a defect to
the TestDirector project. The project stores defect information in a defect
repository that can be accessed by authorized users, such as members of the
development, quality assurance, and support teams.
For example, suppose you are testing a flight reservation application. You
just ran a test set that checks the Fax Order functions and one of the test
runs revealed a defect in the “Send Signature with order” function. You
would submit a defect to the project. Note that you can associate this new
defect with the test you ran for future reference.
You can also view, update, and analyze defects in the project. For
information on adding defects, see Chapter 25, “Adding and Tracking
Defects.”
Reviewing New Defects
Review all new defects in the project and decide which ones to fix. This task
is usually performed by the quality assurance or project manager. Change
the status of a new defect to Open, and assign it to a member of the
development team. You can also locate similar defects. If duplicate defects
appear in the project, change their status to either Closed or Rejected, or
delete them from the project.
Repairing Open Defects
Fix the Open defects. This involves identifying the cause of the defects, and
modifying and rebuilding the application. These tasks are performed by
application developers. When a defect is repaired, assign it the status Fixed.
For example, suppose the defect detected in the flight reservation
application’s Fax Order functions was repaired in a new application build.
You would update the defect status from Open to Fixed.
234
Chapter 23 • The Defect Tracking Workflow
Testing a New Application Build
Run tests on the new build of the application. If a defect does not recur,
assign it the status Closed. If a defect is detected again, assign it the status
Reopen, and return to the previous stage, “Repairing Open Defects.” This task
is usually performed by the quality assurance or project manager.
For information on running tests, see Chapter 20, “Running Tests
Manually” and Chapter 21, “Running Tests Automatically.”
Analyzing Defect Data
View data from defect reports to see how many defects were repaired, and
how many still remain open. As you work, you can save settings that are
helpful in the defect-tracking process, and reload them as needed. For more
information, see Chapter 5, “Working with Favorite Views.”
Reports and graphs enable you to analyze the progress of defect repairs, and
view how long defects have been residing in a project. This helps you
determine when the application can be released. For more information, see
Chapter 26, “Generating Reports” or Chapter 27, “Generating Graphs.”
235
236
24
The Defects Module at a Glance
This chapter introduces the key elements in TestDirector’s Defects module.
➤ The Defects Module
➤ The Defects Menu Bar
➤ The Defects Toolbar
➤ The Defects Grid
The Defects Module
You track defects in TestDirector by clicking the Defects tab.
Defects menu
bar
Defects toolbar
Grid filter
Defects Grid
Description
tab
History tab
R&D Comments
pane
237
The Defects module contains the following key elements:
➤ Defects menu bar, with drop-down menus of Defects module commands.
➤ Defects toolbar, with buttons of commands commonly used when adding,
managing, and tracking defects.
➤ Grid filter, displaying the filter that is currently applied to a column.
➤ Defects Grid, displaying defect data in a grid. For more information, see “The
Defects Grid,” on page 241.
Note: You can use the Defects Script Editor to restrict and dynamically
change the fields and values in the Defects Grid. For more information, refer
➤ Description tab, displaying a defect’s description.
➤ History tab, displaying a defect’s history. For more information, see “Viewing
Defect History,” on page 254.
➤ R&D Comments pane, allowing you to view and add R&D comments for a
defect. Choose View > R&D Comments to display this pane. For more
information, see “Updating Defects,” on page 250.
Note: To find a specific defect by Defect ID in the Defects Grid, choose
Search > Go To Defect.
238
Chapter 24 • The Defects Module at a Glance
The Defects Menu Bar
The Defects menu bar has the following menus:
➤ The Defects menu contains commands that enable you to add, delete, and
mail defects in the Defects Grid.
➤ The Search menu contains commands that enable you to find and replace
field values, and go to a specific defect in the grid.
the Defects Grid, and view an associated test for a selected defect.
➤ The Analysis menu contains commands that enable you to generate defect
reports and graphs. For more information on defect reports, see Chapter 26,
“Generating Reports.” For more information on defect graphs, see
Chapter 27, “Generating Graphs.”
➤ The Favorites menu contains commands that enable you to view a selected
item in the Favorites list, add a Defects Grid view to your Favorites list, and
organize the Favorites list. For more information on favorite views, see
Chapter 5, “Working with Favorite Views.”
The Defects Toolbar
The Defects toolbar has the following buttons:
Add Defect: Opens the Add Defect dialog box, enabling you to add a new
defect to the Defects Grid.
the defects in the grid.
Defects Grid.
Refresh Filter/Sort: Refreshes the Defects Grid so that it displays the most
up-to-date defects, based on the filters you have selected.
define which columns appear in the Defects Grid, and the order in which
they appear. For more information, see “Arranging Columns,” on page 25.
239
Defect Details: Opens the Defect Details dialog box for the selected defect.
The Defect Details dialog box has four tabs:
➤ Details: Enables you to enter information about the selected defect.
➤ Description: Enables you to enter a detailed description of the defect, and
R&D comments.
➤ Attachments: Enables you to associate an attachment with the defect. An
attachment can be a file, URL, snapshot, an image from the Clipboard, or
system information. For more information, see Chapter 4, “Adding
Attachments.”
➤ History: Enables you to view the history of changes made to the defect.
Attachments: Opens the Defect Details dialog box and displays the
Attachments tab.
Find Similar Defects: Includes the following options:
➤ Find Similar Defects: Conducts a search for similar defects and, if any are
found, displays them in the Similar Defects dialog box.
➤ Find Similar Text: Opens the Find Similar Text dialog box, enabling you
to search for similar defects by specifying a text string and, if any are
found, displays them in the Similar Defects dialog box.
Mail Defects: Opens the Send Mail dialog box, enabling you to send a defect
e-mail to recipients selected from a list, or to any other e-mail address.
Favorites: Includes the following options:
➤ Add to Favorites: Opens the Add Favorite dialog box, enabling you to
save a view and add it to your Favorite list.
➤ Organize Favorites: Opens the Organize Favorites dialog box, enabling
you to manage the Favorite list by renaming, saving as, and deleting
views.
For more information on favorite views, see Chapter 5, “Working with
Favorite Views.”
240
Chapter 24 • The Defects Module at a Glance
The Defects Grid
TestDirector organizes and displays defects data in a grid. Each line in the
Defects Grid displays a separate defect record. The Defects Grid can display
the following columns:
Column
Description
Actual Fix Time
Indicates the actual time, in hours, in which the defect
was fixed.
Assigned To
The user name of the person who is assigned to fix the
defect. Click the down arrow to display a list of user
names.
Closing Date
Indicates the date on which the defect was closed. Click
the down arrow to display a calendar and select a closing
date.
Closed in Version
Indicates the application version in which the defect was
closed. Click the down arrow to display a list of versions.
Defect ID
A unique numeric ID for the defect, assigned
automatically by TestDirector. Note that the Defect ID is
read-only.
Description
Describes the defect in detail.
Detected By
The user name of the person who found the defect. By
default, TestDirector inserts the login user name into this
field.
Detected in Version
Indicates the application version in which the defect
occurs. Click the down arrow to display a list of versions.
Detected on Date
The date on which the defect was detected. By default, the
current server date is displayed. Click the down arrow to
display a calendar and select a different detection date.
Estimated Fix Time
Indicates the estimated time, in hours, required for fixing
the defect.
Modified
Indicates the time this defect was last changed.
Planned Closing
Version
Indicates in which version the defect is planned to be
fixed. Click the down arrow to display a list of versions.
241
Column
Description
Priority
The priority of the defect, ranging from low priority (level
1) to urgent priority (level 5).
Project
The name of the project where the defect occurs. Click the
down arrow to display a list of projects.
R&D Comments
Displays comments about the defect entered by R&D.
Reproducible
Indicates whether the defect can be recreated under the
same conditions by which it was detected. Click the down
arrows to choose Y or N.
Severity
The severity of the defect, ranging from low (level 1) to
urgent (level 5).
Status
The current status of the defect. By default, the status is
New. A Defect status can be one of the following: Closed,
Fixed, New, Open, Rejected, Reopen.
Subject
Indicates the subject folder. Click the down arrow to
display a list of subjects.
Summary
A brief summary of the defect.
Note: You can change the label of any of the fields in the Defects Grid. You
can also add user-defined fields to the Defects Grid. For more information,
242
25
Adding and Tracking Defects
You use the Defects module to add application defects directly to a
TestDirector project. You can then track defects until the application’s
developers and application testers determine that they are resolved.
➤ Adding New Defects
➤ Matching Defects
➤ Updating Defects
➤ Finding and Replacing Values
➤ Viewing Defect History
➤ Mailing Defects
➤ Viewing an Associated Test
➤ Deleting Defects
About Adding and Tracking Defects
Defect records inform members of the application development and quality
assurance teams of new defects discovered by other members. By sharing
defect information, both the application development and defect repair
processes are made faster, more efficient, and more comprehensive. As you
monitor the progress of defect repair, you update the information in your
TestDirector project.
243
Suppose you detected a defect in the sample flight reservation application.
When you initially report the defect to the project database, by default it is
assigned the status New. A quality assurance or project manager reviews the
defect, determines a repair priority, changes its status to Open, and assigns it
to a member of the development team. A developer repairs the defect and
assigns it the status Fixed. You retest the application, making sure that the
defect does not recur. The quality assurance or project manager determines
that the defect is actually repaired, and assigns it the status Closed.
Adding New Defects
You can add a new defect to a TestDirector project at any stage of the testing
process.
Note: You can use the Defects Script Editor to restrict and dynamically
change the fields and values in the Add Defect dialog box. You can also
customize the fields for a specific user group. For more information, refer to
the TestDirector Administrator’s Guide.
244
Chapter 25 • Adding and Tracking Defects
To add a new defect:
1 Click the Add Defect button. The Add Defect dialog box opens.
2 Enter the relevant defect details in the dialog box. Note that you must enter
information in all fields with red labels. For more information on available
fields in the Add Defect dialog box, see Chapter 24, “The Defects Module at
a Glance.”
If you want to clear the data in the Add Defect dialog box, click the Clear
button.
245
Tip: To eliminate duplicate or highly similar defects, click the Find Similar
Defects button at the top of the dialog box before you submit a defect. For
more information, see “Matching Defects,” on page 247.
3 You can add an attachment to your defect:
➤ Click the File button to attach a text file.
➤ Click the URL button to attach a URL.
➤ Click the Snapshot button to capture and attach an image.
➤ Click the System Info button to attach information about your computer.
For more information about adding attachments, see Chapter 4, “Adding
Attachments.”
4 You can check the spelling in the dialog box:
5 Click the Submit button to add the defect to the project. TestDirector assigns
a Defect ID to the new defect.
6 Click Close.
246
Matching Defects
Matching defects enables you to eliminate duplicate or similar defects in
your project. Each time you add a new defect, TestDirector stores lists of
keywords from the Summary and Description fields. When you search for
similar defects, keywords in these fields are matched against other defects.
Note that keywords are more than two characters, and letter case does not
affect your results. The following is ignored by TestDirector: articles (a, an,
the); coordinate conjunctions (and, but, for, nor, or); boolean operators
(and, or, not, if, or then); and wildcards (?, *, [ ]).
Note: You can perform more complicated searches on the Summary field by
defining a filter. For more information, see “Filtering Records,” on page 27.
There are two methods you can use to conduct a search for similar defects:
➤ Find Similar Defects: Compares a selected defect with all other existing
defects in your project. You can conduct a search for similar defects in the
Defects Grid, or before submitting a new defect in the Add Defect dialog
box. See “Finding Similar Defects,” on page 248.
➤ Find Similar Text: Compares a specific text string against all other existing
defects in the Defects Grid. You can limit your results by specifying a
percentage of detected similarity. See “Finding Similar Text,” on page 249.
247
Finding Similar Defects
You can match defects by comparing a selected defect with all other existing
defects in your project. When similar defects are found, they are displayed
according to the percentage of detected similarity.
To find similar defects:
1 In the Defects Grid, select a defect and click the Find Similar Defects button.
Alternatively, in the Add Defect dialog box, before you submit a defect, click
the Find Similar Defects button.
Results are displayed in the Similar Defects dialog box. If no similar defects
are found, a message is displayed.
2 Click Close to close the Similar Defects dialog box.
248
Finding Similar Text
You can match defects by comparing a specific text string with all other
existing defects in your project. You can limit the results of defects found to
those that meet a specific similarity percentage. For example, suppose that
you are searching for defects with the word “Help”. If you limit your results
to 25 percent, the search returns the following results:
If you limit your results to 100 percent, the search returns the following
results:
To find similar text:
1 In the Defects Grid, click the Find Similar Defects arrow and choose Find
Similar Text. The Find Similar Text dialog box opens.
249
2 To limit the results of defects found to those with a minimum similarity,
type a percentage in the Percent of Similarity box. By default, TestDirector
returns defects with a similarity of at least 25 percent.
3 In the Text to Find box, type the text string.
4 Click OK. Results are displayed in the Similar Defects dialog box. If no
similar defects are found, a message is displayed.
Updating Defects
Tracking the repair of defects in a project requires that you periodically
update defects. You can do so directly in the Defects Grid, or in the Defect
Details dialog box.
To update defects:
1 In the Defects Grid, double-click the defect you wish to update.
Alternatively, select the defect and click the Defect Details button. The
Defect Details dialog box opens.
250
You can proceed through the defects in the Defects Grid using the browse
buttons:
➤ Click the First button to display the first defect in the grid, or the
Previous button to display the preceding defect.
➤ Click the Next button to display the subsequent defect in the grid, or the
Last button to display the final defect in the grid.
2 Add or modify information for the selected defect in the Details tab. For
more information on available fields in the Details tab, see Chapter 24, “The
Defects Module at a Glance.”
3 Click the Description tab to type a detailed description of the defect.
To add a new R&D comment, click the Comment button. The Defect
module adds a new section to the R&D Comments box, displaying your user
name and the TestDirector server’s current date.
251
4 Click the Attachments tab to add an attachment to the defect. An
the Clipboard, or system information. The Defects module places a clickable
next to the defect in the Defects Grid. For more
attachment icon
information on attachments, see Chapter 4, “Adding Attachments.”
5 Click the History tab to view the history of changes made to the defect. For
each changed field, the date of the change, the name of the person who
made the change, and the new value are displayed. To view a history of
changes made to a specific field only, select the field from the Field box.
6 Click the Mail Defect button to send an e-mail with the defect details. For
more information on mailing defects, see “Mailing Defects,” on page 255.
7 Click OK to save the changes and return to the Defects Grid.
Finding and Replacing Values
You can search and replace field values in the Defects Grid.
To find a value:
1 Choose Search > Find. The Find dialog box opens.
252
6 Click Find Next. TestDirector attempts to locate any defects with the
specified value. If the search is successful, the defect is highlighted in the
Defects Grid. If the search is unsuccessful, an information box opens.
To replace a value:
1 Choose Search > Replace. The Find/Replace Defect dialog box opens.
4 In the Replace With box, type or select a replacement field value.
5 Under Match Criteria:
➤ Select Case Sensitive to distinguish between uppercase and lowercase
characters.
➤ Select Exact Match to search for an exact value.
6 Under Options:
➤ Select From Beginning to start the search from the top of the Defects
Grid.
➤ Select Use Wildcard to incorporate wildcards in the search.
7 To replace the found item and find the next occurrence, click Replace.
8 To replace all occurrences of the search criteria in the Defects Grid, click
Replace All.
253
Viewing Defect History
You can view a list of changes made to any defect in the Defects Grid.
To view the history of changes to a defect:
1 In the Defects Grid, select a defect.
2 Click the History tab. The history of all the fields is displayed in a grid.
For each change to the defect, the grid displays the date of the change, the
name of the person who made the change, and the new value.
3 To specify the field displayed in the grid, select a field name from the Field
list. Only changes made to the selected field are displayed.
254
Mailing Defects
You can send an e-mail about a defect to another user. This enables you to
routinely inform development and quality assurance personnel about defect
repair activity.
To mail a defect:
1 In the Defects Grid, select a defect(s) and click the Mail Defects button. The
Send Mail dialog box opens.
255
4 In the Items box, you can clear any items you do not want to include in the
e-mail.
5 Choose whether you want to include the Attachments and/or History of the
defect.
256
7 You can check the spelling in the dialog box:
a synonym, antonym or related word for the selected word. You can
8 To edit the e-mail, and send it as plain text instead of HTML format, click
Custom.
Viewing an Associated Test
When relevant, you can view the test associated with a defect in the Defects
Grid. A defect is associated with a test in two ways:
➤ During planning, you can associate a test in the test plan tree or Test Grid
with defect(s) in the Defects Grid. For more information, see “Associating
Defects with a Test,” on page 110. Note that any requirements linked to the
test are also associated with the same defect.
➤ During a manual test run, if you add a defect, TestDirector automatically
creates an association between the test run and the new defect.
257
To view an associated test, select a defect in the Defects Grid and choose
View > Associated Test, or right-click the defect and choose Associated Test.
If the test was associated during planning, the Associated Test dialog box
displays five tabs. If the test was associated during a test run, the Test in Test
Set dialog box displays seven tabs.
➤ The Details tab displays a description of the test. It contains the same
information as the Details tab in the Test Plan module. For more
information, see “Adding Tests to a Test Plan Tree,” on page 104.
➤ The Design Steps tab lists the test steps. It contains the same information as
the Design Steps tab in the Test Plan module. For more information, see
Chapter 13, “Building Tests.”
➤ The Test Script tab displays the test script if the test is automated. It contains
the same information as the Test Script tab in the Test Plan module. For
more information, see “Generating Automated Test Templates,” on
page 143.
258
➤ The Attachments tab displays the attachments that were added to the test. It
contains the same information as the Attachments tab in the Test Plan
module. For more information, see Chapter 4, “Adding Attachments.”
➤ The Reqs Coverage tab displays the requirements covered by the test. It
contains the same information as the Reqs Coverage tab in the Test Plan
module. For more information, see Chapter 12, “Linking Tests to
Requirements.”
➤ The Test Run Details tab displays run details for the test. This tab is only
available if the association was made during a test run. It contains the same
information as the Details tab in the Test Run Properties dialog box in the
Test Lab module. For more information, see “Viewing Details of a Test Run,”
on page 221.
➤ The All Runs tab displays the results of all test runs and highlights the run
from which the defect was submitted. This tab is only available if the
association was made during a test run. It contains the same information as
the All Runs tab in the Test Run Properties dialog box in the Test Lab
module. For more information, see “Comparing Results of All Runs,” on
page 223.
Deleting Defects
You can delete old or duplicate defects from a project. When you delete a
defect, TestDirector will not re-use the Defect ID.
To delete a defect:
1 In the Defects Grid, select a defect to delete.
2 Choose Defects > Delete.
259
260
Part VI
TestDirector Analysis
262
26
Generating Reports
TestDirector reports display information about test requirements coverage,
the test plan, test runs, and defect tracking.
➤ Available Reports
➤ Creating Reports
➤ Customizing Reports
➤ Adding Sub-Reports
➤ Deleting Sub-Reports
About Generating Reports
TestDirector reports help you assess the progress of defining requirements
and tests coverage, the test plan, test runs, and defect tracking. You use
reports to assist in determining testing priorities and defect repair schedules,
and in setting application release dates. You can generate reports at any time
during the testing process.
Reports can be generated from each TestDirector module. You can display
reports using their default settings, or you can customize them. When
customizing a report, you can apply filters and sort conditions, and
determine the layout of the fields in the report. You can further customize
the report by adding sub-reports.
You can save the settings of your reports as favorite views and reload them
as needed. You can also save your reports as text files or HTML documents.
263
TestDirector User’s Guide • TestDirector Analysis
Note: You can also save your grid data as a text file, Microsoft Excel
spreadsheet, Microsoft Word document, or HTML document. You save data
from the main window in the Test Grid, Execution Grid, or Defects Grid. For
more information, see “Saving Data to a File,” on page 38.
Available Reports
TestDirector enables you to generate reports from the Requirements module,
Test Plan module, Test Lab module, and Defects module.
Requirements Module Reports
The following reports are available in the Requirements module:
Report
Description
Standard Requirements
Lists the requirements that appear in the requirements
tree. The following sub-reports are available in this
report:
• Coverage Tests: Lists the coverage test information
for each requirement.
• Associated Defects: Lists the associated defects for
each requirement.
Tabular
Displays the requirements that appear in the
requirements tree in a grid format. The following subreports are available in this report:
each requirement.
264
Chapter 26 • Generating Reports
Report
Description
Requirements with
Coverage Tests
tree with their coverage test information. The
following sub-reports are available in this report:
each requirement.
Requirements with
Coverage Tests and
Steps
tree with their coverage test information. It also
displays the test steps for each coverage test.
The following sub-reports are available in this report:
each requirement.
Requirements with
Associated Defects
tree with their associated defects. The following subreports are available in this report:
each requirement.
265
Test Plan Module Reports
The following reports are available in the Test Plan module:
Report
Description
Standard Test Planning
Lists the tests in the test plan tree. The following subreports are available in this report:
• Coverage Requirements: Lists the coverage
requirement information for each test.
• Design Steps: Lists the design steps for each test.
• Runs: Lists all test runs.
• Associated Defects: Lists the defects that are
associated with each test.
Subject Tree
Lists the tests in the test plan tree by subject. The
• Contained Tests: Lists the tests for each subject.
• Related Defects: Lists related defects for each
subject in the test plan tree.
Tests with Design Steps
Lists the tests that appear in the test plan tree,
including their design steps. The following sub-reports
are available in this report:
266
Report
Description
Tests with Covered
Requirements
Lists the tests that appear in the test plan tree with
their requirements coverage information. The
Tests with Associated
Defects
Lists the tests that appear in the test plan tree with
their associated defects. The following sub-reports are
available in this report:
267
Test Lab Module Reports
The following reports are available in the Test Lab module:
Report
Description
Current Test Set
Lists the tests that appear in the current test set. The
• Runs: Lists the test runs of the current test set.
associated with each test in the current test set.
Cross Test Set
Lists the test sets that appear in the Test Sets list,
without listing their tests. The following sub-reports
• Contained Tests: Lists the test in each test set.
Cross Test Set with
Tests
Lists the test sets that appear in the Test Sets list,
including their tests. The following sub-reports are
available in this report:
• Contained Tests: Lists the test in each test set.
Current Test Set with
Failed Test Runs
Lists tests from the current test set, with “Failed” test
run status. The following sub-reports are available in
this report:
• Runs: Lists all test runs with “Failed” status.
associated with each failed test run.
Cross Test Set with
Failed Test Runs
Lists tests from all test sets, with “failed” test run
status. The following sub-report is available in this
report:
268
Defects Module Reports
The following reports are available in the Defects module:
Report
Description
Standard Defects
Lists the defects that appear in the project. The
• Related Requirements: Lists the requirements that
are associated with each defect.
• Source Test: Lists the tests that are associated with
each defect.
• Source Execution Test: Lists the executed tests that
• Source Run: Lists the test runs that are associated
with each defect.
Tabular Defects
Displays the defects that appear in the project in a grid
format. The following sub-reports are available in this
report:
each defect.
with each defect.
Defects with Associated
Tests and Runs
Lists the defects with their associated tests and test run
results. The following sub-reports are available in this
report:
each defect.
with each defect.
269
Report
Description
Fixed or Rejected
Defects
Lists defects with “fixed” or “rejected” status. The
are associated with each fixed/rejected defect.
each fixed/rejected defect.
with each fixed/rejected defect.
Fixed or Rejected
Defects Detected by
Current User
Lists defects with “fixed” or “rejected” status that were
detected by the current user. The following sub-reports
each fixed/rejected defect.
with each fixed/rejected defect.
Opened Defects
Assigned to Current
User
List defects with “open” status that are assigned to the
current user. The following sub-reports are available in
this report:
are associated with each open defect.
each open defect.
are associated with each open defect.
with each open defect.
270
Creating Reports
You can create a report from any TestDirector module. Depending on the
current TestDirector module, you have different report options. You can use
the default report or customize it to meet your needs.
Tip: You can create a quick report for a single node in a tree, or row in a grid
by selecting the requirement, test, or defect, and choosing Analysis >
Report Selected.
To create a report:
1 Select the TestDirector module from which you want to create a report.
2 Choose Analysis > Reports, and select the type of report you want to create.
For more information on report types, see “Available Reports,” on page 264.
The report opens with default data displayed.
271
3 To customize your report, click the Report Customization link. For more
information, see “Customizing Reports,” on page 272.
4 To print your report, click the Print arrow and choose Current Page or
All Pages. The Print dialog box opens. Change the printer settings if
necessary. Click OK to print.
5 To save your report, click the Save arrow and choose Current Page or All
Pages. The Save Web Page dialog box opens. Change the file name if
necessary. To save the report in its original format, select Web Page,
complete in the Save as type list. To save it as a text file, select Text File.
Click OK to save.
6 To save the settings of your report as a favorite view, click the Add to
Favorites button. For more information, see Chapter 5, “Working with
Favorite Views.”
7 Click Back to close the report and return to the current TestDirector module.
Customizing Reports
You can determine the appearance and contents of your TestDirector
reports.
To customize a report:
1 Select the TestDirector module from which you want to generate a report.
2 Choose Analysis > Reports, and select the report you want to customize. For
more information on report types, see “Available Reports,” on page 264. The
report opens with default data displayed.
272
3 Click the Report Customization link to customize your report. The Report
Customization page opens with the default options displayed.
4 Select a main report or a sub-report in the Reports list. The Report
Customization pane displays the available options.
5 Under Page, you can set the number of items per display page (available for
the main report):
➤ To limit the number of items per page, select Limit items per page to and
specify the number of items per page.
➤ To display all items in one page, select All items in one page.
6 Under Template, you can use TestDirector’s default report template or your
own template. (This option is available for the main report only.)
273
7 Under Filter, you can define or clear filters and sorting priorities:
➤ Click the Set Filter/Sort button to filter and sort your data according to
criteria you choose.
➤ Click the Clear Filter/Sort button to clear all the filters and sorting
priorities.
For more information, see Chapter 3, “Working with TestDirector Data.”
8 Under Fields, you can set the fields you want to appear in the report and
their order.
➤ Select All Fields (auto-layout) to display all fields in the report.
➤ Select Custom Fields (layout), and click the Select Fields button to choose
the fields and set their order. For more information, see “Arranging
Columns,” on page 25.
9 You can also select the following options:
274
Option
Description
Grid View
Displays the report as a grid.
Attachments
Displays a list of associated attachments.
History
Displays a list of all the changes made to a
requirement, test, or defect.
Keep Parent-Child Order
Displays the requirement topic with the subrequirement underneath it. Selecting this option
disables your defined filters and sorting priorities.
(Available only in the Requirements module.)
Show Paragraph Number
Displays the assigned hierarchical numbers to each
requirement in the tree. Note that the numbers are
not related to the unique Req ID assigned to each
requirement. (Available only in the Requirements
module.)
Show Full Coverage
Displays the tests coverage for each requirement in
the tree. (Available only in the Requirements
module if you add the Coverage Tests sub-report.)
Option
Description
Show Steps only for
"Failed" Runs
Displays test steps only for failed test runs. (Available
only in the Test Plan and Test Lab modules if you
add the Runs sub-report.)
Show Test Set Name
Displays the test set name in the test run
information. (Available only in the Test Plan and
Test Lab modules if you add the Runs sub-report.)
10 To add a sub-report, click the Add Sub-Report button. For more
information, see “Adding Sub-Reports.”
11 Click the Generate button to generate a new report.
Adding Sub-Reports
You can further customize your reports by adding sub-reports.
To add a sub-report:
1 Select the TestDirector module from which you want to add a sub-report.
2 Choose Analysis > Reports, and select the report for which you want to
create a sub-report. The report opens with default data displayed.
3 Click the Report Customization link. The Report Customization page opens.
4 Select a main report or a sub-report.
5 Click the Add Sub-Report button. The Add Sub-Report dialog box opens.
6 In the Type list, select a sub-report type. For more information see,
“Available Reports,” on page 264.
7 Click OK. The sub-report is added to the Reports list.
275
Deleting Sub-Reports
You can delete sub-reports from the Reports list.
To delete a sub-report:
1 Select the TestDirector module from which you want to delete a sub-report.
2 Choose Analysis > Reports, and select the report that contains the sub-report
you want to delete. The report opens with default data displayed.
3 Click the Report Customization link. The Report Customization page opens.
4 Select a sub-report in the Reports list.
5 Click the Delete Sub-Report button.
276
27 Generating Graphs
TestDirector graphs let you view images describing the information in a
TestDirector project.
➤ TestDirector Graph Types
➤ Creating Graphs
➤ Customizing Graph Content
➤ Customizing the Graph’s Appearance
➤ Customizing the Graph Description
About Generating Graphs
TestDirector graphs help you draw conclusions quickly and see the
relationships between different types of data in a project. You can create
graphs at any stage of the testing process in order to check the progress of
test requirements, test planning, test execution, and defect tracking for your
application. After you generate a graph, you can customize graph properties
to display information according to your specifications.
277
TestDirector Graph Types
TestDirector enables you to generate graphs from the Requirements module,
Test Plan module, Test Lab module, and Defects module.
Requirements Module Graphs
TestDirector enables you to generate the following graphs from the
Requirements module:
278
Graph
Description
Requirements Summary Graph
Shows how many requirements are currently in a
TestDirector project. For more information, see
“Requirements - Summary Graph” on page 281.
Requirements Progress Graph
Shows how many requirements accumulated in a
TestDirector project at specific points during a period of
time. For more information, see “Requirements - Progress
Graph” on page 282.
Requirements Coverage Graph
Shows how many requirements are currently in a
TestDirector project, according to their test coverage
status. For more information, see “Requirements Coverage Graph” on page 283.
Requirements Trend Graph
Shows the history of changes to specific requirement
fields in a TestDirector project, for each time interval
displayed. For more information, see “Requirements Trend Graph” on page 284.
Chapter 27 • Generating Graphs
Test Plan Module Graphs
TestDirector enables you to generate the following graphs from the Test Plan
module:
Graph
Description
Test Planning Summary Graph
Shows how many tests are currently in a TestDirector
project. For more information, see “Test Planning Summary Graph” on page 285.
Test Planning Progress Graph
Shows how many tests accumulated in a TestDirector
project at specific points during a period of time. For more
information, see “Test Planning - Progress Graph” on
page 286.
Test Planning Trend Graph
Shows the history of changes to specific Test Plan fields in
a TestDirector project, for each time interval displayed.
For more information, see “Test Planning - Trend Graph”
on page 287.
Test Lab Module Graphs
TestDirector enables you to generate the following graphs from the Test Lab
module:
Graph
Description
Test Execution Summary Graph
(Current Test Set)
Shows how many tests in a TestDirector project belong to
the current test set. For more information, see “Test
Execution - Summary Graph (Current Test Set)” on
page 288.
Test Execution Progress Graph
(Current Test Set)
Shows how many tests accumulated in the current test set
at specific points during a period of time. For more
information, see “Test Execution - Progress Graph
(Current Test Set)” on page 289.
279
Graph
Description
Test Execution Summary Graph
(Cross Test Set)
Shows how many tests in a TestDirector project belong to
the all the test sets. For more information, see “Test
Execution - Summary Graph (Cross Test Set)” on
page 290.
Test Execution Progress Graph
(Cross Test Set)
Shows how many tests accumulated in all the test sets at
specific points during a period of time. For more
information, see “Test Execution - Progress Graph (Cross
Test Set)” on page 291.
Defects Module Graphs
TestDirector enables you to generate the following graphs from the Defects
module:
280
Graph
Description
Defects - Summary
Graph
Shows a summary of the number of defects in a
TestDirector project, or the estimated/actual amount of
time taken to fix these defects. For more information, see
“Defects - Summary Graph” on page 292.
Defects - Progress
Graph
Shows the accumulation of defects in a TestDirector
project, or the estimated/actual amount of time taken to
fix these defects, at specific points during a period of time.
For more information, see “Defects - Progress Graph” on
page 293.
Defects - Age Graph
Shows the lifetime of defects in a TestDirector project. For
more information, see “Defects - Age Graph” on page 294.
Defects - Trend
Graph
Shows the history of changes to specific defect fields in a
TestDirector project, for each time interval displayed. For
more information, see “Defects - Trend Graph” on
page 295.
Defect Status Trend
Graph
Shows the history of changes to the “Status” defect field
in a TestDirector project, for each time interval displayed.
For more information, see “Defect Status Trend Graph” on
page 296.
Requirements - Summary Graph
The Requirements - Summary Graph shows how many requirements are
currently in a TestDirector project. The number of requirements is displayed
according to the criteria that you specify. You can specify the type of data
displayed along the x-axis, and the requirement information by which
TestDirector groups the data.
For example, choose Author from the X-Axis list to display the number of
requirements that exist in your project, according to author. Select Priority
from the Grouped By list to group requirements in the graph’s columns
according to their level of priority.
For more information on customizing the Requirements - Summary Graph,
see “Customizing a Summary Graph” on page 299.
Note that by default, the graph appears as a bar chart. To view the graph as a
pie chart, click the Pie Chart tab.
281
Requirements - Progress Graph
The Requirements - Progress Graph shows how many requirements
accumulated in a TestDirector project at specific points during a period of
time. The number of requirements is displayed according to the criteria that
you specify. You can specify the time interval displayed along the x-axis, and
the requirement information by which TestDirector groups the data. You
can also specify whether you want to view the history of the selected data
field, and whether you want to view the number of requirements or the
change in the number of requirements.
For example, choose Cover Status from the Group By list to group the
displayed requirements according to their test coverage status. Select Use
History to view history for the Cover Status field. Under Period, select Last 5
weeks to display this interval along the x-axis. (Note that the graph displays
data measured on the last day of each week.) Under Display Options, select
Regular to view the number of requirements, as opposed to the change in
the number of requirements.
For more information on customizing the Requirements - Progress Graph,
see “Customizing a Progress Graph” on page 300.
Note that the graph can only be viewed as a line chart.
282
Requirements - Coverage Graph
The Requirements - Coverage Graph shows how many requirements are
currently in a TestDirector project, according to their test coverage status.
You can specify the requirement information by which TestDirector groups
the data. For example, select Priority from the Grouped By list to group
requirements in the graph’s columns according to their level of priority.
Note: The Requirements - Coverage Graph is a specific type of summary
graph. If you select a different requirement field from the X-Axis list, a
regular Requirements - Summary Graph is displayed.
For more information on customizing the Requirements - Coverage Graph,
283
Requirements - Trend Graph
The Requirements - Trend Graph shows the history of changes to specific
requirement fields in a TestDirector project, for each time interval displayed.
You specify the field for which you want to view the number of changes,
and the time period for which you want to view data.
For example, choose Cover Status from the Count Changes in Field list to
display the number of changes made to the “Cover Status” requirement
field. Under Period, select Last 5 weeks to display this time period along the
x-axis. (Note that the graph displays a sum of the data measured for each
week.)
For more information on customizing the Requirements - Trend Graph, see
“Customizing a Trend Graph” on page 304.
Note that each status change is only recorded once for the purpose of this
graph. For example, if a field was changed from “Not Completed” to
“Passed” to “Not Completed”, the “Not Completed” status change will only
be recorded once in this graph.
The Requirements - Trend Graph can only be viewed as a bar chart.
284
Test Planning - Summary Graph
The Test Planning - Summary Graph shows how many tests are currently in
a TestDirector project. The number of tests is displayed according to the
criteria that you specify. You can specify the type of data displayed along the
x-axis, and the test plan information by which TestDirector groups the data.
For example, choose Designer from the X-Axis list to display the number of
tests that exist in your project, according to designer. Select Priority from the
Grouped By list to group tests in the graph’s columns according to their
level of priority.
For more information on customizing the Test Planning - Summary Graph,
285
Test Planning - Progress Graph
The Test Planning - Progress Graph shows how many tests accumulated in a
TestDirector project at specific points during a period of time. The number
of tests is displayed according to the criteria that you specify. You can
specify the time interval displayed along the x-axis, and the test plan
information by which TestDirector groups the data. You can also specify
whether you want to view the history of the selected data field, and whether
you want to view the number of tests or the change in the number of tests.
For example, choose Status from the Group By list to group the displayed
tests according to their level of priority. Select Use History to view history for
the Priority field. Under Period, select All days and Show daily info to
display each day along the x-axis. Under Display Options, select Regular to
view the number of tests, as opposed to the change in the number of tests.
For more information on customizing the Test Planning - Progress Graph,
see “Customizing a Progress Graph” on page 300.
286
Test Planning - Trend Graph
The Test Planning - Trend Graph shows the history of changes to specific
Test Plan fields in a TestDirector project, for each time interval displayed.
You specify the field for which you want to view the number of changes,
and the time period for which you want to view data.
For example, choose Status from the Count Changes in Field list to display
the number of changes made to the Test Plan “Status” field. Under Period,
select Last 5 weeks to display this time period along the x-axis. (Note that
the graph displays a sum of the data measured for each week.)
For more information on customizing the Test Planning - Trend Graph, see
graph. For example, if a field was changed from “Ready” to “Repair” to
“Ready”, the “Ready” status change will only be recorded once in this graph.
The Test Planning - Trend Graph can only be viewed as a bar chart.
287
Test Execution - Summary Graph (Current Test Set)
The Test Execution - Summary Graph (Current Test Set) shows how many
tests in a TestDirector project belong to the current test set. The number of
tests is displayed according to the criteria that you specify. You can specify
the type of data displayed along the x-axis, and the test plan and test in test
set information by which TestDirector groups the data.
For example, choose Status from the X-Axis list to display the number of
tests that exist in your project, according to test status. Select Plan: Priority
from the Grouped By list to group tests in the graph’s columns according to
their level of priority.
For more information on customizing the Test Execution - Summary Graph
(Current Test Set), see “Customizing a Summary Graph” on page 299.
288
Test Execution - Progress Graph (Current Test Set)
The Test Execution - Progress Graph (Current Test Set) shows how many
tests accumulated in the current test set at specific points during a period of
time. The number of tests is displayed according to the criteria that you
specify. You can specify the time interval displayed along the x-axis, and the
test plan and test in test set information by which TestDirector groups the
data. You can also specify whether you want to view the number of tests or
the change in the number of tests.
tests according to their status. Under Period, select Last 5 weeks to display
this interval along the x-axis. (Note that the graph displays data measured
on the last day of each week.) Under Display Options, select Regular to view
the number of tests, as opposed to the change in the number of tests.
For more information on customizing the Test Execution - Progress Graph
(Current Test Set), see “Customizing a Progress Graph” on page 300.
289
Test Execution - Summary Graph (Cross Test Set)
The Test Execution - Summary Graph (Cross Test Set) shows how many tests
in a TestDirector project belong to the all the test sets. The number of tests is
displayed according to the criteria that you specify. You can specify the type
of data displayed along the x-axis, and the test plan and test in test set
information by which TestDirector groups the data.
For example, choose Plan:Designer from the X-Axis list to display the
number of tests that exist in your project, according to the test plan
designer. Select Status from the Grouped By list to group tests in the graph’s
columns according to their status.
For more information on customizing the Test Execution - Summary Graph
(Cross Test Set), see “Customizing a Summary Graph” on page 299.
290
Test Execution - Progress Graph (Cross Test Set)
The Test Execution - Progress Graph (Cross Test Set) shows how many tests
accumulated in all the test sets at specific points during a period of time.
The number of tests is displayed according to the criteria that you specify.
You can specify the time interval displayed along the x-axis, and the test
plan and test in test set information by which TestDirector groups the data.
You can also specify whether you want to view the number of tests or the
change in the number of tests.
tests according to their status. Under Period, select Last 5 weeks and Show
daily info to display daily data for this time interval along the x-axis. Under
Display Options, select Regular to view the number of tests, as opposed to
the change in the number of tests.
For more information on customizing the Test Execution - Progress Graph
(Cross Test Set), see “Customizing a Progress Graph” on page 300.
291
Defects - Summary Graph
The Defects - Summary Graph shows a summary of the number of defects in
a TestDirector project, or the estimated/actual amount of time taken to fix
these defects. The information is displayed according to the criteria that you
specify. You can specify the type of data displayed along the x-axis, the type
of data displayed along the y-axis, and the defect information by which
TestDirector groups the data.
For example, choose Assigned To from the X-Axis list to display the number
of defects that exist in your project, according to the people to whom they
are assigned. Select Status from the Grouped By list to group defects in the
graph’s columns according to their status. Under Data Type, select Count to
display the number of defects along the y-axis.
For more information on customizing the Defects - Summary Graph, see
“Customizing a Summary Graph” on page 299.
292
Defects - Progress Graph
The Defects - Progress Graph shows the accumulation of defects in a
TestDirector project, or the estimated/actual amount of time taken to fix
these defects, at specific points during a period of time. The information is
displayed according to the criteria that you specify. You can specify the time
interval displayed along the x-axis, the defect information by which
TestDirector groups the data, and the data displayed along the y-axis. You
can also specify whether you want to view the history of the selected data
field, and whether you want to view the number of defects or the change in
the number of defects.
defects according to their status. Select Use History to view history for the
Status field. Under Data Type, select Count to view the number of defects
along the y-axis, as opposed to the estimated/actual amount of time taken
to fix the defects. Under Period, select Last 5 weeks to display this interval
along the x-axis. (Note that the graph displays data measured on the last day
of each week.) Under Display Options, select Regular to view the number of
defects, as opposed to the change in the number of defects.
For more information on customizing the Defects - Progress Graph, see
“Customizing a Progress Graph” on page 300.
293
Defects - Age Graph
The Defects - Age Graph shows the lifetime of defects in a TestDirector
project. The lifetime of a defect begins when it is reported, and ends when it
is closed. The information in this graph is displayed according to the criteria
that you specify. You can specify the defect information by which
TestDirector groups the data, and the data displayed along the y-axis. You
can also specify the time interval that you want to use to divide the data, if
you want to view graph content in two data columns.
defects according to their status. Under Data Type, select Count to view the
number of defects along the y-axis, as opposed to the estimated/actual
amount of time taken to fix the defects. Under Age Grouping, select No
Grouping to display all of the available age groupings.
For more information on customizing the Defects - Age Graph, see
“Customizing an Age Graph” on page 303.
Note that the age of a “Closed” defect is the difference between the date on
which it was reported and the date on which it was closed. Once a defect is
closed, its age is fixed.
The Defects - Age Graph can only be viewed as a bar chart.
294
Defects - Trend Graph
The Defects - Trend Graph shows the history of changes to specific defect
fields in a TestDirector project, for each time interval displayed. You specify
the field for which you want to view the number of changes, and the time
period for which you want to view data.
For example, choose Priority from the Count Changes in Field list to display
the number of changes made to the “Priority” defect field. Under Period,
select Last 5 weeks to display this time period along the x-axis. (Note that
the graph displays a sum of the data measured for each week.)
For more information on customizing the Defects - Trend Graph, see
Note that each priority change is only recorded once for the purpose of this
graph. For example, if a field was changed from “Urgent” to “Very High” to
“Urgent”, the “Urgent” priority change will only be recorded once in this
graph.
The Defects - Trend Graph can only be viewed as a bar chart.
295
Defect Status Trend Graph
The Defect Status Trend Graph shows the history of changes to the “Status”
defect field in a TestDirector project, for each time interval displayed.
You can specify the time period for which you want to view data. For
example, under Period, select Last 5 weeks to display this time period along
the x-axis. (Note that the graph displays a sum of the data measured for each
week.) You can also click Filter to open the Filter dialog box and filter the
graph content to display only those records meeting the criteria that you
define. For more information on filters, see “Filtering Records,” on page 27.
graph. For example, if a field was changed from “Reopen” to “Fixed” to
“Reopen”, the “Reopen” status change will only be recorded once in this
graph.
The Defect Status Trend Graph can only be viewed as a bar chart.
296
Creating Graphs
You can generate a graph from any TestDirector module. Depending on the
current TestDirector module, you have different graph options. For example,
in Defects, you can generate a graph that displays the number of defects
assigned to each member of a quality assurance team.
To create a graph:
1 Select the TestDirector module from which you want to generate a graph.
2 Choose Analysis > Graphs, and select a graph type. For more information on
graph types, see “TestDirector Graph Types,” on page 278.
Note: You can also use the Graph Wizard to create graphs. Choose
Analysis > Graphs > Graph Wizard.
The graph opens with default data and appearance settings.
Graph display
tabs
Description
tab
Favorite
graphs area
Graph toolbar
Customizing
graph properties
area
297
A graph contains the following key components:
➤ Graph display tabs, displaying the graph as a bar chart, pie chart, line
chart, or data grid.
➤ Description tab, displaying information about the graph.
➤ Favorite graphs area, saving and loading favorite customized graphs.
➤ Graph toolbar, containing the commands you use to display, print,
magnify, and customize graphs.
➤ Customizing graph properties area, enabling you to specify the information
that appears in a graph.
3 Select an available graph display tab:
➤ Bar Chart: Displays the graph as a bar graph.
➤ Pie Chart: Displays the graph as a pie graph.
➤ Line Chart: Displays the graph as a line graph.
➤ Data Grid: Displays the graph as a grid.
4 To further analyze your data, click a segment in the graph. The Drill Down
Results dialog box opens and displays a grid with more details. You can
modify the information in the grid and determine the column appearance
and order. You can also save the contents of a grid as a text file, Microsoft
Excel spreadsheet, Microsoft Word document, or HTML document. For more
information, see Chapter 3, “Working with TestDirector Data.”
5 Customize the graph content. For more information, see “Customizing
Graph Content,” on page 299.
6 To customize the graph title, graph color, and graph display, click the
Set Graph Appearance button. For more graph appearance options, see
“Customizing the Graph’s Appearance,” on page 305.
7 To save your customized graph for future use, click the Add to Favorites
button. For more information, see Chapter 5, “Working with Favorite
Views.”
298
8 If you have saved the graph as a favorite, you can customize the graph
description. For more information, see “Customizing the Graph
Description,” on page 306.
9 Click Back to close the graph and return to the current TestDirector module.
Customizing Graph Content
You can specify what information appears in a graph. This includes
customizing a summary graph, progress graph, age graph, and trend graph.
Customizing a Summary Graph
You can specify the information that appears in a summary type graph.
To customize a summary graph:
1 In the summary graph, choose a field from the X-Axis list to determine the
information displayed along the x-axis of the graph.
2 Choose a field from the Grouped By list to determine the information by
which TestDirector groups data in the graph.
299
3 Under Data Type, you set the y-axis of the graph:
➤ Select Count to display the total number of items (for example, a count
of open defects).
➤ Select Sum of and choose Estimated Fix Time to display the estimated
time required for fixing the defects, or Actual Fix Time to display the
actual time that was spent fixing the defects. (Available only in the
Defects module.)
4 Click the Filter button to open the Filter dialog box and filter the graph
content to display only those records meeting the criteria that you define.
For more information on filters, see “Filtering Records,” on page 27.
5 Click the Refresh button to apply your changes. The new graph is displayed.
Customizing a Progress Graph
You can specify the information that appears in a progress type graph.
300
To customize a progress graph:
1 In the progress graph, choose a field from the Group By list to determine the
information by which TestDirector groups data in the graph.
2 If the selected field includes a history of the values entered, the Use History
check box is enabled. When the check box is selected, the history of the
selected field will be displayed in the graph.
of open defects).
actual time that was spent fixing the defects. (Available only in the
Defects module.)
4 Under Period, select the period of time you want the graph to show.
5 Under Display Options:
➤ Select Regular to view the number of requirements, tests, or defects over
the period of time you selected.
➤ Select Changes over Time to view the change in the number of
requirements, tests, or defects over the period of time you selected. Note
that each record begins at 0.
301
In the graph below, the Regular option is selected. You can view the number
of tests in the Design, Ready, and Repair states for the selected time period.
In the following graph, the Changes over Time option is selected. In
particular, note the change in the number of tests in the Design state over
the selected time period.
302
6 Click Filter to open the Filter dialog box and filter the graph content to
display only those records meeting the criteria that you define. For more
information on filters, see “Filtering Records,” on page 27.
Customizing an Age Graph
You can specify the information that appears in an age type graph. Note that
an age type graph is only available in the Defects module.
To customize an age graph:
1 In the age graph, choose a field from the Group By list to determine the
information by which TestDirector groups data in the graph.
of open defects).
actual time that was spent fixing the defects.
303
3 You can view the graph content in two data columns. When you do this, all
data older than a certain time interval (for example, older than six months)
appears in one column, and all data more recent than that time interval (for
example, less than six months old) appears in the other column.
To view graph content in two data columns, under Age Grouping, select the
time interval that you want to use to divide the data.
Customizing a Trend Graph
You can specify the information that appears in a trend type graph.
304
To customize a trend graph:
1 In the trend graph, choose a field from the Count Changes in Field list to
determine the information for which TestDirector shows changes in the
graph. You can select one field or all fields.
2 Under Period, select the time period you want the graph to show.
Customizing the Graph’s Appearance
You can determine how information appears in the graph using the graph
toolbar. The toolbar includes the following buttons (note that some buttons
may not be available for some graph types):
Show Total Values: Toggles between showing and not showing a total value
in the graph. This option is only available for progress type graphs.
Scroll to the Left: Scrolls the graph to the left. (This button is enabled when
the Zoom In and Zoom Out buttons are in use.)
Scroll to the Right: Scrolls the graph to the right. (This button is enabled
when the Zoom In and Zoom Out buttons are in use.)
Show All: Returns graph to its normal size. (This button is enabled when the
Zoom In and Zoom Out buttons are in use.)
Zoom In: Increases the magnification of the selected portion of the graph.
Zoom Out: Decreases the magnification of the selected portion of the graph.
Rotate Bottom Labels: Toggles between rotating the text on the x-axis
vertically and horizontally.
Set 2D/3D Graph: Toggles the graph from two to three dimensions.
305
Set Graph Appearance: Changes the appearance of the graph. Opens the
Graph Appearance dialog box, enabling you to customize the graph title,
graph color, and graph display.
Copy Graph to Clipboard: Copies the graph as a bitmap to the clipboard.
You can select whether you want to copy the graph in color or
monochrome.
Print Graph: Prints the graph. You can select whether you want to print in
color or monochrome, and whether you want to print the graph
description.
Edit Categories: Enables you to combine categories for graph display (for
example, if the Status field has three categories, “New,” “Open,” and
“Fixed,” you could combine the New and Open categories into a “To Do”
category) in the Edit Categories dialog box. Restore the previous graph
display by selecting Reset Categories.
Customizing the Graph Description
If you have saved your graph as a favorite, you can change the predefined
graph description. You can also add any text you like to the description.
To customize the graph description:
1 Click the Description tab to open the Description pane.
2 The Description pane is divided into two panes. The upper pane contains
information about the graph. You cannot change or add to the text in the
upper pane. The lower pane contains a description of the graph.
Edit the graph description as desired. Your new description is saved
automatically.
306
28
Generating Project Documents
The TestDirector Document Generator enables you to create a Microsoft
Word document containing a project’s requirements, planning, test list, test
execution, and defect tracking data.
Note: The Document Generator is only available from TestDirector if the
following programs are installed on your computer:
➤ Microsoft Word 97 or higher
➤ Microsoft Office 97 Service Release 2 or higher
➤ Launching the Document Generator
➤ Setting Formatting Instructions
➤ Specifying Project Data
➤ Generating a Project Document
307
About Using the Document Generator
The Document Generator enables you to create a hard copy of the data
contained in a TestDirector project. You create the document by performing
the following tasks:
1 Set document format.
2 Specify document content.
3 Generate and edit the document.
First, you set formatting instructions in order to determine how your project
document will look. For example, you can print a company logo on each
page of the document, create a table of contents and an index, and place test
scripts and file attachments in the text of your document.
Next, you specify the project data that will be presented in your document.
You can select information from TestDirector’s modules. For example, from
the Test Plan module, you can choose which folders and tests to include
from the test plan tree, sort this data alphabetically or in a custom sort
order, and display the data as lists or tables.
Once you have set the formatting instructions and specified the document’s
content, you can save the document settings as a favorite view for future use
and generate the document. After document generation is complete, you
can view and edit the document in Microsoft Word for Office 97 or
Microsoft Word for Office 2000. The information for each tab you select will
be printed in a separate chapter of the project document.
308
Chapter 28 • Generating Project Documents
Below is a sample page from a Microsoft Word project document generated
by TestDirector’s Document Generator.
309
Launching the Document Generator
To start the Document Generator, click the purple Tools button on the
upper-right side of the TestDirector window. Choose Document Generator.
The Document Generator opens.
Document
Generator
tree
Options
page
The Document Generator tree displays a number of check boxes. When you
select a check box, the options page for that entry is displayed. You use
option pages to set formatting instructions or select project data to include
in the project document.
310
Setting Formatting Instructions
Before you can generate a document, you set formatting instructions in
order to control how the document will look and what will be included in
the cover page.
To set formatting instructions:
1 Open the Document Generator. By default, the Document Settings tab is
displayed.
Document
check box
2 Type a Title for the document, information about the Author, and a
Description of the document.
311
3 Click the Options tab.
4 Under Include With Document, you can select the following options to
include in the project document:
312
Option
Description
First Page
The cover page of the project document. This displays the
title of the document, the date the document was created,
and the name of the document’s author. You specify this
information in the Document Settings tab.
Table of Contents
A list of all the project document’s sections.
Index
An alphabetical list of all the information in the project
document. The index appears at the end of the document.
5 Under Attachment Options, choose where attachments will appear in the
document. An attachment can be a file, URL, or image.
You can select one of the following options for displaying attachments:
Option
Description
Include in Text
Displays attachments in the main text of the document.
Include in Appendix
Places attachments in a separate appendix.
6 Under Test Script Options, choose where test scripts will appear in your
document:
Option
Description
Include in Text
Displays test scripts in the main text of the document.
Include in Appendix
Places test scripts in a separate appendix.
7 Under Graph Options, choose where graphs will appear in your document:
Option
Description
Include in Text
Displays graphs in the main text of the document.
Include in Appendix
Places graphs in a separate appendix.
8 Clear the Do not generate paragraph if no project information is available
check box if you want to include empty data fields in the project document.
313
9 Click the Logo tab.
You can place an image at the top of each page in the project document. If
you do not select an image, Mercury Interactive’s logo will appear on each
page.
10 Click the Load button. The Open dialog box opens. Use this dialog box to
locate the image. A preview of the image is displayed.
11 Once you have located the image, click the Open button. The image is
displayed in the Logo tab. To remove the image, click Clear.
314
Specifying Project Data
Click a check box in the Document Generator tree to specify project data to
include in your project document.
Check Box
Description
Document
Displays the Document Settings, Options and Logo tabs,
enabling you to set formatting instructions. For more
information, see “Setting Formatting Instructions,” on
page 311. Note that this option is always selected.
Requirements
Specify which requirements and tests coverage to include
from the Requirements module. For more information,
see “Specifying Requirements Module Data,” on page 316.
Subject Tree
Specify which test plan tree folders to include from the
Test Plan module.
Subject Tests: Specify which tests to include from the
selected folders.
For more information, see “Specifying Test Plan Module
Data,” on page 318.
Tests List
Specify which tests to include from the Test Grid. For
more information, see “Specifying Test Grid Data,” on
page 322.
315
Check Box
Description
Execution
Specify which test sets to include from the Test Lab
module.
Tests: Specify which tests to include from the selected test
sets.
Runs: Specify which test runs to include from the selected
tests in a test set.
For more information, see “Specifying Test Lab Module
Data,” on page 325.
Defects
Specify which defects to include from the Defects tab. For
more information, see “Specifying Defects Module Data,”
on page 330.
Specifying Requirements Module Data
You use the Requirements page to specify the test requirements information
from the Requirements module that should appear in the Requirements
section of the TestDirector document.
316
To specify Requirements module data:
1 Select the Requirements check box in the Document Generator tree. The
Requirements page is displayed.
2 In the Advanced Filter/Sort box, choose one of the following options:
Option
Description
All Requirements
Includes all the test requirements from the requirements
tree.
By Status
Includes only requirements with the selected status.
Selected
Includes only selected requirements. Click the Filter &
Sort button to specify the criteria for selecting
requirements. For more information on using the Filter
dialog box, see Chapter 3, “Working with TestDirector
Data.”
317
3 In the Requirements Layout box, choose one of the following options:
Option
Description
Full Page
Displays a list of the selected requirements.
Coverage
Displays a table of the selected requirements and their
coverage status. Click the Customize button to customize
the table. Use the Tabular Layout dialog box to choose the
columns that will appear in the table, and set the column
order, width, and captions.
4 If you selected the Full Page Requirements Layout, check Include Coverage
to include tests coverage for the requirements.
5 Check Include Graphs, and select graph(s) from the list to include in the
project document. Note that only the graphs you saved as favorites are
included in the list. For more information on favorite views, see Chapter 5,
Specifying Test Plan Module Data
You use the Subject Tree and Subject Tests pages to specify the test planning
information from the Test Plan module that should appear in the Plan Tests
section of the TestDirector document.
318
To specify Test Plan module data:
1 Select the Subject Tree check box in the Document Generator tree. The
Subject Tree page is displayed.
319
2 In the Tree Sort box, determine the order of the test plan tree information
in your document:
Option
Description
Alphabetical
The contents of the folders will be organized according to
the alphabetical order of the folders in the test plan tree.
For example, suppose the test plan tree contains two
folders, Automated Tests and Manual Tests. The tests in
the Automated Tests folder will be printed before the tests
in the Manual Tests folder.
Custom
The contents of the folders will be organized according to
the custom sort order you set for displaying test plan tree
folders. By default, subject folders in the test plan tree
appear in alphabetical order (by name). For example,
suppose the test plan tree contains two folders,
Automated Tests and Manual Tests. You can create a sort
order that prints the tests in the Manual Tests folder
before the tests in the Automated Tests folder. For more
information about creating a custom sort order for the test
plan tree, see Chapter 11, “Developing the Test Plan Tree.”
3 In the Folders box, choose which of the test plan tree folders will appear in
the document:
Option
Description
All
Includes all the folders in the test plan tree.
Selected
Includes only the folders you choose from the test plan
tree. You select the folders from the test plan tree
displayed on the right side of the Subject Tree page.
4 Clear the Include Attachments option to exclude all folder attachments
from your document. Folder attachments are files that have been associated
with the folder, such as text files, images, or URLs.
320
6 Expand Subject Tree in the Document Generator tree, and select the Subject
Tests check box. The Subject Tests page is displayed.
7 In the Tests box, determine the tests you want to include in the document:
Option
Description
All Tests
Includes all the tests from the selected test plan tree
folders.
Selected
Includes only selected tests. Click the Filter and Sort
button to specify the criteria for selecting tests. For more
information on using the Filter dialog box, see Chapter 3,
“Working with TestDirector Data.”
321
8 Check the Include Design Steps option to include design steps from the test.
In the Design Steps Layout box, specify how design steps will be organized:
Option
Description
Full Page
Displays a list of all the design steps in a test.
Tabular
Displays all the design steps in a test as a table. Click the
Customize button to customize the table. Use the Tabular
Layout dialog box to choose the columns that will appear
in the table, and set the column order, width, and
captions.
9 Clear the Include Test Scripts check box to exclude test scripts from the
document.
10 Clear the Include Tests History check box to exclude the History table from
your document. This is a list of all the changes made to the tests, as well as
the names of the people who made these changes.
11 Clear the Include Tests Attachments check box to exclude test attachments
from your document.
Specifying Test Grid Data
You use the Tests List page to specify the tests from the Test Grid that should
appear in the Tests section of the TestDirector document. For more
information about the Test Grid, see Chapter 3, “Working with TestDirector
Data.”
322
To specify Test Grid data:
1 Select the Tests List check box in the Document Generator tree. The Tests
List page is displayed.
Option
Description
All Tests
Includes all the tests from the Test Grid.
Selected
323
3 In the Tests Layout box, specify how the tests will be organized:
Option
Description
Full Page
Displays a list of all the tests in the project.
Tabular
Displays all the tests as a table. Click the Customize
button to customize the table. Use the Tabular Layout
dialog box to choose the columns that will appear in the
table, and set the column order, width, and captions.
4 If you selected Full Page Tests Layout, check the Include Design Steps option
to include design steps from the test.
In the Design Steps Layout box, specify how design steps will be organized:
Option
Description
Full Page
Displays a list of all the design steps in a test.
Tabular
Displays all the design steps in a test as a table. Click the
captions.
5 Clear the Include Test Scripts check box to exclude test scripts from the
document.
6 Clear the Include Tests History check box to exclude the History table from
your document. This is a list of all the changes made to the tests, as well as
the names of the people who made these changes.
7 Clear the Include Tests Attachments check box to exclude test attachments
from your document.
324
Specifying Test Lab Module Data
You use the Execution, Execution Tests, and Execution Runs pages to specify
the test execution information from the Test Lab module that should appear
in the Run Tests section of the TestDirector document.
To specify Test Lab Module data:
1 Select the Execution check box in the Document Generator tree. The
Execution page is displayed.
2 Select a test set in the Available Test Sets list and click the > button. The test
set is moved from the Available Test Sets list to the Selected Test Sets list.
To move all the tests to the Selected Test Sets list, click the >> button.
To filter the list of available test sets, click Selected and then click the Filter
and Sort button. For more information on using the Filter dialog box, see
Chapter 3, “Working with TestDirector Data.”
325
3 To remove a test set, select a test set in the Selected Test Sets list and click
the < button. The test set is moved from the Selected Test Sets list to the
Available Test Sets list.
To move all the tests to the Available Test Sets list, click the << button.
5 Double-click Execution in the Document Generator tree and select the Tests
check box. The Execution Tests page is displayed.
326
Option
Description
All Tests
Includes all the tests in the selected test set.
Selected
7 In the Tests Layout box, specify how the tests will be organized:
Option
Description
Full Page
Displays test information as a list.
Tabular
Displays test information as a table. Click the Customize
Note: If you select Tabular, you cannot include test runs
in the document.
8 If you selected Full Page Tests Layout, you can also set the following options:
Option
Description
Include Test Scripts
Includes test scripts in the text of your document.
Include Tests History
Displays a list of all the changes made to the tests, and
who made them.
Include Attachments
Includes test run attachments in the text of your
document.
Include Graphs
Includes the selected graph(s) in your document. Note
that only the graphs you saved as favorites are included in
the list. For more information on favorite views, see
Chapter 5, “Working with Favorite Views.”
327
9 Double-click Execution in the Document Generator tree, double-click Tests,
and select the Runs check box in the Document Generator tree. The
Execution Runs page is displayed.
Note: This section is not available if you chose Tabular Tests Layout in the
Tests section.
328
10 In the Runs box, choose one of the following options:
Option
Description
Last Run
Includes only the last run of the test.
All Runs
Includes all runs of the test.
Selected
Includes only selected runs in the document. Click the
Filter and Sort button to specify the criteria for selecting
tests. For more information on using the Filter dialog box,
see Chapter 3, “Working with TestDirector Data.”
11 In the Runs Layout box, choose one of the following options:
Option
Description
Full Page
Displays a list of all the test runs.
Tabular
Displays all the test runs as a table. Click the Customize
12 If you selected Full Page Runs Layout, you can select the Include Run Steps
option. This option allows you to include lists of run steps in your
document.
In the Run Steps Layout box, choose one of the following options:
Option
Description
Full Page
Displays a list of all the steps in a run.
Tabular
Displays all the steps in a run as a table. Click the
captions.
329
Specifying Defects Module Data
You use the Defects page to specify the defect information from the Defects
module that should appear in the Track Defects section of the TestDirector
document.
To specify Defects module data:
1 Select the Defects check box in the Document Generator tree. The Defects
page is displayed.
2 In the Defects box, choose one of the following options:
330
Option
Description
All Defects
Includes all the defects from the Defects Grid.
Selected
Includes only selected defects. Click the Filter and Sort
button to specify the criteria for selecting defects. For
more information on using the Filter dialog box, see
Chapter 3, “Working with TestDirector Data.”
3 In the Defects Layout box, choose one of the following options:
Option
Description
Full Page
Displays all the selected defects as a list.
Tabular
Displays all the selected defects as a table. Click the
in the table, set the column order, width, and captions.
4 If you selected the Full Page Defects Layout, you can also set the following
options:
Option
Description
Include Defects
History
Displays a list of all the changes made to the defects.
Include Defects
Attachments
Includes defect attachments in the text of your document.
Include Graphs
Includes the graph(s) you select from the list in the
project document. Note that only the graphs you saved as
favorites are included in the list. For more information on
favorite views, see Chapter 5, “Working with Favorite
Views.”
331
Generating a Project Document
After you set formatting instructions and specify project data, you can
generate the project document. You save the document as a Microsoft Word
file. Note that Word must be closed before you generate.
To generate a document:
1 Click the Full Document button. The Save As dialog box opens.
2 In the Save in box, set the location for the document in your network file
system.
3 In the File name box, assign the document a name.
4 In the Save as type box, verify that Word Documents is selected.
5 Click the Save button.
TestDirector begins generating the document and a dialog box displays the
document creation progress.
➤ Click the Hide in Tray button to hide the progress dialog box. You can
redisplay the progress dialog box by double clicking the Document
Generator icon
in the system tray.
➤ Click the Stop button to cancel the document generation.
When the process is complete, Microsoft Word opens and displays the
document.
Tip: You can generate a preview project document that enables you to
quickly see how the document will look, without all the detail included. To
generate a snapshot project document, click tIm2
3 Td(
DoQEMC/P
ena)Tj0 Tct62(
<</MCID
d)Td(n)Tj0.6627
eeTn
0 Td(t)Tj0.37
Go to Test in Test Plan Tree command, Test
Lab module 159
Go to Test in Test Set command, Test Plan module 94
Graph Appearance dialog box 306
graph appearance, customizing 305
graphs 277–306
Bar Chart tab 298
creating 297
customizing appearance 305
customizing content 299
customizing description 306
Data Grid tab 298
Defect Status Trend Graph 296
Defects - Age Graph 294
Defects - Progress Graph 293
Defects - Summary Graph 292
Defects - Trend Graph 295
Line Chart tab 298
Pie Chart tab 298
Requirements - Coverage Graph 283
Requirements - Progress Graph 282
Requirements - Summary Graph 281
Requirements - Trend Graph 284
Test Execution - Progress Graph (Cross Test Set) 291
Test Execution - Progress Graph (Current Test Set) 289
Test Execution - Summary Graph (Cross Test Set) 290
Test Execution - Summary Graph (Current Test Set) 288
Test Planning - Progress Graph 286
Test Planning - Summary Graph 285
Test Planning - Trend Graph 287
toolbar 305
types 278
grid filter box 29
Grid Filters command 29
Grouped By list 299, 301, 303
366
H
Help button 17
Help button, common toolbar 18
Hide in Tray button, Document
Generator 332
history
clearing 21
displaying in graphs 301
History tab
Defects Grid 238, 254
requirements tree 71
Test Grid 97
Test Run Properties dialog box 229
Home button 18
Host Group list 212
Host Manager 212–215
hosts 212–215
adding 213
adding host group 214
adding to a group 215
definition 205
deleting 214
deleting host groups 215
host group definition 214
removing from group 215
Hosts menu, Test Lab module 159
HTML document, saving data as 38
I
images, attaching 43
importing to TestDirector
from Excel 12
from Word 11
Insert Parameter button 134
Installation Guide x
Index
L
Last Run Results pane, Execution Grid 161
Launch button 144
Line Chart tab, graphs 298
load testing 88
LoadRunner Scenario, test type
definition 105
Login button 16
Logo tab, Document Generator 314
Logout button 16
M
Mail Defects button 255
Mail Requirement button 72
Mail Selected Test(s) button, Test
Grid 98, 112
Manual Runner - Step Details dialog box 201
Manual Runner dialog box 199
manual tests, running 197–204
Manual, test type definition 105
Mercury Interactive on the Web xi
Microsoft Access database 10
Microsoft Excel, exporting from 12
Microsoft SQL database 10
Microsoft Word
exporting from 11
generating project documents 332
Modified
Defects Grid 241
Execution Grid 163
Test Grid 99
More link 200
N
Name
Tests Coverage tab 126
New Call to Test button 134
New Child Requirement button 68
New Execution Condition dialog box 189
New Folder dialog box 103
New Host Group dialog box 214
New Requirement button 66, 68
New Step button 131
New Test button 105
New Test Set button 171
New Test Set dialog box 171
No Run requirement status 62
Normal magnification level 195
normal test set 170
Not Completed requirement status 62
Not Covered requirement status 62
Notifications link 176
Numeration command, requirements tree 70
O
On Failure link 177
online resources xi
Open button, attachments 45
Open Test Architecture Guide x
Options tab, Document Generator 312
Oracle database 10
Order Tests dialog box
Execution Flow 193
Execution Grid 216
ordering tests
in the Execution Flow 193
in the Execution Grid 216
Organize command, Favorites 48
Organize Favorites command 49
Organize Favorites dialog box 49
OS field 200
P
Parameter Properties dialog box 134
parameters
adding to test 134
overview 132
Pass All command 202
Passed button, manual test run 202
Passed requirement status 62
Password box, Login window 16
password, changing 19
Paste as Child command, requirements
tree 77, 78
367
Paste button
requirements tree 77, 78
Test Grid 97
Paste command 139
Paste Steps button, Test Plan module 139
Paste Test Set command 179
Path, Test Grid 99
Percent of Similarity box 250
performance testing 88
Period
progress graph 301
trend graph 305
permissions 10
Pie Chart tab, graphs 298
Plan, Execution Grid
Creation Date 163
Description 163
Designer 163
Estimated DevTime 163
Execution Status 163
Modified 163
Path 163
Status 163
Steps 163
Subject 163
Template 163
Test Name 163
Type 163
Planned Closing Version, Defects Grid 241
Planned Exec Date
details of test run 222
Execution Grid 163
Planned Exec Time
Execution Grid 164
Planned Host Name
Execution Grid 164
Planning menu, Test Plan module 95
Print Graph button 306
Priority
Defects Grid 242
private folder, in favorites 49, 50
privileges 11
Product, requirements tree 63
368
Project Administration utility x
Project Customization window x
project databases 10
Project list, Login window 15
Project, Defects Grid 242
Properties dialog box 50
Properties of user dialog box 20
properties, changing 20
public folder, in favorites 49, 50
Purge Runs command 181
Q
QuickTest Professional for MySAP.com Windows Client, test type
definition 105
QuickTest Professional, test type
definition 105
R
R&D Comments box, Defects Grid 242, 251
Read Me First xi
Refresh All command
Reqs Coverage tab 123
Requirements module 70
Refresh button
associated defects 111
graphs 300, 303, 304, 305
Refresh Filter/Sort button 38, 224
Refresh Selected button
Select a Test dialog box 135
test plan tree 109
Refresh Test Sets Filter/Sort command 38
Refresh Tests Filter/Sort command 38
regression test set 170
remote execution 205–215
remote hosts, setting up 212–215
Remove All Execution Conditions
command 192
Remove button, associated defects 111
Remove Execution Condition command 191
Index
Remove From Coverage button
Remove Host From Host Group button 215
Remove Test(s) From Test Set button 179
Remove Time Dependency command 192
Rename command, requirements tree 76
Rename Test Set command 180
renaming a folder or test in the test plan
tree 117
renaming a requirement 76
Renumber Steps button 139
renumbering test steps 139
reordering test steps 138
Replace command
Defects Grid 253
Execution Grid 218
Replace dialog box 140
reporting defects
adding defects 244
at a glance 237–242
Defects Grid 241
deleting defects 259
finding and replacing 252
mailing defects 255
matching defects 247
matching text 247
updating defects 250
viewing defect history 254
workflow 233–235
reports 263–276
adding sub-reports 275
customizing 272
Defects module reports 269
deleting sub-reports 276
generating 271
generating project documents
307–332
overview 263
Requirements module reports 264
Test Lab module reports 268
Test Plan module reports 266
Reproducible, Defects Grid 242
Req ID, requirements tree 63
Reqs Coverage tab
Associated Test dialog box 259
Test Plan module 94
Requirement, Reqs Coverage tab 122
Requirements check box, Document
Generator tree 317
requirements coverage 122–124
adding requirements 123
example 120
overview 119
removing requirements 124
Requirements module
at a glance 57–63
coverage 125–128
field definitions 62
generating project
documents 316–318
graphs 278
main window, Coverage view 58
main window, Document view 58
menu bar 59
reports 263–276
requirements tree 65–84
toolbar 60
workflow 53–56
Requirements tab 57
requirements tree 65–84
copying a requirement 76
creating 66
creating tests from 79–84
definition 55
deleting a requirement 78
displaying numeration 70
expanding and collapsing 70
field definitions 62
finding a requirement 68
mailing a requirement 72
moving a requirement 77
overview 65
refreshing 70
renaming a requirement 76
showing in Test Plan module 123
tests coverage 125–128
369
requirements tree (cont’d)
viewing associated defects 74
viewing requirement history 71
zooming in 69
zooming out 69
Reset Categories dialog box 306
Reset Test Set command 180
resizing grid columns 26
results for test run 219–230
Reviewed
Rotate Bottom Labels graphs 305
Run All Tests Locally check box 208
Run button
Execution Flow tab 198, 208
Execution Grid tab 198, 208
run conditions, setting 188
Run Configuration tab, Test Run Properties dialog box 225
Run Events tab, Test Run Properties dialog
box 228
Run Manually button
Execution Flow tab 199
Execution Grid tab 199
Run on Host, Execution dialog box 208
Run Schedule of Test dialog box
Execution Conditions tab 188
Time Dependency tab 190
Run Test Set button
running test sets 205–218
running tests
automatically 205–218
manually 197–204
Runs check box, Document Generator
tree 328
S
sanity test set 170
Save As command 38
Save Grid Result As dialog box 38
Save Selected button, attachments 46
Save Steps command 132
370
saving data to a file 38
scheduling test execution 185–195
scope 54
screen capture, attaching 43
script, generating 143
Scroll To The Left button 305
Scroll To The Right button 305
Search Results dialog box
Execution Flow 194
test plan tree 114
security testing 88
Select a Destination Subject dialog box 82
Select a Test dialog box 134
Select Clean Up Test dialog box 177, 229
Select Columns dialog box 25
Select Filter Condition dialog box 28
Select Host dialog box 208
Select Recipients dialog box 73, 113, 256
Select Requirements button 123
Select Tests button 127, 173
Send Mail dialog box
defects 255
requirements 72
tests 111
Service Pack field 200
Set 2D/3D Graph button 305
Set Filter/Sort button 27, 36, 224
Set Graph Appearance button 306
Set Test Sets Filter/Sort command 27, 36
Set Tests Filter/Sort command 27, 36
Settings per test link 178
Severity, Defects Grid 242
Show All button 305
Show Full Path command 122
Show Last Run Results command 161
Show only Template Test checkbox 135
Show Parameters button 202
Show Total Values button 305
Similar Defects dialog box 248
Snapshot button 43, 332
Snapshot dialog box 43
sort criteria
clearing 38
refreshing 38
setting 36–38
Index
Sort Direction, Filter dialog box 37
Sort Folders button 115
Sort Folders in Test Plan Tree dialog box 115
Sort tab, Filter dialog box 37
Sorted Fields list 37
specifying requirements 53–56
Spelling buttons, common toolbar 18
Spelling Options button
Add Defect 246
common toolbar 18
Send Mail 74, 113, 257
starting TestDirector 13
Status
Defects Grid 242
Execution Grid 164
Test Grid 99
test plan tree 107
Status Filter list, Tests Coverage tab 126
Step command 82
Steps
test 129–140
Test Grid 99
Steps button, All Runs tab 224
Stop button
Document Generator 332
Execution dialog box 209
stress testing 88
Subject
Defects Grid 242
Test Grid 99
Subject command 81
subject folders
adding to test plan tree 103
definition 101
deleting 117
finding in test plan tree 114
renaming 117
sorting in test plan tree 115
Subject Tests check box, Document Generator tree 321
Subject Tree check box, Document Generator tree 319
Summary, Defects Grid 242
support information xi
Sybase database 10
System Info button 44
System Information dialog box 44
System Test, test type definition 106
System tests 145–150
T
technical support online xi
Template Test command 133
Template, Test Grid 99
templates, generating for automated
tests 143
Test command 82
test execution
automatically 205–218
manually 197–204
test sets 205–218
Test Grid 96–100
column definitions 99
copying tests 97
deleting tests 98
finding a test 115
generating project documents 322–324
mailing a test 111
main window 96
pasting tests 97
toolbar 97
Test Lab module
generating project documents 325–329
graphs 279
main window 158
menu bar 159
reports 263–276
running tests automatically 205–218
running tests manually 197–204
test plan tree toolbar 160
test sets 169–184
test sets toolbar 160
viewing test results 219–230
workflow 153–155
371
Test Lab tab 158
test management process 4
planning tests 6
running tests 8
specifying requirements 5
tracking defects 9
Test Name
Test Grid 99
test plan tree 107
Test Plan module
automating tests 141–144
generating project
documents 318–322
graphs 279
main window 93
menu bar 95
reports 263–276
Test Grid 96–100
test plan tree 101–118
test steps 129–140
toolbar 95
workflow 87–91
Test Plan tab 93
test plan tree 101–118
adding tests 104
associating defects with a test 110
creating 103
deleting folders or tests 117
expanding and collapsing 109
finding a folder or test 114
mailing a test 111
overview 101
refreshing 109
renaming folders or tests 117
showing in Requirements module 127
showing in Test Lab module 173
sorting folders 115
test icons 108
viewing 109
Test Run Details tab, Associated Test dialog
box 259
372
Test Run Properties dialog box 219–230
All Runs tab 223
Attachments tab 223
Details tab 221
History tab 229
Run Configuration tab 225
Run Events tab 228
Test Run Schedule command 188
Test Script tab 94, 144
Associated Test dialog box 258
test script, generating 143
Test Set Details command 172
Test Set on Test Failure Rules dialog box 178
Test Set Properties tab
Details 172
Notifications 176
On Failure 177
test sets 169–184
adding 171
adding tests to 173
copying 179
definition 169
deleting 180
overview 169
purge runs 181
removing tests from 179
renaming 180
resetting 180
running tests 205–218
setting notifications 175
setting on failure rules 177
types 170
Test Sets Filter/Sort button 27, 36
Test Sets menu, Test Lab module 159
test steps 129–140
adding 130
copying 138
definition 129
deleting 138
editing during test run 203
modifying 136
renumbering 139
reordering 138
Test Type list, Test Plan module 105
Test Version, Execution Grid 164
Index
TestDirector
documentation set x
exiting 16
Login window 15
main window 16
online resources xi
overview 3
starting 13
TestDirector URL 13
TestDirector reports 263–276
adding sub-reports 275
customizing 272
Defects module reports 269
deleting sub-reports 276
generating 271
overview 263
Requirements module reports 264
Test Lab module reports 268
Test Plan module reports 266
TestDirector_Demo project 15
Tester
Execution Grid 164
testing requirements, specifying 53–56
testing scope 54
tests
adding to test plan tree 104
associating defects 110
automating 141–144
continuing manual run 204
creating from requirements
tree 79–84
creating test steps 129–140
deleting from test plan tree 117
finding in Test Grid 115
finding in test plan tree 114
linking requirements to a
test 122–124
linking tests to a
requirement 125–128
renaming in test plan tree 117
running automatically 205–218
running locally 208
running manually 197–204
running remotely 208
scheduling test runs 185–195
tests (cont’d)
test sets 169–184
types 105
viewing all 96
viewing run results 219–230
Tests check box, Document Generator
tree 326
tests coverage 125–128
adding tests 126
example 121
overview 119
removing tests 128
viewing 126
Tests Coverage button 67
Tests Filter/Sort button 27, 36
Tests List check box, Document
Generator 323
Text File, saving data as 38
Thesaurus button
Add Defect 246
common toolbar 18
Send Mail 74, 114, 257
Time
Execution Grid 164
specifying for a test run 188
Time Dependency icon 192
Time Dependency of Test dialog box 192
Time Dependency tab, Run Schedule of Test
dialog box 190
toolbars
Defects module 239
Execution Flow 166
Execution Grid 162
graphs 305
Test Grid 97
Test Plan module 95
test plan tree 160
test sets 160
Tools button 17
Change Password command 19
Change User Properties command 20
Document Generator command 310
373
tracking defects
adding defects 244
Defects Grid 241
deleting defects 259
mailing defects 255
matching defects 247
matching text 247
updating defects 250
viewing defect history 254
workflow 233–235
Tutorial x
Type
Test Grid 99
typographical conventions in this guide xii
U
Unattached folder, test plan tree 117
URL button 42
URL for TestDirector 13
Use History check box, graphs 301
user groups 11
User ID box, Login window 16
user privileges 11
user properties, changing 20
V
VAPI, test type definition 105
VAPI-XP API 350–353
VAPI-XP tests 335–359
creating 336–344
debugging 357–359
editing 345–349
running in debug mode 354
running in test mode 355
VAPI-XP, test type definition 106
View box, Requirements module 57–58
View command, Favorites 48
View menu
Test Lab module 159
Test Plan module 95
View Runs list, All Runs tab 224
374
views, favorite 47–50
Visible Columns list 25
W
Web page, attaching 42
What’s New in TestDirector xi
WinRunner Automated, test type definition 105
WinRunner parameters 227
Word
exporting from 11
generating project documents 332
Word Document, saving data as 38
X
X-Axis list 299
XRunner, test type definition 106
Z
Zoom In button
Execution Flow 195
graphs 305
Zoom Out button
Execution Flow 195
graphs 305
Zoom Out One Level button 69
Zoom Out To Root button 69
Mercury Interactive Corporation
1325 Borregas Avenue
Sunnyvale, CA 94089 USA
Main Telephone: (408) 822-5200
Sales & Information: (800) TEST-911, (866) TOPAZ-4U
Customer Support: (877) TEST-HLP
Fax: (408) 822-5300
Home Page: www.mercuryinteractive.com
Customer Support: support.mercuryinteractive.com
� ��

TestDirector User`s Guide - Professional Development Resources

Transcription

Similar documents

AnimatorDV Simple+ Quick Start

Fetal Development as Vulnerable Periods

Moi - IB Rubinetterie

Surftech Warranty Claim Form

XMPlayer Express

Afni Background Check Process Guide

KLA Tencor EV300 Defect Review SEM

Untitled - Brookstone

NTREIS Internet Explorer Settings

Flatbed