Glossary of ALM Octane entities

This topic lists ALM Octane entities and their matching symbols.

Backlog and requirement entities

Requirement Folder RF A folder grouping a number of requirements.
Requirement R

Requirements describe aspects of your project whose approval and progress you want to track. These can include business goals, customer requests, functional requirements, and so on.

You can link requirements to tests and defects, to track coverage.

Epic

E

Epics are large components or aims for your product or project.

Epics are divided into features.

Define epics under the root of the backlog tree.

Feature

F

Features are mid-size functional goals. They are groups of actions or functions that you plan for your product or project.

A feature is divided into user stories, defects, quality stories and tests.

Define features under an epic or under the root of the backlog tree.

User Story

US

User stories describe actions that users of your product should be able to perform.

Define user stories under features or directly under the root of the backlog tree.

Quality Story

QS

A quality story provides a place to describe actions that should be done internally by your developers or quality engineers. For example, quality stories can be used to describe tests that should be authored or updated.

Define quality stories under features or directly under the root of the backlog tree.

Defect

D

Defects are bugs or flaws. Any action or function that does not work should have a defect set up to fix it.

Defects can be defined under features or directly under the root of the backlog tree.

Task

T

Tasks are action items within user stories, defects, and quality stories. Tasks describe the actions required to implement the defects and stories.

Back to top

Test entities

Manual Test

MT

Manual tests make sure an application works as expected by testing most of its features.

Manual test types include acceptance, end-to-end, regression, sanity, security, performance, and others.

This entity represents the test steps to perform in the application under test.

Gherkin Test

GT

Gherkin tests are a type of manual test. They use the Gherkin syntax and scenario structure. Gherkin test subtypes also include acceptance, end-to-end, regression, sanity, security, and performance.

This entity represents the scenarios to perform on the application under test.

Test Suite

TS

A container with set of tests grouped in one unit. Can contain manual tests and Gherkin tests that run sequentially, as well as executable automation tests that are triggered to run on a CI server.

Test suites contain no independent steps of their own.

Automated Test

AT

Automated tests are edited and managed in external tools, such as UFT, LoadRunner, and LeanFT, Performance Center. You can run the tests on automation and CI servers or on ALM and send the results to ALM Octane.

This entity represents the script (not editable) that is stored and maintained in the external tool.

Executable automated tests can run as part of a test suite in ALM Octane. For details, see Add UFT tests from an SCM repository.

Manual Test Run

MR A manual run of a test.

Gherkin Test Run

GR An automated run of a Gherkin test.

Test Suite Run

SR A run of a test suite.

Automated Test Run

AR A run of an automated test, by a CI server such as Jenkins or TeamCity.

Pipeline

PL

ALM Octane pipelines consist of pipeline steps, which represent the jobs that run on your CI server.

Pipelines enable you to interact with your CI server. For example, ALM Octane collects the results of automated tests that run on the CI server.

Pipeline Run PR

A run of a pipeline, by a CI server such as Jenkins or TeamCity.

Pipeline runs consist of builds, and can include information about failing automated tests, SCM commits related to this pipeline run, and more.

Build B

A build is the result of a pipeline step run.

  • A pipeline run consists of builds.
  • If a pipeline step runs automated tests, its build consists of automated test runs.
Vulnerability V Vulnerabilities are security issues found in your code by a security testing scan. After reviewing a vulnerability, you can create a relevant defect to fix in your code, or dismiss and close the issue.

Back to top

Configuration entities

Release

R

A release is a group of application changes made available to your users at the same time.

Releases can be divided into sprints or milestones.

Team

TM

Each team has a team lead as well as team members.

Workspace admins can assign team members and team leaders, and assign teams to releases. They can also estimate the team's velocity.

Back to top