Mercury Quality Center

Welcome

Welcome to the Mercury Quality Center tutorial. The tutorial is a self-paced guide that teaches
you the basics of managing, testing and optimizing your applications with Mercury Quality Center.

Mercury Quality Center is a next generation tool derived from Mercury's Test Director. It allows an
organization to optimize its software testing processes using a web-based test management tool.
This includes requirements gathering, test modeling, test scheduling and defect tracking. In this
tutorial you'll learn how to control the following QA elements:

 Requirements Management
 Business Component Design
 Test and Test Set Management
 Defects Management
 Management Reporting and Analysis

The tutorial is divided into a number of short, self-paced sections. After completing the tutorial,
you can apply the skills you have learned to more advanced courses.

 Introducing Quality Center describes the basic characteristics of Mercury Quality

Center.
 Managing Requirements shows you how to create and link requirements to tests.
 Business Components discusses how reusable-testing components can be developed
without recording.
 Test Plan Elements shows you how to organize automated and manual tests.
 Test Lab Elements shows you how to group and schedule tests from the test plan.
 Defects Management shows you how to track defects throughout the application life
cycle.
 Reporting and Analysis shows you how to create management reports and graphs.
 Miscellaneous Features shows you what other capabilities are included in Quality
Center.

Getting Started

Mercury Quality Center (powered by Test Director) is a browser-based test management tool.
Because it is browser-based, anyone, worldwide, can connect to it. To begin using Quality Center
you just need to know the starting URL. By clicking on the Quality Center link, you'll see the
screen shown below.

The first time you connect to Quality Center it will ask to download some ActiveX components.
Choose to install these components. They are required and will enhance the browser interaction.

Mercury Quality Center manages information on multiple application projects. Projects can also
be grouped into domains to separate functionality. When users connect to Quality Center they
provide a Domain, Project, User ID and Password. The Quality Center administrator assigns roles
to each user that allows them to view or change specific pieces of data. Some user roles will have
more permissions than others.
Quality Center is architected on a J2EE platform and can run on a variety of host hardware. It
utilizes either Microsoft SQL Server or Oracle databases as its repository. Quality Center doesn't
have a "Save" feature. When you make a change and select elsewhere, the change is sent to the
server at that time. Be aware that any edits get immediately saved.

Since Quality Center is a shared application, those changes may be occurring to data while
you're looking at it. A refresh button is used to synchronize your view with the latest data. You can
usually refresh a single section or choose to refresh all the items in a display. It's a good practice
to refresh the data shortly before making any changes to it.

The following sections will introduce you to the capabilities of Mercury Quality Center and will
show you how to truly optimize your quality management processes.

Managing Requirements

Requirements Module

The Requirements section of Quality Center is accessed by clicking on the Requirements icon on
the leftmost toolbar.

Requirements are the backbone of any development or testing process. They are the language of
software development and testing. Whether written down or implied they form the basis for what
is developed and tested. Mercury Quality Center enables organizations to share a common vision
for requirements management. Quality Center not only provides a centralized storage area for
requirements but allows you to track their progress through the application life cycle.
Requirements are linked to the execution results of tests so you can easily see if a requirement
has been satisfied or not.

Figure 1 shows that the Profiling requirement has not yet been met. The tests associated with it
have at least one failure among them, and therefore the requirement is marked as Failed.
Requirements in Quality Center can also be nested. Requirements can contain child
requirements or other parent requirements. Parent requirements inherit the success or failure of
their children, and any requirement that directly has an associated test is said to have “Direct
Coverage.” Best practice dictates that all requirements should have one or more associated tests,
and all tests should have one or more associated requirements .
 Figure 1 - Requirements (Coverage Analysis View)

Requirements - Coverage Analysis View

Figure 1 shows a view called "Coverage Analysis View". The view being shown is indicated by the
text located beneath the menu bar. This view displays a bar chart analysis of each requirement in
a project. A completed project where all the tests have passed would show all green bars.

