Menu

Introduction to qTest Objects

Overview

qTest Objects are components you create within your qTest environment. These objects can be edited, deleted, copied, or cut on the system tree 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

    Test_Plan_Releases.png

    Note:
    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 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 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 in Requirements will be mirrored in Test Design.

REquirements_tab.png

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. 

To manage qTest Requirements, refer to the article Create, Edit, Copy, and Delete Requirements. 


Example: This example shows a top-level module, named Imported from JIRA, and in that module are three nested modules named EBJ1 Sprint 3, Medium (P3) and EBJ1 Sprint 4. Within the Medium (P3) module there are 4 requirements. This project's Jira Requirement integration settings are organized to bring in requirements in a nested structured that contains Sprint and Priority. 
example_modules_2.png

 

Objects in Test Design

Test Design is also comprised of 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.

Find Test Cases in the Navigation Panel housed within Test Design Modules. Your Test Design Modules will be a logical grouping of similar Test Cases.
Example: Test Cases for a login screen for different types of users. 

Test_Case.png

Objects in Test Execution

Test Execution contains the most qTest Objects. Here, users can manage:

  • Releases
  • Test Cycles: the testing of a release can be broken into a number of shorter cycles and are assigned to an overall release, or you can assign them to a build within a release. A Test Cycle is a container that shows a high-level summary of its underlying Test Suites and Test Runs, including the execution results of these tests and any defects found. Within a given release, you may need to execute many types of tests such as new features and bug fixes. For this reason, you may have more than one Test Cycle within the release or even multi-level Test Cycles, which will be beneficial for organizing and reporting. A possible example of multi-level Test Cycles would be for new features that need to be tested on a browser version and a mobile version of your software. 
  • Test Suites: a set of the same type of test cases, such as functional tests, non-functional tests, sanity tests, or possibly even regression tests. Test suites are focused on addressing specific test objectives. For example, tests in a test suite may be grouped to validate specific components of your software or to test given levels of integration. A Test Suite can be regarded as the lowest level container to organize test runs. 
  • Test Runs: an uninterrupted period of time spent in executing a test case. 

 

These Objects are in the left Navigation Panel. 

Test_Execution_Objects.png

For more information on using Test Execution, refer to the Test Execution section of the Help Guide.

Defects

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

For more information on Defects tracking, refer to the Defects Section of the Help Guide.

Powered by Zendesk