qTest Glossary of Terms

Listed below are key terms that are used throughout the qTest suite of products. The general concepts originate from qTest Manager and branch to other qTest applications, while others are specific to Insights, Explorer/Sessions, Parameters, Launch, Pulse, or Scenario.

Please note, this is a living document and will have constant updates which are driven by new features and product enhancements.

General Concepts

The terms listed below originate in qTest Manager.

Objects: Objects can be edited, deleted, copied or cut on the system tree to manage your test project in a flexible manner.

  • Release: A Release represents an internal or external distribution of software once a development loop within a product’s lifecycle has been completed. In qTest, a start and end date of a Release must be defined.

  • Build: The Build information includes data on the relevant testing plan, tests conducted, test results, and Defect records. You can define Build as a Milestone. You might have a Build for your UAT environment and then another Build for a Beta release.

  • Module: Users can divide applications into modules, which are hierarchical groupings based on the product’s structure and functionality. Requirements and Test Cases can be assigned to specific module levels. Often, it is helpful to organize Requirements and Test Cases into logical groupings, according to application functionality. Modules are commonly shared between the Requirement tree and the Test Case tree. Creating or editing modules in the Requirement tree will affect the Test Design tree and vice versa.

  • Requirement: Requirements describe in detail what needs to be achieved in order for the software developed to meet its objectives.

  • Test Cycle: 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 Suite: Test Suites are comprised of 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 Cycles and Test Suites are simply containers for your Test Cases. How you use and organize these features are determined by your organization.

  • Test Case: A Test Case describes in detail what needs to be tested to meet quality objectives. A Test Case details steps, including actions and scenarios, and expected results.

  • Test Run: A Test Run refers to an uninterrupted period of time spent executing a Test Case. For each Test Run, the tester is provided with the instructions and resources required to perform the test. In addition, the Test Run may specify a choice of possible results and provide testers with the ability to attach supporting documents and comments.

  • Defect: A flaw that causes a component or system to fail to behave or function as expected. If encountered during execution, a Defect may cause a failure of the component or system.

For more information on qTest Objects, refer to Introduction to qTest Objects.

Root Page: This page is displayed when a user clicks the topmost object of any system tree. The name of the root object will correspond to the project. The user can collapse the system tree or expand it to view the entire structure.

System User Roles

  • Site Admin: The first user who registers a site on the Tricentis Web page will be granted full privileges on site settings page.

  • Project Admin: A user who is normally assigned to a project created by the Site Admin and who has all permissions enabled on their assigned project.

  • Project User: Any other users who are invited to the registered site by the Site Admin and added to a specific project by the Project Admin. The Project Admin can specify a Project User’s permissions and access rights for within a specific project.

qTest Menu: qTest’s major menus provide different capabilities that correspond to each step in the product testing life cycle. qTest includes the following System tabs: Test Plan, Requirements, Test Design, Test Execution, Defects, and Reports.

Tree panel: A hierarchical display of objects, for example, with the root page at the top and underlying objects at the bottom. The tree panel of each menu displays different objects:

  • Test Plan menu: Release tree

  • Requirements menu: Requirement tree

  • Test Design menu: Test Case tree

  • Test Execution menu: Test Run tree

Test Data Source: A test database that is used for a specific test suite. All test runs for a given test suite must be based on the data extracted from the associated test data source.

Insights

  • Analysis: Prebuilt reports grouped together by Quality, Coverage, and Velocity. Data tables are provided at the bottom of the window for each report type.

  • Explore Data tab: Objects of raw qTest data where you can generate and view charts at the report level. You will see the following tabs:

    • Formula: Allows you to create a new column as a formula in the data table. ex: display the duration of resolving defects, would be close date minus submit date

    • Filter: Filters that will apply to the data table, does affect the filters selected at the Global level. as the filters are combined for greater filtering

    • Chart: Allows you to create different charts based on filters selected. You can Add these charts to the gallery panel and they will display in the custom category.

    • Crosstab: Allows you to filter

  • Global Filter: This is specific to the user and you can include one or more projects. Filters selected will display on the chosen reports and on the right side of the window as a 'filter tag.'

  • Panel: Is defined as a chart or report that will display on a Dashboard.

    • System panel: Panel prebuilt by qTest

    • Custom panel: User-created panel

  • Dashboard: A collection of panels that you can group together using tabs within a dashboard.

    • Create Dashboard: Allows you to create your own Dashboards. If you select the Show in Menu check box the dashboard created will display in the dashboards drop-down.

    • Dashboards

      • Shared: Prebuilt container for dashboards that allows you to share dashboards to anyone with access to Insights.

      • Personal: Prebuilt container for user-created Dashboards.

        You can create a bookmark for Shared or User-created dashboards. This does not apply to 'Personal' dashboards.

    • Manage: This screen displays the Available Dashboards and any dashboards that are Saved with Filters.

      • Available Dashboards: Dashboards you created

      • Saved with Filters: Any Dashboard in the Saved with Filters section will open in a separate tab of your browser using a bookmark. You can share these Dashboards using the blue filter icon.

  • Gallery: Carousel of panels that are grouped together by category. A collapsible menu which uses drag and drop to move panels to a Dashboard.

  • Saved Reports tab: displays user saved reports for easy access and scheduling, which only apply to Analysis and Explore Data reports. Any saved report will display in the Manage window and will open in a new tab as a bookmark.

  • Embed Reports: Allows you to place a report in an external website such as Confluence.

  • Shareable URL: This is beneficial for a user without a qTest account to access a read-only shared Dashboard.

  • Drill-down: Allows you to filter down data further when you click on a chart, using the drill-down functions.

Pulse

Rules: Pulse Rules consist of Triggers and Actions, which are ultimately an 'if this trigger occurs, then I want Pulse to perform this action'. The Trigger occurs using a webhook and the Action is performed using program code.

Constants: Keys and values that are predefined and entered in the Action.

Action: Program code that you want to execute as part of a Pulse Rule.

Trigger: A unique webhook produced by the application that will not only be used to create your Pulse Rule, but it will also be entered into the separate application tool for complete integration.