The statuses that a requirement can have are listed below:

 Failed – One or more associated tests from a direct or child requirement has failed.
 N/A – The current status of the requirement is not applicable.
 No Run – No associated tests have been executed and no results are known.
 Not Completed – One or more associated tests has begun (but not finished) its
execution.
 Not Covered – No tests have been linked to this requirement or its children.
 Passed – All associated tests from direct or child requirements have passed.

Requirements Coverage View

Requirements Module - Coverage View

Requirements can also be viewed in a "Coverage View." This view differs from the Coverage
Analysis View by showing all the tests that are associated with a given requirement. Figure 2
shows the requirements tree on the left which is opened up to see the details of the "Flight
Tickets" requirement. The requirements tree has been opened to show the nested child
requirements and has been numbered. This numbering can be turned on or off from the View
menu by choosing "Numeration."

Requirements are linked to tests stored in the Test Plan section by clicking on the "Select Tests"
button. This brings up a sidebar with the Test Plan tree. Tests are linked by dragging files or whole
folders onto the list of associated tests. You can also create these same links from the Test Plan
section.

Figure 2 also shows the results of the most recent runs of the associated tests. A number of the
tests show a fail status. Even a single failed status will cause the requirement to display a failed
status in the Coverage Analysis View. Only when all the linked tests has passed will the
requirement show as having passed.

Figure 2 - Requirements (Coverage View)

The Coverage View is useful for examining the requirements tree and to link tests to
requirements.

Three different tabs in this view are :

 Test Coverage Tab – Allows you to see the associated tests and their statuses. You can
also create new links by dragging tests into the coverage area.
 Details Tab – Displays the attributes for each requirement such as the author, priority
and description.
 Attachments Tab – Any attachments like supporting documents, screenshots, and links..

Requirements Module - Document View

A third way to view requirements is called the Document View as shown in Figure 3. This view
offers a grid-like view of the requirements. Attributes can be edited directly from this view by
changing the cell values. The displayed attribute columns can be selected by clicking on the
Columns button (to the left of the magnifying glass). This brings up a dialog that allows you to
select and order the columns. Columns can also be ordered by dragging the column headers
around.

Figure 3 - Requirements (Document View)

The Description tab at the bottom displays and edit box for the selected requirement. The History
tab shows the change history for the requirement. This allows tracability when questions come up
later about when a change was made and by whom.

Chevrons ( » ) exist above this section and allow to hide or display the History and Description.
Similar chevrons exist throughout Quality Center. They all work to hide or display different
sections.

Changes to a requirement causes a ripple effect in the tests that are linked to it. If you modify the
description, it might change the nature of the requirement. This causes all tests associated with a
requirement to be suspect. When viewed in the Test Plan, those tests will appear with a red
exclamation point ( ! ) next to them This means they should be re-run or re-visited to determine if
they still satisfy the changed requirement.
Requirements Creation
Creating New Requirements

Requirements can be added or edited in any of the three views.Two buttons control how new
requirements are added. Figure 4 shows the toolbar with these buttons in the upper left corner.
Both buttons create new requirements; they differ only in where they create the requirement.

The New Requirement button creates a new requirements at the same level as the requirement
that is currently selected. In Figure 4, the "1.2 Online Travel Information Services" parent
requirement is selected. Clicking the New Requirement button would create a new requirement
numbered 1.4. New requirements always get added and numbered after any existing
requirements. In this case, that last requirement at the current level is "1.3 - Profiling".

Clicking the New Child Requirement button (next to the New Requirement button) at this same
level would create a sub-requirement numbered 1.2.5. That's because the last sub-requirement
(or child) is "1.2.4 - Tips & FAQ". Both buttons create identical requirements but at different levels.

Only parent requirements with children will have the + / - symbol to their left. Once requirements
have been created you can reorder them by dragging and dropping them. They will be
automatically be renumbered.

