This User Guide aims to help you get the most out of your installation of QaTraq and help you take control of your test management process. This particular User Guide covers functionality included in Stage 4 of the QaTraq project. Stage 4 of the project included the following 2 releases : If you are looking for a quick introduction then the tutorial provides a quick overview of the QA Traq application. Feedback regarding errors, suggestions or omissions in this document can be submitted via our feedback page.

The QATraq application is based around a hierarchy which relates to the following test process:

Test Cases			A test case is the core component of the test process. A test case can be written once and then related to many test scripts (so that you can create a number of test scripts containing the same test cases but each test script having different test result records). In addition to this every test case is related to a product and components of that product (in much the same way as a defect report is always related to a product and component). So Test Case are … based on a product based on one or more components (components make up a product) related to a product version ( when the result record is created for a test case)
Products		Versions
Components

QA Traq is a web based application that helps you take control of your test documentation. There are eight main types of document:

1. Phase - definitions of the different types of testing employed in your organisation
2. Plans - repository for test plan documents and related information (eg Gantt charts)
3. Design - repository for all documentation relating to test design
4. Scripts - test outline information and a container for groups of test cases
5. Cases - a specific test containing details such as test steps, expected outcome, etc
6. Results - records detailing the outcome of a test
7. Products - a product which is going to be tested (products contain one or more components)
8. Reports - queries that produce reports showing how you testing is progressing

To navigating your way around these different types of documents use the two step approach outlined below: For each type of document you will find that you can work with documents in the following modes:

1. View - Search for and view existing documents (this is the default mode).
2. New - Create a new document.
3. ModifyM - Search for and modify an existing document.
4. Delete - Search for and delete an existing document.
5. Copy - Search for and copy an existing document.

Which of these modes you have access to for particular document types depends on the privileges assigned by the administrator (see User Administration below). If you do not have privileges to view, create new, modify, delete or copy a particular document type then you will not have access to the modes on the left hand side menu.

Access to document types and editing functionality for documents is determined by a combination of user records, roles and privileges. Roles are assigned privileges. Users are assigned roles thus giving them privileges. This relationship between User, Roles and Privileges is shown below The process for creating users, roles and privileges is as follows:

1. A role is defined by creating a new role (Roles -> New)
2. Privileges are granted to a role (Roles -> Modify)
3. A new user is defined (Users -> New)
4. A user is assigned one or more roles (Users -> Modify)

Users - You can define numerous users within QA Traq. For each user you can specify a Login Name, User Name, Password, Default Role and Additional Roles.

New users can be created by any user who has 'New' privileges (see below for details on privileges) assigned to their user account. To create a new user select users and then 'new' from the side menu. Complete the Log in and user names fields along with a default password. Select a default role to provide the user with a set of initial privileges.

To change a password once a new user has been created you need to log in, select Users and then search for your login name. When 'viewing' a user record which matches the name you logged in with, you will be given the option to change your password.

Roles - Within QA Traq a number of roles can be defined. A Role is assigned privileges that grant certain access rights within the application. Each user can be assigned one or more roles within the Test Management Tool (i.e. there is a many-to-many relationship between users and roles).

Privileges - Each role is granted a set of privileges to view, create new, modify, delete or copy particular document types (like the privilege to view test plan documents). Thus a user that is assigned a role will be granted the privileges of that role. If a user is assigned two (or more) roles then that user is assigned the privileges of both of the roles.

Defining the privileges assigned to a role can be a laborious task of selecting many check boxes. For this reason if you are to create many roles it may be easier to create a template role and then copy the role. When you copy a role the privileges are copied to the new role saving you the effort of selecting many check boxes to define the privileges.

Every document is assigned a unique Document ID. This identifier is formed as follows: Where the document type consists of three identifying letters: The document number is a unique number generated automatically and assigned to the document for its entire life. The document version is assigned automatically too but increments each time a document is modified. Thus, when you modify a document the document number remains the same and the version number changes.

