Glossary / Terminology

This glossary explains the terms used in Appsvio Test Management (ATM) and in its documentation. Short forms used in the docs are in brackets.

Actual Result

A field on each test step in the execution window, next to Action, Data, and Expected Result. Testers write notes from the test there. See also Expected Result.

Appsvio Test Management (ATM)

A test management app for Jira Cloud, built on Atlassian Forge. ATM is available only for Jira Cloud, in the Standard edition. It supports both company-managed and team-managed spaces. See What is ATM.

ATM custom fields

ATM adds eight custom fields to Jira. Each one has its own entry in this glossary:

• ATM Environments
• ATM Preconditions
• ATM Repository
• ATM TE Progress
• ATM TE Status
• ATM Test Cases
• ATM Test Plans
• ATM Test Type

When you create the sample project, ATM adds them to the right screens for each testing object. When you save the configuration of a Testing Project, ATM adds them to the view of each mapped object. If you configure a space by hand, check these settings yourself. See ATM in Jira.

ATM Environments

A custom field on Test Executions and defects that holds the selected test environments. On defects, it lets you search for defects by environment. See Environment.

ATM Preconditions

A custom field on Test Cases that holds the preconditions as formatted text. See Precondition.

ATM Repository

A custom field on Test Cases that holds the folder of the Test Case in the Test Repository tree. ATM Repository is also the name of the tab in a Jira space that opens the Test Repository.

ATM TE Progress

A custom field on Test Executions. It shows the percentage of Test Case Executions in a final status. See Progress.

ATM TE Status

A custom field on Test Executions that holds the status of the Test Execution, from a predefined list. It needs an active license.

ATM Test Cases

A custom field on Test Plans and Test Executions that lists the linked Test Cases.

ATM Test Plans

A custom field on Test Executions and Test Campaigns. On Test Executions, it lists the linked Test Plans.

ATM Test Type

A custom field on Test Cases that holds the test type. It’s read-only and, for now, always Manual. ATM sets it when you add the first step. In an import file, the value must be Manual.

Atlassian Enterprise Certified (AEC)

An Atlassian Marketplace program for apps that meet the requirements of enterprise customers. ATM is Atlassian Enterprise Certified. See No data egress.

Atlassian Forge

Atlassian’s platform for cloud apps. Forge apps run on Atlassian infrastructure. ATM is built on Forge, and its data never leaves Atlassian. See Architecture.

Atlassian Government Cloud (AGC)

A separate Atlassian cloud environment for the US government and the companies that work with it. It meets the FedRAMP requirements. ATM doesn’t support AGC yet. See Atlassian Government Cloud.

Call test

A test step that calls another Test Case. During a Test Case Execution, the steps of the called Test Case appear in place of the Call test step. A Test Case that calls another one can’t be called itself. See Test Steps.

Configuration

The global settings page of ATM. Jira administrators open it with the Configuration button on the Testing Projects page. It has two sections: Environments and Test steps. See Global Environments.

Coverage report

A report that shows which requirements are covered by Test Cases and which aren’t. It works only when the Testing Project defines what a requirement is. See Coverage Report.

Data residency

Where app data is stored. ATM stores all its data on Atlassian’s side, in one of 11 regions. See Data Residency.

Defect

A Jira work item, for example a Bug, that you create or link during a Test Case Execution. In the execution window, Add Defect creates a new one and Link Defect links an existing one. You create it from a test step or from the whole Test Case Execution, and it’s related to that Test Case Execution. A good practice is a linked defect for every failed step. See Defects.

Environment

A test environment, for example Test, Staging, or Production. You usually set it on a Test Execution in the ATM Environments field. You can also add this field to defects. One Test Plan can run on several environments, each in its own Test Execution. Jira administrators manage environments in Configuration on the Testing Projects page. See Global Environments.

Evidences

A field on a test step in the execution window. Testers add screenshots there, and a counter shows the number of files. A good practice is a screenshot for every failed step.

