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 5 of the QaTraq project. Stage 5 of the project included the following 3 releases : If you are looking for a quick introduction then the tutorial provides a quick overview of the QaTraq 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

QaTraq is a web based application that helps you take control of your test documentation. To navigating your way around QaTraq use the three step approach outlined below: 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

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. Modify - 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.

Once you have selected the document type and the mode, you can search for a specific document. The search results provide a list from which you can then select a single document. Having selected a document you will notice a few 'Navigation' options on the side menu. Using 'Next' and 'Prev' (previous) links under Navigation you can step through the list of documents that were produced from your search. Selecting 'list' will take you back to the results of your original search results.

When working in 'View' mode for any of the document types you will find that you also have a 'Print' option on the side menu. Clicking 'Print' opens a new browser window with just the the document being viewed in (i.e. no menu's are visible). In this new 'print' browser window you can use your standard browser print functionality to print a document.

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 QaTraq. 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 QaTraq 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 QaTraq 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.

It is possible to add attachments to Test Plans, Test Design, Test Script and Test Cases. When creating new ,or modifying, Plans, Designs, Scripts or Cases you can select [Add attachment]. This presents the user with an upload window where the user can search and select the attachment 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 Plans, Designs, Scripts or Cases the user is presented with an addition checkbox along side each attachment. If you want the attachment to be copied to the new document then make sure the check box is ticked. If an attachment doesn't have its check box selected then the attachment will not be copied to 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 QaTraq 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 QaTraq 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 QaTraq 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 QaTraq 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 QaTraq 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 QaTraq. 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 QaTraq 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 QaTraq 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 QaTraq 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.

A 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 QaTraq 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 QaTraq is split into three sections:

1. Test Case Title and Version info
2. Products and Components
3. Attachments
4. 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. Attachments - when you create a new test case record or modify an existing test case 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 QaTraq database. See Attachments for more information on saving and storing attachments.

4. 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'.

When you modify a test case what essentially happens is that a new test case is created as a completely new entity (for example if you modify TCA5-0.2 you create a new test case TCA5-0.3). This new version of the test case will not be included in existing test scripts (in the above example TCA5-0.3 is the new version of the test case but any test scripts containing TCA5 will still contains the old version of the test case TCA5-0.2).

This happens because you need to maintain the validity of the test results. For example, if you have already recorded a pass result against version 0.2 of a test case (TCA5-0.2) you don’t want to modify the test case and find that the original pass result is now associated with version 0.3 of the test case (TCA5-0.3), because version 0.3 of the test case could be completely different from version 0.2 of the test case.

However, in some circumstances, where say you haven’t yet run the test case (and the associated result is still ‘outstanding’) you may actually want to change the version of a test case included in a test script. So every time a test case is modified, and the version incremented, a check is made to see if the old version is included in an existing test script and if it is the user can select which test scripts need updating.

On the Modify Test Case page you will find a section to 'Search for Test Scripts that contain the current Test Case'. This section allows you to search for test script containing the current test case and update them automatically:

Title : filter criteria based on the titles of the test scripts which contain versions of the test case which is being modified
Script ID : filter criteria based on the test script ID of the test scripts which contain old versions of the test case which is being modified
Cases Version : radio buttons specifying filter criteria based on which versions of the test cases should be listed
All : list test scripts which contain ANY previous versions of a test case (e.g. if the version being modified is TCA5-1.1 then list test scripts which contain TCA5-0.1, TCA5-0.2, TCA5-0.3 etc)
Current (default) : list test scripts which contain only this version of the test case (i.e. the test case which is being modified. So if you are modifying TCA6-1.0 then only list test scripts which contain TCA6-1.0 will be listed)
Result : Only list test scripts containing test cases which have a specified result (for example you are only likely to list scripts which have tests cases with a result of 'outstanding'. You are not likely to list scripts which have test cases with results of Pass or Fail as these test cases have already been run).

When you click the [FILTER] button any test scripts already listed which have the ‘Update Script’ check box checked will remain listed (even if they don’t match the new filter criteria). Having searched and filtered the tests script containing the test case just check the boxes for the test scripts that you want to update to the new version of the test case. When you click 'Save and View' for the test case the test scripts selected will all be updated. Note that the results specified in the selected test scripts will be carried forward to the new version of the case in the script.

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 QaTraq 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 QaTraq are split into six sections:

1. Document Title and Version info
2. Parent Test Design
3. Intended Tester
4. Product and Product Version
5. Attachments
6. Plain Text content
7. 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. Attachments - when you create a new test script record or modify an existing test script 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 QaTraq database. See Attachments for more information on saving and storing attachments.

6. 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.

7. 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 Cases for more details about including and removing test cases in a test script.

When modifying test scripts you can change the versions, severity and priority of each individual test case included in the script (see Including and Removing Test Cases for more details about including and removing test cases in a test script).

For each included test case a drop down box is available which will allow you to select different versions of the test case. So for example if the first version of a test case (e.g. TCA12-0.1) has been modified and updated to version TCA12-0.2 then you will find a drop down box in the modify test script page which allows you to select either TCA12-0.1 and TCA12-0.2. Thus you can update the test script to include the latest versions of any test cases which have been modified.

When you modify a test script you can also change the Priority and Severity values of each test case included in the script. The priority value determines the order that the test cases are listed in the test script (and the test results). The severity can be used to indicate to the tester the importance of this test case should the test case fail (i.e. if it’s a high severity test case and the test case result is a fail then the severity of the bug raised should probably be high).

Copying test scripts gives you the capability to run the same test script on multiple versions of the same product or even completely different products. As you get new builds and you need to run a set of tests on each version just copy the test script. When you copy the test script first select which Test Design document the new script is related to and then alter the product, version and intended tester as required.

When you copy a test script you also copy the test cases that are included in that test script (see Including and Removing Test Cases for more details about including and removing test cases in a test script). This means that you also create a new set of test results that are associated with the test script and the test cases. When the new test results are created to go with the newly copied test script you have two options; you can copy the results from the original test script or you can reset the results records.

1) Copy the results All the results are copied from the original test scripts results. This means that if you have a ‘Fail’ result against a test case in the original test script you will have a ‘Fail’ result against the test case in the new test script. In fact when you copy a test script the following fields are also copied from the associated results; Product Version, Tester, Result, Comments and Defects