For example a test plan could be identified by the identifier TPL5-1.1 (Test Plan 5, Version 1.1), and a test case might be identified by the identifier TCA5-2.0 (Test Case 5, Version 2.0)

The QA Traq application automatically tracks the versions of all test documentation (Test Plans, Test Cases etc). Each time a document is modified the version number is incremented. All previous versions of the document are retained.

Version numbers are based on major and minor version identifiers. For example version 1.3 has a major version of ‘1’ and a minor version of ‘3’. When a document is created or modified the user has the option to increment major, minor or major&minor version numbers. The user chooses whether to increment the major/minor numbers by selecting the appropriate option from the following list: When a document is copied the new document will have its version number re-set to the default version of 0.1 (although the user can choose to increment major or minor numbers before saving). Note that the new document does not retain the version number of the original document.

It is not possible for a user to update an old version of a document. A user is only able to update the latest version of the document and then save the document with an incremented version number. For example if versions 1.0 and 2.0 of a document exist then it is not possible to edit version 1.0 of the document. Version 2.0 of the document will be editable. If a user does want to edit a document (which is not a latest version) then he/she can copy the older version and then edit it as a new document.

Currently it is possible to add attachments to Test Plan and Test Design documents. When creating new ,or modifying, Test Plan and Test Design document you can select [Add attachment]. This presents the user with an upload window where the user can search and select the attachement to be added. Once you have clicked [Attach File] in the upload window you will see the attachment listed in the 'Attachments' section of the document. At this stage you can either remove the document by clicking [delete] or view the document by clicking on [view].

When copying a Test Plan or Test Design document the user is presented with an addition checkbox along side each attachment. If you want the attachment to be copied to the new test plan or test design document then make sure the check box is ticked. If an attachment doesn't have its check box selected then the attachement will not be present in the newly copied document.

IMPORTANT: attachments are not actually attached to the document until the user saves the Test Plan or Test Design document (by clicking on [Save and View] for example).

Attachments added are stored on the file system in the ./attachments directory where QA Traq is installed (they are not stored within the database) . The name of the attachments on the file system are as follows: Attachments with "--" in the file name are for temporary attachments (i.e. before clicking [Save and View] ).

WARNING: if you are only backing up using msqldump then you will not be backing up your attachments. You MUST backup up your filesystem in order to backup the attachments stored in QA Traq!

The Test Plan provides a repository for all the testing activities and documentation relating to the planning of a testing project. A test plan record within QA Traq is split into five sections:

1. Document Title and Version info
2. Related Test Phases
3. Related Documents (Test Design, Test Script and Test Cases)
4. Attachments (which might consist of test plan documents or gantt charts)
5. Plain Text content

1. Document Title and Version Info - This section contains the title given to this test plan record, the creation/modification date, Version, Document ID and Author (or last person to modify the document).