Expected Result

One of the three default fields of a test step, next to Action and Data. During a Test Case Execution, testers see it next to the Actual Result field. See Test Steps.

Final status

A status that counts as done in progress bars. Which statuses are final comes from the ATM status configuration. See Test Campaign.

Flat view

A view of the Test Repository that shows the Test Cases of the current folder and all its subfolders. See also Tree view.

Folder

A group of Test Cases in the Test Repository. Some labels in the app call it a catalog, for example Add catalog, Delete catalog, and the default name New Catalog. Folders are optional, and a Test Case can be in only one folder. See Test Repository.

Import

Creating or updating many Test Cases at once from an Excel file (.xlsx or .xls). For now, you can’t import Test Plans, Test Executions, or Test Case Executions. See Import.

Work type

ATM adds Test Cases, Test Plans, Test Campaigns, and Test Executions to Jira as work types. It does this when you create the sample project, unless work types with these names already exist. We recommend naming these work types after the testing objects, for example Test Plan. See ATM in Jira.

Isolated Cloud

An Atlassian offering in which Atlassian products run on infrastructure dedicated to one organization. It’s for companies with high security and regulatory requirements. ATM supports Isolated Cloud from October 1, 2026. To install it there, contact Atlassian or selected Atlassian Solution Partners. See Atlassian Isolated Cloud.

Iteration

A repeated run of a Test Case Execution, for example a retest. Progress counts only the latest iteration. See Retests.

Jira administrator

Some actions in ATM are available only to Jira administrators. Only they can install the app, create the sample project, see the Configuration button, and create, edit, disable, or delete a Testing Project. See Permissions.

JQL

Jira Query Language, the query language of Jira search. You can search testing objects with ATM fields, for example "ATM Repository" = "folder_name". See Using Jira Fields.

Link type

The Jira link type that connects requirements with Test Cases. You choose it in the Testing Project, and it’s required when you map requirements. We recommend the link type that shows “is tested by” on the requirement and “tests” on the Test Case. The sample project uses it. The Testing Project wizard has no default link type. See Testing Elements.

No data egress

The app doesn’t send data outside the platform it runs on. Data from ATM never leaves Atlassian. See No data egress.

Precondition

The conditions that must be met before you run a test. In ATM, it’s the ATM Preconditions field on a Test Case, a Paragraph (text) field. During a run, testers see it in the Test Case Execution window above the steps. See Preconditions.

Progress

A progress bar that shows how much of the testing is done. A Test Execution shows progress from the statuses of its Test Case Executions. A Test Plan (ATM TP Progress) adds up its Test Executions, and a Test Campaign adds up its Test Plans. Only the latest iteration of each Test Case counts. For the full rule, see Test Campaign.

Repository Path

A column in the import file that sets the folder of a Test Case. Separate folder names with a slash. Missing folders are created during the import.

Requirement (REQ)

Any Jira work item that Test Cases verify, for example an Epic, a Story, or a Task. A requirement is linked to Test Cases with a Jira link, and it can have no, one, or many Test Cases. Requirements are optional in ATM, but the Coverage and Traceability reports need them. See About Requirement.

Runs on Atlassian (RoA)

A badge that Atlassian gives to Forge apps that store data only in Atlassian and don’t send it outside. ATM has this badge. See No data egress.

Sample project

A fully working sample test process with all testing objects. It has all work types, custom fields, and workflows configured, and it contains test data. It’s a company-managed space that keeps all testing objects in one space to make onboarding easier. When you create it, ATM adds the work types for testing objects to Jira and creates its own workflows for them. We recommend that you always create it when you start testing. Jira administrators create it with Create sample project in Apps › Test Management › Get started. See Quick Start.

Test Campaign (TCA)

An optional Jira work item that groups one or more Test Plans. The business uses it to follow testing progress, and it can act as a request for testing. One Test Plan can be in several Test Campaigns. See Test Campaign.

