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-TEST

A QuickTest Professional test.

WR-AUTOMATED

A WinRunner test.

DB-TEST A VuGen script from LoadRunner.

LR-SCENARIO A LoadRunner scenario.

BUSINESS-PROCESS

A Business Process test. These consist of a set of business 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 ConnectivityAllows a machine to run remotely scheduled tests through QC .

Mercury Quality Center System Test Remote AgentEnables system tests (like rebooting) to run remotely.

Mercury Quality Center Client Side SetupDownloads 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 ManagementBusiness ComponentsTest PlansTest SetsDefects 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.