Quality Center Structure

General Structure

HP Quality Center consists of 2 parts:

Administration
Projects' GUI

Below their major characteristics and the purpose for which they were designed.

Administration - SiteAdmin

The Administration section allow you to:

create/delete Domain and Projects
manage users (create/delete users)
view and manage QC connection
view Licenses situation
view the status of the Application Servers
view the information about DB Server
manage the Configuration and Parameters

Projects' GUI

It's the User Interface section where users are enable to interact with Project's object and data such as requirements, releases, tests, testsets, defects, reporting.

The profiles to which the user is associated allow him to perform action on the project's objects such as update, create or delete.

Project Structure

A Quality Center Project is a box that contains Requirements, Releases, Tests. Inside it it's possible to create chains of test that represent the TestSet. There is also a section all dedicated to the manage of the Bugs and one for the Reporting.

The Project Structure consist of 2 aspects:

data such as attachments and scripts (workflow script editor) that often are saved and stored into the FileSystem
a DataBase that consist on meny tables where are stored object such as Requirements, Tests, Runs, TestSets, Bugs and so on.

Quality Center could be installed on a unique machine that contains also FileSystem data or have a 3 level architecture consist on QC core installed on few application servers, one DB server and one shared FileSystem.

Whatever configuaration used the path of the FileSystem for the projects is: \\..\Quality Center\repository\qc\DomainName_ID\ProjectName\ inside of who are stored one xml file, dbid.xml, in which are saved all based project information, and others folders among which the main ones are:

scripts: folder contains .tds files, that are file for every single module of the script editor (requirements, testplan, testlab, manualrunner, etc...)
attach: folder that contains all project object's attachment. Naming convention is OBJECTTYPE_attachmentname.extension (for ex: BUG_applerr.jpg)

The dbid.xml structure is this one:

<?xml version="1.0" encoding="UTF-8" ?>

- <ProjectDescription>

<PROJECT_NAME >ProjectName</PROJECT_NAME>

<DB_TYPE>2</DB_TYPE>

<DESCRIPTION>Created on AAAA-MM-DD HH:MI:SS</DESCRIPTION>

<DB_CONNSTR_FORMAT>jdbc:mercury:sqlserver://NomeDBServer\SID:Porta

</DB_CONNSTR_FORMAT>

<DB_NATIVE_AUTHENTICATION>N</DB_NATIVE_AUTHENTICATION>

<DB_NAME>DBProjectName</DB_NAME>

<DBSERVER_NAME>DBServerName\SID</DBSERVER_NAME>

<DB_USER_PASS>TWO:XX-XXX-XXX-X-XX-XX</DB_USER_PASS>

<PR_HAS_VCSDB>N</PR_HAS_VCSDB>

<PHYSICAL_DIRECTORY>\\..\..\Quality Center\repository\qc\DOMAINNAME_ID\ProjectName\

</PHYSICAL_DIRECTORY>

<USERS_QUOTA>-1</USERS_QUOTA>

<PR_IS_ACTIVE>Y</PR_IS_ACTIVE>

<SAQ_IS_ACTIVE>N</SAQ_IS_ACTIVE>

<VM_REPOSITORY />

<PR_LANGUAGE>English</PR_LANGUAGE>

<PROJECT_TYPE>Standard</PROJECT_TYPE>

<IS_TEMPLATE>N</IS_TEMPLATE>

<PROJECT_UID>aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa</PROJECT_UID>

</ProjectDescription>

IMPORTANT:

DBNAME is the project DB name. The naming convention provides for a maximum of 30 characters. If the length of the Project Name is up to 27 characters long, will be add other 3 characters that are "_db". In the case the name is longer it will be truncated on the 30th character.

Here there are the major DataBase tables:

ACTIONS: here are stored the available actions for the Project (however is better to retrieve those name from workflow script editor through the function ActionCanExecute)
ALL_LISTS: this table contains all the item stored inside the lists with also the testplan folder and their path
AUDIT_LOG and AUDIT_PROPERTIES: with these 2 tables you can see the logs of the actions execute on an object. For example you can see all the change status of a bug.
BUG: table that contains all the information about defects.
COMMON_SETTINGS: very usefull table. It is used to pass data, for example, from ManualRun Module to Bug Module. It is very dynamic and lends to various uses.
CYCLE and CYCL_FOLD: The first one is the TestSets (Test Strategy) Table and the Second one is the table where are stored info about TestSet Folders.
DESSTEPS: this table contains info about the steps of the tests (design step) that are created during the creation of a test (test plan section).
GROUPS: table of the groups associated to the project
LIBRARIES: table contains the list of libraries.
LINK: in this table are stored the link between BUGs and the others entity (Tests, TestSets, Requirements...)
LOCKS: locks table
MODULES: table content of the QC projects sections
RELEASES: releases table
RELEASE_CYCLES: this table contains the Test Cycles under the Releases.
REQ: table of the Requirements (also the folder in this section is a type of requirement and it is stored here)
REQ_COVER: link between requirements and tests
REQ_RELEASES: link between requirements and releases
REQ_TRACE: link between requirements
REQ_TYPE: table contains all the characteristics of the type of requirements
RUN: table where are stored all the test executions
STEP: RUN's sister table contains the step executions (Different from DesignStep)
TEST: table of the Tests
TESTCYCL: table contains the TestInstance present into TestSets
USERS: table of the project's users.

SITE ADMINISTATOR STRUCTURE

The admin GUI consist in differents tab. Every tab allow the administrator to use the functions explain above.

The structure of the manage project view consist as a tree with the Domains, as folders, that contain the Projects. Projects and Templates has different icon.

The SiteAdmin DB is a single one that contains general information, such as the list of Projects, Users (where are stored also password) and qc users' connections.

DB is not visible from the GUI. It is possibile to manage SiteAdmin Object using SaApi (SiteAdmin API).