At first glance this might seem like a piece of useless functionality but consider the scenario where you might be branching a piece of software under test. You have already completed some tests prior to the branch but now you need to finish the outstanding tests on both branches. When you copy the test script and 'copy the results' you are provided with two partially completed test scripts; one for each branch.

2) Reset the results records In some situations though it is necessary to reset the Product Version, Tester, Results, Comments and Defects in the results records of the new test script. When you copy a test script and select the 'Reset Results Records' box the results in the new test script are reset as follows

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 cases 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.

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.

QaTraq 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 , QaTraq is not meant to be a defect tracking application. QaTraq only records the fact that there is a defect and provides a URL link to further defect details in a defect tracking application. QaTraq will not record the details about the defect.

The Query functionality in QaTraq allows the user to write, store and run pure SQL statements (requiring knowledge of Sql and QaTraq database structure). The Report functionality on the other hand provides users with pre-defined forms which run Sql queries behind the scenes (thus Reports require no knowledge of Sql).

The reporting functionality lends itself to the addition of new reports as and when new report include files are created by developers and users. Whilst only a couple of reports were included as part of the qatraq_0_7_beta release it is the aim of the QaTraq team to start releasing new reports for inclusion in QaTraq on a regular basis. If you want to start writing your own reports then take a look at the examples included in qatraq_0_7_beta release (found in the in the qatraq/reports directory) and read the section on reports in the design document (see the Stage 5 Design Document for more information).

Reports and Queries both work within the existing view/modify/new/delete/copy document structure. However, only when you 'view' a report or query are the associated SQL statements executed and the results displayed. Note that the SQL queries only work with SELECT statements (it is not possible to execute queries which modify the database).

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

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

Note also that no version control is applied to reports and queries. Each time a report or query is modified it will be saved with the same ID. Thus report and query Ids conform to the format ‘RPTxx’ or 'QRYxx' (eg RPT3 or QRY4) .