Figure 4 - Creating New Requirements (with Numeration)

Business Components

Business Components Module

The Business Components section of Quality Center is accessed by clicking on the Business
Components icon on the leftmost toolbar.

Business components are reusable test modules that can be built with minimal testing expertise.
Business Process Testing (BPT) is a method to develop these reusable components. This
technique allows a business analyst to wire up many different functional tests from a set of
components. Business components can be built “script-free” and then reused in many different
test scenarios. This dramatically reduces the cost and maintenance of a QA organization.

Figure 5 shows a Login component as part of a set of reusable components. Each component is
a piece of a business process. Components can have input and output parameters allowing them
to be "wired-together" in many ways. In the Test Plan section, the components are assembled into
whole processes. The creation of components and business processes can be done primarily by
business analysts. QA engineers are used to construct "Application Areas" which are repositories
of GUI elements and keyword functions.

Figure 5 - Business Components

Test Plan Organization

Test Plan Module

The Test Plan section of Quality Center can be accessed by clicking on the Test Plan icon on the
leftmost toolbar.

Tests are stored into a directory structure that is created by the testing team. Other Mercury tools
like QuickTest Professional and LoadRunner can establish a connection to Quality Center and
then store their tests into this structure. You can think of Quality Center as a large shared file
system that everyone can use to store their tests. Quality Center also holds other information like
the designer, status, and the creation date. The Test Plan tree is shown in Figure 6.

Figure 6 - Test Plan - Details View

The Test Plan section contains details about all the testing assets stored in Quality Center. It is
here that tests from QuickTest Professional, LoadRunner, WinRunner and others are stored.
Various test types are shown in Table 1.

Test Type Icon(s) Description

MANUAL A manual test with steps. If the test does not have step
associated then only the the blue M appears.

QUICKTEST- A QuickTest Professional test.

TEST

WR- A WinRunner test.

AUTOMATED

DB-TEST A VuGen script from LoadRunner.

LR-SCENARIO A LoadRunner scenario.

BUSINESS- A Business Process test. These consist of a set of business

PROCESS components organized into a business process. The top icon is
in a ready state while the lower icon is in maintenence mode

SYSTEM-TEST A system test. System tests can collect system information,

capture a desktop image or restart a system.

VAPI-XP-TEST A Visual API test that executes a programming-language based

test.

Table 1- Test Types

Test Plan Scripts
Test Plan - Scripts

The Test Plan shows a tree structure of how the tests are stored. To the right is a Test Script tab,
which shows the test itself. This is not an editable view, but there is a button above the script that
will launch the appropriate test tool. Figure 7 shows a view of a QuickTest Professional script. You
can see the keyword view, the data table and also the active screen snapshot of the application at
the current step in the test script.

Many types of automated and manual tests can be stored. In Figure 7 you see a number of
manual tests. The blue M icon indicates this. They may also have a footprint icon next to them
indicating that they have specific steps. While the goal of most QA organizations is to automate
testing, manual tests still plan an important part. Non-tool oriented tests include system tests and
Visual API (VAPI) tests. VAPI test scripts run through a direct scripting interface like VBScript,
JavaScript, PythonScript or PerlScript.

Tests in the test plan view are organized into sets of folders. The folders that you create will
depend on the needs of the project. Some typical folder organizations might be around functional
versus load testing, or development areas like system, unit and black box tests. They can also be
organized based upon different functional areas within an application.
 Figure 7 - Test Script Tab

There are 5 tabs associated with the Test Plan section These are :

 Details Tab – Displays the attributes for each test or folder such as the author, priority
and description.
 Design Steps Tab – Manual tests and combined functional/manual tests will show a set
of steps, descriptions and expected results.
 Test Script Tab – Non-manual test scripts will be displayed in a read-only type editor. For
