Saturday, May 2, 2009


Architecture for Quality Center :

Mercury Quality Centre is a web-based test management tool. It gives you a centralized control over the entire testing life cycle. It gives an easy interface to manage and organize activities like Requirements coverage, Test Case

Management, Test Execution Reporting, Defect Management, and Test Automation. All these activities are provided from a single tool, which is web-based and can be accessed from any where. Hence, making the task of the testers and managers easy.

Mercury Quality Centre
can be divided into two parts:

Site Administrator Bin
Quality Centre Bin

Site Administration Bin: It is the starting point for the usage of Mercury Quality Centre. This part is used for all the administrative activities. Password for site admin is defined during the installation so make sure that you remember the password during installation. From this part of Mercury Quality Centre, we generally do the following activities:

Creating the projects

Assigning users to the projects
Creating specific roles
Configuring QTP or Winrunner scripts to use from Mercury Quality Centre
Configuring the mail servers

Verifying licensing information
Information about database

Quality Center Bin: This part of Mercury Quality Centre gives functionality of almost everything that as a tester or test manager you need to do in your day to day activity apart from execution. This is the most common interface used by the customers or users. In this part, we generally do the following activities:

Creating test plans
Defining requirements
Creating test cases
Creating test labs
Associating requirements with defects in essence

1. Requirements Module:

In this section, first we understand all the requirements, once we understood the what are to be tested, listed out all the Main Requirements as well as sub-requirements (child requirements).

For every Requirement we need to plan a Test.

Test means Test case (in manual) or
Test means Test Script (in Automation)

This module used for building the requirement string. To do the same

This module has provided Two options

a). New Requirement
b). New Child Requirement

These two requirements will do the following
One can attach any kind of attachments to the requirement
It will automatically shows the author name
It will generate IDs automatically for each and every requirements
One can give direct cover status of the requirements like
· Whether the test is covered or Not
· Whether its executed or Not
· If executed, whether its passed or Failed

2. Test Plan Module :

In this section,

We need to create test plan for corresponding requirements which were prepared in Requirement module.

Using the Traceability matrix, you should cross check whether you have created test plans for all the requirements.

This module is used for creating the tests (automatically or manually for all the requirements) to do the same one has to create a folder, under that he needs create the desired empty test. Based on the test one has to launch the corresponding functional tool (QTP), generate the desired test scripts and Click on the save Button in the functional tool.

The script will be saved in the empty script file which is already created in the Quality center. In the same way one has to create all the tests. Once all the test are created this module also provides the facility to establish the link between the test and corresponding requirements with help of requirements coverage tab in order to establish automatic traceability and its feasibility. Once all the test are created then one will go to next module
by name Test Lab.

3.Test Lab Module :

In this section, First of all we need to identify all the end-to-end scenarios , then for each end-to-end scenarios we will create a Test Set.

This module is used for the following…

1. Building the Test set
2. Execute the Test set
3. Analyze the results.

1. To do the same one has to Build/ create the folders and create corresponding test sets with help of all the available test sets based on the different end-to-end scenarios.

2.Once the tests are Build one can Execute them by either RUN or RUN ALL options provided in this module.

RUN : is used for Running a single selected test in the test set

RUN ALL : is used for running all the tests in the test set

3.Once the execution is completed one can analyze the Results in the Functional tool (QTP) it self and if at all one can identify the Defects and need to post them , he can do it from the Functional tool itself, other wise, go to next module by name Defects Module.

4 Defects Module :

This module acts like Bug Tracking tool and provides all the facilities to manage the defects like Adding the defects, changing the status of defects etc., with complete bug tracking facility is provided.

Once the Defects (if any) are been sent to Developers, they will re-build the application by removing such defects and send it again for Testing.
This is called 2nd Build, doing testing on 2nd build on wards is called Re-Testing or Regression testing.

Here we do testing from 3rd module (Test Lab Module) to 4th module (Defects Module).
Till all the defects have been fixed.

5. Log Off