2. Related Test Phases - within QA Traq you can specify definitions of your test phases (see Test Phases). Each test plan can be related to zero or more test phases (i.e. you don't have to specify a test phase or your test plan could be relevant to all the test phases you have defined). This allows you to provide an indication as to which stages of testing a particular test plan covers.

3. Related Documents - when you create test design documents in QA Traq they must have a test plan document as a parent document. So, within each test plan document you will see a list of test design documents which are related to the test plan. In addition every test script (and the number of test cases within that test script) will also be listed. You can click any of the test design or test script titles to be taken directly to the test design or test script record. Note that the list of design documents and test scripts will always show the latest version of the design document or test script document.

4. Attachments- when you create a new test plan or modify an existing test plan you can add attachments. Clicking the 'Add Attachment' button in new or modify mode brings up an attachments window from which you can select attachments to upload to the QA Traq database. See Attachments for more information on saving and storing attachments.

5. Plain Text Content - In addition to storing attachments within a test plan record you can also enter plain text content. This could take the form of notes on the attachments or even the test plan detail (although this will be somewhat restrictive in terms of formatting).

As part of most test efforts it is common to define different types of test phases (i.e. unit testing, system testing, etc). The test phases functionality within QA Traq allows you to define your test phases and record information like entry and exit criteria applicable to each test phase. Once test phases have been defined it is possible to relate test plans to certain test phases. This provides visibility of which test plans cover which test phases.

With various test phases defined you will find that you can select from a list of these defined test phases in the 'Related Test Phases' section of test plans. You can select many test phases as being applicable to a test plan document (for example you many create a new test plan which covers both unit and unit integration testing). Once you have selected the test phases that are applicable to a test plan users will know instantly which phases of the test cycle different test plans relate to.

If you have no requirement to record details about your test phases then there is no need to define them within QA Traq. In this situation, when you create or modify test plans there will be no entries in the test phases selection list to select. Thus there will be no record in the 'Related Test Phases' section of the test plan once you have created a new test plan.

The test design records are provide so that design information can be recorded prior to (or whilst) test scripts/cases are developed. For example you could store information relating to boundary condition analysis which leads to the creation to specific test scripts and test cases. A test plan record within QA Traq is split into five sections:

1. Document Title and Version info
2. Parent Test Plan
3. Related Documents (Test Scripts and Test Cases)
4. Attachments (which might consist design notes in text documents)
5. Plain Text content

1. Document Title and Version Info - This section contains the title given to this test design record, the creation/modification date, Version, Document ID and Author (or last person to modify the document).

2. Parent Test Plan - when you create a new test design record it has to be related to a test plan document. Thus when you create a new test design record you have to search and select the appropriate test plan document as the parent document.

3. Related Documents - when you create test scripts in QA Traq they must have a test design record as a parent document. So, within each test design record you will see a list of test scripts (and the associated test cases) which are related to the test design record. You can click any of the test script or test case titles to be taken directly to the test script or test case record. Note that the list of script records will always show the latest version of the test script document.

4. Attachments - when you create a new test design record or modify an existing test design record you can add attachments. Clicking the 'Add Attachment' button in new or modify mode brings up an attachments window from which you can select attachments to upload to the QA Traq database. See Attachments for more information on saving and storing attachments.

5. Plain Text Content - In addition to storing attachments within a test design record you can also enter plain text content. This could take the form of notes on the attachments or even the test design detail (although this will be somewhat restrictive in terms of formatting).

A Product is an application or system that is the focus of the testing process. Every test case can be written to test a single product. As such when you create a new test case you have to specify the product to which it applies. In addition to this every product is made up of numerous components. So when you define a test case you specify not only the product to which it applies but also the components within that product that it covers. Specifying the products/components can provide you with a rough idea of test coverage (for example we have run 2 test cases for component 'x' but no test cases for component 'y').

In addition to the components every product can also have a number of versions. Versions only apply to products (versions do not apply to components within a product). With versions specified, when you enter test case results you can specify which version of the product the test result applies to. Thus the product version is only applicable to the test case result (and not the individual test case).

To add components or versions to a product select 'modify' on the products side menu and then search for the product. All products listed will contain the option to 1) modify the product (name and description) 2) modify the components 3) modify the versions. When you select a component or version for a product you will be able to create new, modify, delete and view product components and versions

Test Case is a specific test intended to verify one particular aspect of a Product/ Component under test. A test case will contain information entered by the user which covers input values, predicted outcomes and objectives for the test. Each test case will be related to a single product but will also be related to one or more components.

Test cases form the core of the QA traq application. Every test case can be included in multiple test scripts. Each time a test case is included in a test script a test result record is created ready for the test outcome to be recorded. A test case record within QA Traq is split into three sections:

1. Test Case Title and Version info
2. Products and Components
3. Plain Text content

1. Document Title and Version Info - This section contains the title given to this test case record, the creation/modification date, Version, Document ID and Author (or last person to modify the document).

2. Products and Components - every test case is related to a single product and zero (or more) components within that product (see Products and Componentsabove).