Test Case (TC)

The basis of test management. A Jira work item that describes a test with its test steps and precondition. You create it like any other Jira work item, with the Test Case work type. Test Cases are organized in the Test Repository and linked to requirements. See Create Test Case.

Test Case Architect

The Rovo agent in ATM. It proposes Test Cases for a requirement and creates the ones you choose. You start it with Create with Rovo Agent in the Test Management panel on a requirement. See Create Test Cases with Rovo Agent.

Test Case Execution (TCE)

A copy of a Test Case inside a Test Execution. It isn’t a Jira work item, but ATM’s own object. It can be assigned to a tester. Each step has its own status, and ATM sets the status of the Test Case Execution from them. After the first Passed step, the Test Case Execution is In progress. One Failed step makes it Failed, and all steps Passed make it Passed. You can also change the status by hand. Later changes to the Test Case don’t change existing Test Case Executions. See Test Steps Execution.

Test Execution (TE)

A Jira work item in which tests are run. You create it like any other Jira work item, or from a Test Plan or a Test Case. ATM creates a Test Case Execution for each selected Test Case. A Test Execution shows progress based on the statuses of its Test Case Executions, and it has its own status. It usually has an environment and a version. See About Test Execution.

Test Management panel

The ATM panel on the page of a Jira work item. On a Test Case, it holds the steps, requirements, Test Plans, Test Executions, and Test Case Executions. On a requirement, it shows the linked Test Cases and the coverage. See Coverage with Test Case.

Test Plan (TP)

A Jira work item that sets the scope of testing: the Test Cases to run. You can run a Test Plan many times, and each run is a separate Test Execution. See Test Plans.

Test Repository

The folder tree of Test Cases. Each Testing Project has one repository. You open it from the ATM Repository tab in the Jira space that holds the Test Cases. Testing often starts here, when you choose Test Cases for a Test Plan.

Test step

One action in a Test Case. By default, a step has three fields: Action, Data, and Expected Result. You can’t delete these default fields. In the Test steps configuration, you can turn off any of them, but at least one must stay on. During a Test Case Execution, each step has its own status: Passed, Failed, In progress, Blocked, or Not Executed. See Test Steps.

Test step version

A version of the test steps of a Test Case, for example V1 with the Default label. Changing the steps in a new version doesn’t change earlier versions. A new Test Execution uses the default version. See Steps Versioning.

Testing object

An object of the test process in ATM: requirement, Test Case, Test Plan, Test Campaign, Test Execution, Test Case Execution, or defect. All of them are Jira work items except Test Case Executions. The minimum test process needs Test Cases, Test Executions, and Test Case Executions. Test Plans and Test Campaigns are optional, but larger deployments practically need them. See Testing objects & Relations.

Testing Project

The test project in ATM. It sits above Jira spaces and connects them. It maps each testing object to a Jira space and a work type, and sets the link type between requirements and Test Cases. Mapping Test Cases, Test Plans, and Test Executions is required, while requirements, defects, and Test Campaigns are optional. Requirements and defects can be shared between Testing Projects. Every user can see the list of Testing Projects, but only Jira administrators can create, edit, disable, or delete them. See Testing Elements.

Testing Project Dashboard

The page of a Testing Project. It shows its configuration, counters of testing objects, Test Execution progress, and charts. See Testing Project Dashboard.

Traceability report

A report that follows the links from requirements through Test Cases and Test Case Executions to defects. Like the Coverage report, it needs requirements defined in the Testing Project. See Traceability Report.

Tree view

A view of the Test Repository that shows only the Test Cases of the current folder. See also Flat view.

Workflow

In the sample project, ATM creates its own workflows for its work types. You can also use Jira workflows for approval, for example to accept Test Cases or approve Test Plans. See ATM in Jira.

Work item

Jira’s current name for what it used to call a work item. All testing objects in ATM are work items, except Test Case Executions.