Introduction to qTest Objects

qTest Objects are components you create within your qTest environment. These objects can be edited, deleted, copied, or cut on the tree panel so that qTest remains both highly customizable and user-friendly.

Objects in Test Plan

Test Plan is the default homepage for each qTest Project because you can view the general project overview. Many of the fields you see here populate with data that you enter when creating the qTest Project. The Test Plan displays the following information:

• Name

• Start and End Dates

• Description

• Project Timeline

• Key Facts

• Associated Releases

  

  To view Releases, select the arrow on the "Release" drop-down menu.

In the Test Plan, you can create and edit two qTest Objects:

• Release: An internal or external distribution of software that is pushed once a development loop within a product's lifestyle has been completed.

• Build: Includes data on the relevant testing plan, tests conducted, test results, and defect records. A Release can have multiple Builds that you can define as a Milestone. An example would be a Build for UAT and another Build for your Beta release.

If your team uses an external ALM tool such as Jira, Rally, or VersionOne, the Release plan was likely already established in that external ALM. If that is the case, feel free to use the Test Plan as a lightweight feature to create the Releases as “containers” to build actual plans that you will see in Test Execution.

For step by step instructions on how to use the Test Plan, refer to the Test Plan for Releases and Builds article.

Objects in Requirements

Requirements in qTest are synonymous with a user story/issue, which describe in detail what needs to happen for the software you are developing to meet its objectives. You will link your Test Cases to your Requirements. The structure you create on Requirements tab will be mirrored on the Test Design tab.

In qTest, you can group your Requirements together and nest them inside of Modules. This allows you to create hierarchical groupings based on the product’s structure and functionality that has one common objective, such as a Sprint or epic. You can even have multiple levels of Modules to group like items together, such as Requirements worked by different teams within a Sprint.

This example shows a top-level Module, MD-7 Common, and in that module is a nested module, MD-10 Free Trial. Within the nested Module, there are two Requirements. This project's Jira Requirement integration settings are organized to bring in Requirements in a nested structured that contains Sprints and Priorities.

Objects in Test Design

Test Design also comprises Modules, but includes another qTest object: the Test Case. A Test Case describes in detail what needs to be tested to meet quality objectives and will detail steps, including actions, scenarios, and the expected results.

Test Cases are located in Test Design Modules in the tree panel. Your Test Design Modules will be a logical grouping of similar Test Cases, such as Test Cases for a log in screen for different types of users.

Objects in Test Execution

Properly organizing your test execution objects is critical to your team’s success. The organization of objects on the Test Execution tab not only affects how testers will use qTest on a daily basis but also heavily influences reporting in qTest Insights. As long as you understand the hierarchy of objects on the Test Execution tab, you can organize your data however you want to meet the needs of your team.

For more information about creating objects on the Test Execution tab, refer to Create Test Execution Objects.

• Releases. A Release is a testing milestone during which certain requirements must be developed and tested. Releases can be either manually created in qTest or imported directly from a third-party Application Lifecycle Management (ALM) tool, such as Jira, Rally, or VersionOne. Both manual and imported Releases are mirrored between the Test Execution tab and the Test Plan tab.

  

• Test Cycles. Test Cycles are nested in Releases. Test Cycles show a high-level summaries of the associated Test Suites and Test Runs, including the execution results of these tests and any Defects found, and can be useful for separating different areas of testing within a Release. For example, you may have a Test Cycle for testing an application on a browser and another Test Cycle for testing the application on a mobile device. You can also nest Test Cycles within Test Cycles to create sub-Test Cycles for further levels of organization. For example, in the browser Test Cycle, you may create three sub-Test Cycles for testing the application on Internet Explorer, Chrome, and Safari.

  Test Cycles directly underneath a Release	A sub-Test Cycle within a Test Cycle

• Test Suites. Test Suites are nested in Test Cycles. Test Suites are used for more granular groupings of Test Runs. For example, tests in a Test Suite may be grouped to validate specific components of your software or to test given levels of integration. You could also use Test Suites to group sets of the same types of Test Cases, such as functional tests, non-functional tests, sanity tests, or regression tests.

  

• Test Runs. Test Runs are single instances of executed Test Cases. Test Runs are located in the Test Run grid on a Release, Test Cycle, or Test Suite screen.

  

Defects

qTest Manager also tracks objects called Defects. Defects are any flaws that cause a component or system to fail to behave or function as expected.