3. Plain Text Content - The plain text content section of the test case is the section that should contain the details about how to execute the step. It is likely to contain sections like 'Test Steps' and 'Expected Results'.

A Test Script is a document which describes in detail how a test is to be conducted. A test script will contain information outlining the test, defines the pre-requisites and contains a number of test cases. The user will enter the outline and pre-requisite text and then link the test script to a number of test cases that need to be contained within the test script.

Test scripts really brings together all the key aspects of the QA Traq application. Every test script has a parent test design record and each test script record contains its core content similar to other document types. The core contents of a test script record within QA Traq are split into six sections:

1. Document Title and Version info
2. Parent Test Design
3. Intended Tester
4. Product and Product Version
5. Plain Text content
6. Test Cases

1. Document Title and Version Info - This section contains the title given to this test script record, the creation/modification date, Version, Document ID and Author (or last person to modify the document).

2. Parent Test Design - when you create a new test script record it has to be related to a test design record. Thus when you create a new test script record you have to search for and select the appropriate test design document as the parent document.

3. Intended Tester - this field lets you specify who you expect to run the tests specified in this test script. Each time you add a test case to a test script, the associated test result record that is created has the intended tester value used as the default value for the individual test result record (this value can be changed in the test result record. See Test Results).

4. Product and Product Version - the aim of each test script is to test a certain area of functionality against a particular product and a particular version of that product. These fields let you specify the product which is under test and the version of that product that you intend to test.

Although every test script is based around a single product and a single product version it is possible to include test cases which are for different products. It is also possible to record test case results for a product version, other than the main version which is, specified in the test script (thus allowing you to continue with a test script even if you have to start testing a different version of the product half way through completion of the test script).

5. Plain Text Content - The plain text content section of the test script is the section that should contain the details about how to execute the test script. It is likely to contain sections like 'Pre-requisites' and 'Test Setup' details.

6.Test Cases - once you have created a test script you can associate zero or more test cases with the test script by 'including' them in the test script. Once test cases have been included they are listed below the other test script details. See Including and Removing Test Casesfor more details about including and removing test cases in a test script.

Every test script can contain, through a process known as 'including', many test cases. Once you have created a test script you select 'include' to associate test cases with a test script. The include test cases page lets you search for test cases to include by specifying any of the following criteria: Having completed a search for test cases you can include the test cases in a test script by selecting the 'Include' box in one or more test cases and then clicking the [Include] button at the bottom of the page. However, before clicking [Include] you can also specify the severity and priority for each test case you included.

Severity - severity can be used to indicate how severe the consequences of a test failure might be. Thus the person executing a test which fails would have some idea that test case '1' failing (with a High severity) constitutes a far worse condition that perhaps test case '2' failing which has a Low severity.

Priority - priority is used to order the test cases included in a test script. If you specify a priority of 0 then this is deemed the highest priority test case and will be listed first when you view a test script or the test results. It is valid to specify the same priority to many test cases (so you could stick to priority 1, 2 and 3) although you don't then have any control over the order of same priority test cases. Alternatively you can give every test case a different priority number and guarantee that the order will be as you specify. If you don't specify a priority for a test case then it is given the highest priority of '0'.

Removing test cases is slightly more straight forward than including them. Once you have searched for and selected the appropriate test script you select the check boxes of the test cases you wish to remove. Once you click [Remove] at the bottom of the page the test cases will be removed from the test script. Note also that once a test case has been removed the test result record for that test script / test case combination will also be removed.

Although a test script will be based around testing one product (as listed in the test script details) it is possible to include test cases which are for different products. The ability to include test cases for other products, could for instance, allow the creation to integration tests between two products. Or you could create a pseudo product (say for 'usability') and then include these test cases across many different product test scripts (thus having common usability test cases across multiple products).

Note that each time you include or remove test cases the minor version of the test script is incremented. For example if you are including 2 test case in test script TSC1-0.2 (version 0.2) then the version will be incremented to 0.3 once you have completed the include. In this way you can go back to previous version of a test script and see exactly which test cases were included and the test result for a test case before it was removed.