Mercury-based scripts a launch button allows you to start the testing tool and load the
script into it. Some test types will require an add-in to display properly.
 Attachments Tab – Any attachments like supporting documents, screenshots, and links.
 Reqs Coverage Tab – Displays the associated requirements for a given test. Allows you
to link requirements from the requirements tree to tests in the Test Plan.

Under the View menu for the Test Plan section is an option to view the plan in a Test Grid. This
view is similar to the requirement's Document View which shows the data in a table view.

Test Plan Creation

Test Plan - Creation
To create a test plan you need to consider how you should organize your testing. That usually
involves understanding what testing processes are already in place. Are there separate testing
teams for functional versus performance testing? Is the focus on different phases of testing? Do
tests exist for black-box, white-box, unit and system testing? The answers to these quiestions will
guide you as you build a test plan structure.

The structure is consists of a set of folders and files. The only real difference is that the files and
folder exist on a remote Quality Center server.

To create a structure you start by creating a folder and naming it. The left most button above the
test plan tree is the New Folder button. When you click it you'll see a dialog as shown in Figure 8.
New folders are always created underneath the current folder that is selected. To create a folder
at the highest level, just select the Subject folder. In Figure 8, a new folder is being created called
"Flight Logistics." Since the Subject folder is selected, this folder will end up beneath the "Mercury
Tours Site" Folder.

Figure 8 - Test Plan Folder Creation

Test Plan Manual Scripts

Test Plan - Manual Test Scripts
The storage structure created in the Test Plan consists of folders and files. Folders can be nested
inside of other folders. This structure mimics a typical file system structure.

Two buttons control the creation of this structure. Figure 9 shows the "Test Plan Tree." The top left
button creates new folders while the button to the right creates new tests. Tests can also be
created directly from Mercury's testing tools (e.g. QuickTest Professional, WinRunner,
LoadRunner). When these tools are connected to Quality Center the Test Plan Tree appears
when saving a test.

Figure 9 - Test Plan Tree

Manual tests are commonly used as a starting point for transitioning to automated testing. Quality
Center's support for manual tests include template tests, parameters and the ability to call other
manual tests.

To create a manual test, a user selects the New Test button and chooses a manual test type.
Each step is then constructed with a step name, a description and an expected result. Figure 10
shows a manual test which calls another manual test. This modular structure is easily maintained.
 Figure 10 - Manual Test Steps

When running manual tests, a dialog window appears that guides the tester through the manual
steps. After each step, the tester can note the pass/fail status of the step and the actual versus
expected results.

Test Lab Elements

Test Lab Module

The Test Lab section of Quality Center is accessed by clicking on the Test Lab icon on the
leftmost toolbar.

The Test Lab is where tests from the Test Plan section are scheduled to run. Tests are placed into
Test Sets and test sets are placed into folders. A test set is just a logical grouping of tests that
should be run as a group. It is a collection of tests. In the Test Lab, you create these collections
and then schedule them to run. You can schedule them to run unattended at off hours with no
supervision. This allows testing activities to occur 24 hours a day. Because testing can now be
run without anyone present, more testing can be done, and the quality of the application
increases.

Figure 11 shows the details of the "Mercury Tours Functionality" test set. In this view the folders
are green and the test sets appear within them as yellow pages. To the right of the test set tree
you can see a view of all the tests contained in this test set. These sets can be a collection of
many types of tests, both automated and manual.

You can also see that these tests have a status of Passed or Failed. This indicates what occurred
when the test was last run. This also reflects upon the status of any requirements that were
associated with that test. The most recent status of a test’s execution determines whether the
requirements linked to it are passed or failed. Tests share the same status types that
requirements have.

Figure 11 shows that the second test from the top has been selected. This is indicated by the
small green triangle on the left of the test name. Near the bottom of the window it shows the last
run results for this test. You can even bring up the complete run results window for this run by
clicking on the “Launch Report” icon. The entire history of a test can be seen by double-clicking
on its name.

Figure 11 - Test Lab View

Test Lab Structures
Test Set Creation

The Test Lab consists of an organization of test sets. A folder-based structure contains these
sets. Each set is a collection of tests used to verify some sort of compliance, standard or
functionality. You might have test sets to determine whether the application is connecting to a
database properly. You might also have one to test just the API of an application. Each of these
sets verifies that some related task is being tested.

Another way to organize tests is based upon the expected release date of the application. You
might construct a two-month test set (large), a two-week test set (medium) and a two-day (small)
test set. These would correlate to the amount of time remaining before the release. If there's not
much time left to test, only test the more critical functionality. The more time you have, the more
testing that can be done.

To create a new test set you select the folder and click the New Test Set icon. In the dialog box
that appears you name the test set. Then you can click on the "Select Tests" button and drag
individual tests or whole folders to add to the test set. Tests can even be added more than once in
a test set. This allows you to run the same test with different sets of data or to reset a database
between other tests.

Figure 12 shows a new test set called "Profiling" and the entire contents of the "Profiling" test plan
folder has been added to it by dragging it to the execution grid. By naming the test sets the same
as a test plan folder you can map a test plan function to an executable test set.

A test set is executed by clicking on the "Run Test Set" button and then scheduling a time and
place to run.
 Figure 12 - Test Set Creation

Test Lab Execution Flow

Test Lab Module - Execution Flow

The Execution Flow tab in the Test Lab allows you to order the execution of tests in a test set.
This allows you to graphically define the flow of the test set. For example, you can define which
test should start the test set and which ones should follow. You can even define what happens
when a test fails. In that case you might want to run a cleanup test and stop the test run. Figure
13 shows a sample execution flow diagram.

Scheduling tests is also done in this view. Automated tests can be scheduled to run unattended
on remote machines as long as they have access to a copy of the tool that created the test.
Typically, a QA organization will set aside a number of computers to be used solely for testing.
These testing computers are then used for running unattended test sets. It is a good practice to
keep these computers as pristine as possible so that interactions with questionable software are
minimized.
When adding tests to a Test Set, the tests have no specific order. If they are run on one machine
Quality Center will choose an order for them. However, you can create a specific order and set
dependecies between the tests.

Figure 13 shows the execution flow tab for the Mercury Tours Sanity test set. "Both Profiling" and
"Site Stability" can be run at the same time but "Flight Reservation" will run only if "Profiling runs
and completes with a Pass status. This is indicated by the green line. Conditions are set by
clicking on the lines and editing their properties. The order can be set graphically by dragging
lines to connect the tests. The tests can be run on the local machine or a designated test server.

Figure 13 - Test Execution Flow

Test Lab Properties

Test Lab Module - Test Set Properties
The Test Set Properties tab allows you to configure settings for an entire test set. Figure 14
shows this tab with the On Failure section highlighed. You can define properties for the following
sections:

 Notifications - Set email notifications based on failures and configure the notification
message.
 On Failure - Configure failure response and cleanup tests.
 Attachments - Attach supporting documents and snapshots.
 Details - Edit the test set description and other attributes

Figure 14 - Test Set Properties

Defects Management
Defects Module
The Defects section of Quality Center can be accessed by clicking on the Defects icon on the
leftmost toolbar.

Defects or application issues can be logged through this module. The Defects section allows you
to view defects and issues that have been identified for a project. There is an “Add Defect…”
button that exists on all the different views and any defect entered shows up in this view.

Defects are tracked through this view and can be assigned to specific users for resolution.
Defects are assigned a specific ID and the user determines an initial priority. As a defect works its
way through to resolution, its history is tracked in the Quality Center database.

At the top of the columns in Figure 15, you can see a number of blank white boxes. These allow
you to enter filters on the data for that column. For the filters, the star characrter (*) is a wildcard.
For example, if you wanted to find all the “flight” related issues detected by “alice_qc” you would
put “ *flight* ” beneath the Summary column and “alice_qc” beneath the Detected By column.
That would match all the defects that had “flights” in thire summary and were detected by
“alice_qc”. All other defects would be filtered out.