One current short coming of the QA Traq application is that if you have a test case included in a test script, and you then change the test case (and therefore increment the test case version) the test script still retains the old version of the test case. This is valid in many situations (such as the situation where you have already recorded the result for the test case), but does require that you remove the old test case version and then include the new version in some instances.

For every test case that is included in a test script a test result record is created for that test script / test case combination. Thus, every included test case will have a test result (e.g. pass, fail, etc).




There are three things to note from the above:

1. A test result record is only created when a test case is included in a test script the same test case can be included in different test scripts (e.g. TCA1-0.1 which is included in both TSC1 and TSC2).
2. Each test case in this instance will have a unique test result record
3. If a test case is not included in a test script then there will be no test result associated with it (eg TCA7-0.1)

The document ID of result documents matches that of the associated test script record. Each time a test script is changed, and the test script version incremented, the associated test result record will have its test result version incremented so that it matches the test script version. For example: So in effect every time you search for a test result document you are searching for the equivalent test script document. For example if you need the test results for test script TSC2-0.1 then you would be searching for test result document TRS2-01. So in effect there are no ‘physical’ Test Result documents. The test result documents are always created from the associated test script and test cases records. It is for this reason that you only ever have privileges to view or modify test results (you can not create new, delete or copy test results. When you create new, delete or copy test scripts the associated test result records are created, deleted or copied).

Viewing and Modifying Test Results does however, differ from other document types in one significant way. You can view test results in two different ways 'single' or 'multiple'. When you search for test result records you will be presented with the option to view a test scripts results as follows:

single
multiple
Regardless of whether you display results in single or multiple views, each result record contains the following information: An important point to note is that a user can only modify or update a test result record if the user logged in matches the user name in the tester field. If these do not match then you will not be able to modify the result record. If you need to modify the result record then the user needs to change the 'tester' field so that it matches the user that he/she is logged in as. This is necessary to avoid different users modifying the same result record at the same time.

QA Traq is designed to work alongside web based defect tracking tools (such as bugzilla). Any test result record can be associated with multiple defects (e.g. if a test case fails then one or two defects can listed against the test case result).

When modifying a test result record in multiple view clicking the [d]efect button for a test result entry will present you with a defect entry window. When modifying a test result record in single view clicking [edit] in the defects box will present you with a defect entry window.

Entering defects in the defect entry window allows you to enter a title and a URL for the defect. The URL is not required but if it is entered then the defect title will be present as a URL link to the defect record in a defect tracking application (such as bugzilla). Having entered the title and the URL you can click add to confirm the defect entry. Multiple defect records can be logged against a single test case result. Clicking deleted for an existing defect record will remove the defect record from this particular test case result.

Note that , QA Traq is not meant to be a defect tracking application. QA Traq only records the fact that there is a defect and provides a URL link to further defect details in a defect tracking application. QA Traq will not record the details about the defect.

Currently reports are based on running SQL queries from the QA Traq user interface. Reports work within the existing view/modify/new/delete/copy document structure. Only when a report is viewed is the associated SQL query executed and the results displayed. Note that the SQL queries for the reports only work with SELECT statements (it is not possible to execute queries which modify the database).

Users can create and modify their own reports but are not be able to delete or modify other users reports. Thus the following restrictions are placed on report documents:

1. Users can only modify their own reports (i.e. if a report was created by user ‘xxx’ then user ‘xxx’ must be the logged in user if he wants to modify a report)
2. Users can only delete their own reports (i.e. if a report was created by user ‘xxx’ then user ‘yyy’ can not delete the report)
3. Users can copy or view all other users reports (i.e. user ‘yyy’ can copy a report created by user ‘xxx’)

Note also that no version control is applied to report documents. Each time a report is modified it will be saved with the same ID. Thus report Ids will are of the format ‘RPTxx’ (eg RPT3 or RPT4) .