Figure 15 - Defects Grid

Defects Tracking
Defects Tracking Process

Defects typically go through 4 phases :

 New - A new defect is identified and work is started to review and assign it.
 Open / Reopen - A new or existing defect is being worked on.
 Fixed - A defect has been resolved but needs testing to close it.
 Closed / Rejected - A defect has been resolved or rejected but is available to be
reopened.

Once a defect is identified a process of resolution needs to take place. It might first need to be
verified and then routed to a group or individual for fixing. Eventually it can it be closed or
rejected.

Quality Center's work flow customization can enforce rules on a process like this. A work flow
could be set up to make sure that a defect's status could not go directly from Open to Closed,
bypassing Fixed. Similar customizations can be made for the other modules of Quality Center.

Figure 16 shows a typical defect tracking process.

Figure 16 - Defects Tracking Process

Reporting and Analysis

Quality Center - Reports and Graphs

Each of the major elements in Quality Center has pre-defined reports and graphs that can be
displayed and saved to files. This reporting feature can be accessed by choosing the “Reports
and Analysis” item under the Analysis menu. Figure 17 shows a requirements summary graph.
This bar graph shows all the users that have authored requirements and has grouped them by
their priority. In this example, "alice_qc" has authored 9 requirements and all of them are “Very
High” priority.

Adjustments can be made to these graphs by changing the "X-Axis" and by what it is "Grouped
By." The reports templates can also be customized in a similar way.

Figure 17 - Reports and Analysis

Document Generator

Quality Center - Document Generator

In addition to the standard reports and graphs, Quality Center offers a complete document
generator for custom reports. This tool is found under the Tools menu at the upper right corner of
the window.

The document generator allow a truly custom report to built using specific topics, filters and
sorting. Once a report has been created it can be saved (with all its settings) to a Favorite.
Favorites exist is other QC sections as well and can be either public (everyone can see them) or
private (only the creator can see them).

Figure 18 shows a custom report that will detail just the failed requirements for a system.

Figure 18 - Document Generator

Administration
Administering Quality Center

There are a number of other capabilities in Quality Center that allow you to optimize your QA
processes. There are built-in features for defining workflow characteristics, reporting, document
generation and field customization. In addition, there is a special administration login that can
adjust many other settings.
Administering Quality Center involves creating new projects, setting up user roles, customizing
fields, and maintaining the Quality Center database. Two forms of administration are available.
There is an overall Site Administrator that governs the domains, projects, users, connections and
database characteristics. From that special account, you can create or rename projects or even
disconnect idle users. Figure 19 shows the Site Administrator's console.

Figure 19 - Site Administrator Console

There is a also a separate admin section for customizing a specific project. By clicking on the
"Customize" link on the main Quality Center login page you get to the image shown in Figure 20.
The following features are available :

 Change Password - Change your password.

 Change User Properties - Change your diaplay name, email, phone and description.
 Set Up Users - Add, modify or delete users to a project.
 Set Up Groups - Manage user roles and set permissions for viewing, changing and
deleting fields.
 Customize Module Access - Set the groups that have full module access or just the
Defects module.
 Customize Project Entities - Add, modify or delete custom fields in Quality Center.
  Customize Project Lists - Add, modify or delete pulldown lists and choices in Quality
Center.
 Configure Mail - Set email notification conditions and users to be notified.
 Set Traceability Notification Rules - Activate various traceability notification rules.
 Set Up Workflow - Customize list dependencies, defect fields and forms and workflow
characteristics.

Figure 20 - Project Customization

Add-Ins
Quality Center Add-Ins

Quality Center offers pre-built integrations with a number of other products. These are called Add-
Ins. Add-ins enable additional functionality that is not available as default. Add-ins are installed
separately.

From the Quality Center home page there is a link called "Add-Ins Page." Figure 21 shows the
add-ins page from this link. The initial Add-Ins consist of :

 Mercury Quality Center Connectivity

Allows a machine to run remotely scheduled tests through QC .
 Mercury Quality Center System Test Remote Agent
Enables system tests (like rebooting) to run remotely.
 Mercury Quality Center Client Side Setup
Downloads the initial Quality Center ActiveX controls without going through a browser.
 Figure 21 - Initial Add-Ins Page

Additional add-ins can be found under the link More Mercury Quality Center Add-Ins :

Mercury Testing Tool Add-ins:

 QuickTest Professional Add-in

Enables you to work with QuickTest Professional in a Quality Center project.
 QuickTest Professional for MySAP.com Windows Client Add-in
Enables you to work with QuickTest Professional for MySAP.com Windows Client in a
Quality Center project.
 QuickTest Professional Add-in for Business Process Testing
Enables you to work with business process tests in a Quality Center project.
 XRunner Add-in
Enables you to work with XRunner in a Quality Center project.

Microsoft Office Add-ins:

 Microsoft Word Add-in

Enables you to export your existing test documents or requirements in Microsoft Word
directly to Quality Center.
 Microsoft Excel Add-in
Enables you to export your existing test documents, requirements, or defects in Microsoft
Excel directly to Quality Center.

Synchronization Tool Add-ins:

 Requirements Synchronizer for Rational RequisitePro Add-in

Organizes the transfer of requirements data between Quality Center and Rational
RequisitePro.
 Defects Synchronizer for Rational ClearQuest Add-in
Organizes the transfer of defect data between Quality Center and Rational ClearQuest.
  Defects Synchronizer for Merant PVCS Tracker Add-in
Organizes the transfer of defect data between Quality Center and Merant PVCS Tracker.

Version Control Add-ins:

 Microsoft Visual SourceSafe Version Control Add-in

Enables Quality Center to work with Microsoft Visual SourceSafe, allowing you to perform
version control on your Quality Center tests.
 Rational ClearCase Version Control Add-in
Enables Quality Center to work with Rational ClearCase, allowing you to perform version
control on your Quality Center tests.
 Third Party Version Control Add-in
Enables Quality Center to work with a third party version control tool, allowing you to
perform version control on your Quality Center tests.

Others:

 Mercury Quality Center Explorer Add-in

Enables Quality Center client users to run a browser-independent version of Quality
Center.
 Import Tests Add-in
Enables you to import tests to your Quality Center project.

Summary

Mercury Quality Center

This concludes the Fundamentals of Mercury Quality Center tutorial.

Here are some key points to remember:

• There are 5 major elements in Quality Center

Requirements Management
Business Components
Test Plans
Test Sets
Defects Management

• Mercury Quality Center provides a global repository of application quality

information and assets

• Users of Quality Center include Software Developers, Business Analysts,

Quality Engineers, R&D, and QA management

• Quality Center optimizes the software development and software deployment

life cycles

• Workflow customizations provide the ultimate fit for unique QA processes

Thank you for completing this tutorial!

What's Next?

Now that you have completed this tutorial, you are ready to start using Quality Center to manage
your own applications.

Here's a number of resources where you can get more information on Mercury Quality Center.

 Mercury Customer Support

Mercury's award winning Customer Support is just an email or phone call away.
To reach them, just email to support@mercury.com with your question or call 1-
877-TESTHLP. You'll need your maintenance number to access the support
technicians.

 Mercury Support Knowledgebase

You can access the vast Mercury Support knowledgebase by logging in to

http://support.mercury.com. Here you'll find solutions to the most commonly
asked questions as well as online forums.

 Online Quality Center Documentation

You can find answers to most of your questions just by browsing the many online guides
provided by Quality Center. These guides are located in the Help links throughout Quality
Center. Make sure you start by checking out the Mercury Quality Center User’s Guide.