ALM Octane User Guide PDF

ALM Octane
Software Version: 12.60.4
ALM Octane User Guide
Go to HELP CENTER ONLINE

http://admhelp.microfocus.com/octane/
Document Release Date: July 15, 2018 | Software Release Date: July 2018
Legal Notices
Disclaimer
Certain versions of software and/or documents (“Material”) accessible here may contain branding from Hewlett-Packard
Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by
Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks
is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.
Warranty
The only warranties for products and services of Micro Focus and its affiliates and licensors (“Micro Focus”) are set forth in
the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. Micro Focus shall not be liable for technical or editorial errors or omissions contained
herein. The information contained herein is subject to change without notice.
Restricted Rights Legend

Contains Confidential Information. Except as specifically indicated otherwise, a valid license is required for possession, use or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.
Copyright Notice
© Copyright 2016-2018 Micro Focus or one of its affiliates
Trademark Notices
Adobe™ is a trademark of Adobe Systems Incorporated.
Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.
UNIX® is a registered trademark of The Open Group.
This product includes an interface of the 'zlib' general purpose compression library, which is Copyright © 1995-2002 Jean-
loup Gailly and Mark Adler.
ALM Octane (12.60.4) Page 2 of 598

Contents
ALM Octane 1
Welcome to ALM Octane 22

Introducing ALM Octane 23
Get started 23
Set up the environment 24
Product versions 24
Micro Focus DevOps Suite 24
What's new in 12.60.4 25
Roles and permissions 25
Usability 25
IDE integrations: Eclipse 26
Pipelines and CI servers 26
GDPR: Conditions For Consent 27
Administration 27
Synchronization 28
LDAP (on-premises) 28
REST API 28
What's new in 12.55.32 (SaaS) 28
What's new video 28
User management 29
Administration 29
Usability 30
Testing 31
Integrations 31
GDPR-compliance enhancements (technical preview) 31
REST API 32
What's new in 12.55.25 (SaaS) 32
What's new video 32
Usability 32
Settings and configuration 33
UFT Integration 34
Integrations 34
REST API 34
Help Center search 34
ALM Octane lifecycle 35
Manage the backlog and track release quality 35

Track build quality 36

Incorporate test and build results into overall product quality 36
Track product quality 36
Analyze quality 36
ALM Octane with Agile and waterfall 37
Agile development flow 37
Traditional waterfall development flow 45
ALM Octane modules 52
ALM Octane editions 53
Editions overview 53
Trial license 55
License management 55
Team Edition 56
Team Edition overview 56
Working with Team Edition: End-to-end flow 57
System requirements 57
Hardware 58
Software 59
Database and Elasticsearch 60
Integrations 60
Installation, setup, and synchronization 61
Set your language 62
Change your own UI language 62
Set another ALM Octane user's UI language 62
Set the language for the ALM Octane site or a space 62
Known issues 63
Populate your system with demo data 63
Common flows 65
User help 66
Basics 68
Glossary of ALM Octane entities 69
Backlog and requirement entities 69
Test entities 70
Configuration entities 72
Access your assigned work 72
What does the My Work module include? 72
Manage your items 73
Create a rule to assign items 74
Advance the phase of an item 74

Attach files to items 75

Attributes, tags, and environments 76
Attributes 77
Tags 77
Environments 78
Collaborate with an item's stakeholders 79
Comment on items 80
Date formats 81
Duplicate an item 82
How to duplicate items 82
Duplicating requirements 82
Edit forms 83
Receive notifications and emails 83
Follow an item 83
Configure notifications 84
Get notified about comments 84
Personalize your display 85
Filter 85
Select grid columns 85
Sort 86
Group 86
Favorites 86
Preview an item 87
Relate items to other items 88
Relate items 88
Examples 89
Types of relations 89
Reporting in ALM Octane 91
Create dashboard views 91
Export information to Excel 91
Get items using the REST API 92
Search for information 92
Use the project global search 92
Search in context of a grid or tree 93
View an item's history 93
When to use the Backlog and Quality modules 94
Requirement management 94
What are requirements? 95
How are requirements related to backlog items? 95
Working with requirements 96
Author mode and Manage mode 96
Define a requirement in Author mode 97

Define a requirement in Manage mode 98

Associate tags, releases, features, defects, and tests with a requirement 98
Export requirements to Word and PDF formats 99
Analyze requirements 100
Backlog management 100
What is the ALM Octane Backlog? 100
The ALM Octane Backlog cycle 101
Glossary of backlog entities 102
Backlog root 102
Epics 102
Features 103
Backlog Items 103
User stories and quality stories 103
Defects 104
Tasks 105
Tests 105
Project management flow 106
Set up releases, teams, and workflows 106
Build your backlog 106
Plan your release 107
Track progress 108
Analyze and monitor your release quality 110
Build the product backlog 110
Create the Backlog 110
Fill in Backlog fields automatically 111
Rank the Backlog 111
Rank with WSJF attributes 112
Update multiple backlog items 113
Import backlog items 113
Step 1: Prepare the import file 113
Step 2: Import backlog items 117
Set up and manage release plans 118
Build the release backlog 118
Split unfinished features 119
Move items to another release 120
Backlog planning buckets 121
Open planning buckets 121
What does the planning bucket display? 121
Balance release and sprint workloads 122
Velocity vs. capacity 123
Set the default sprint velocity 123
Set sprint velocities 123

Plan release and sprint backlogs 125

Track velocity and capacity 125
Use-case scenario: Setting your team's velocity 126
Manage the team backlog 128
Edit your team's capacity per sprint 128
Assign items to team members 128
Track team progress 129
Team planning buckets 131
Work on your stories 132
Break items into tasks 132
Use the task board to manage work 132
Work on assigned items 133
Block an item 133
Track work completion progress 134
Split unfinished user stories 134
Use the Board View 135
What is the Board View? 136
About the Story Board 136
Customize the Story Board display 136
Set Story Board workflow rules 138
Add items 139
Perform sprint closure and retrospective 140
Enable the team retrospective area 140
Address incomplete items 140
View a sprint scope change report 141
Perform sprint retrospective 142
Create and run tests 142
Analyze release progress 143
Progress column 143
Planning buckets 143
Overview tab widgets 145
Release Forecast widget 145
Assign items to application modules 146
Quality management 146
How does ALM Octane measure quality? 146
Working with application modules 147
Work with application modules 148
Plan the application module structure 148
Build the application module tree 149
Add user defined fields to the application module 150
Assign items to application modules 150
Create and manage rules to assign automated tests 151

Create and run tests 154

Report and track product defects 154
Report defects 154
Track and analyze defects 155
Copy a defect to a different workspace 156
Analyze application area quality 157
Analyze specific application area quality 158
Identify application modules affected by recent development 158
CI Pipelines 159
What are pipelines? 159
How ALM Octane builds a pipeline's topology 161
Displaying pipelines in ALM Octane 161
DevOps CI server integration flow 162
Overview 162
Collect data from your CI server 162
Connect the CI data to ALM Octane entities 162
Reflect the integrated data in ALM Octane's dashboards and grids 163
Create and configure pipelines 163
Add a pipeline in ALM Octane 164
Customize your pipeline display 166
Explore a pipeline's graphical representation 166
Label and configure pipeline steps 169
Filter pipeline steps 174
Delete a pipeline 174
Special pipeline types 174
Run pipelines 175
What happens when a pipeline runs? 175
Trigger a pipeline run from ALM Octane (Optional) 176
View and analyze the pipeline overview 176
View pipeline run results 177
Analyze pipeline run results 180
Additional information on pipeline overview widgets 181
Track code changes 182
View and share a live summary of your pipelines 182
Failure Analysis Insight cards 183
Analyze builds 186
Build details 186
Build failure classification 187
Classify build failures manually 188
Create rules to classify build failures automatically 189
Edit or delete classification rules 190
Analyze tests 191

Overview 191
Prerequisites 192
Test run details 192
Assign someone to investigate failures 194
Best practice: Involve committers in pipeline failure analysis 195
Expand your test failure analysis 196
Track changes committed to your Source Control Management system 199
Overview 199
Use cases for tracking commits 200
Prerequisites 201
Track commits associated with a pipeline run 201
Track commits associated with backlog items 202
Use the Commits tab to track committed changes 202
Use the dashboard to analyze your commit activity 204
In the Tests tab, find commits related to failures 204
Map SCM users to ALM Octane users 204
Troubleshooting 205
Identify problematic tests 205
Identify hotspots in your code 207
What is a hotspot? 207
How does ALM Octane measure hotspots? 207
Set up the hotspot dashboard widget 207
Assess potential risk using the hotspot widget 208
Identify risky commits and features at risk 210
Identify application modules at risk 211
Track security vulnerabilities 212
Overview 212
Prerequisites 212
View security assessment results in ALM Octane 213
Manage the discovered vulnerabilities 213
Track code coverage in pipeline runs 214
Code coverage overview 214
Connect ALM Octane to code coverage data 214
View code coverage data in ALM Octane 215
The 'Code coverage by package' widget 216
View code coverage data in ALM Octane 218
The 'Code coverage by package' widget 220
Testing 222
Manual testing flow 223
The testing process 224
What kind of testing can I do? 224
Testing Design 225

Test Development 225

Test Execution 226
Test Analysis 226
Automated testing flow (pipelines) 226
Overview 227
Prepare your testing tool environment 227
Set up a Jenkins server to trigger test runs 227
Set up a Jenkins job to run tests using the testing tool 228
Create a pipeline in ALM Octane containing the Jenkins jobs 229
Run the pipeline 230
Use test assignment rules to connect results to your ALM Octane entities 230
Analyze test results 231
Create manual tests 231
Create tests and add test steps 231
Use parameters in tests 233
Manual test syntax 235
Test syntax 235
Format text in the test script 236
Create Gherkin tests 237
Why use Gherkin tests? 237
Create Gherkin tests 238
Add test scenarios 239
Prepare your Gherkin tests for automation 240
Gherkin test syntax 241
Feature section 241
Background section 242
Scenario section 242
Scenario Outline 243
Import manual tests and test suites 243
Step 1: Prepare the import file 244
Step 2: Add test steps to your import file 247
Step 3: Add test suite tests to your import file 247
Step 4: Import tests and test suites 248
Link manual and Gherkin tests to automated tests 248
Create test suites 249
What are test suites? 250
Create test suites 250
Add tests to a test suite 250
Parameterize UFT tests 251
Run manual and Gherkin tests 251
How ALM Octane runs tests 252
Run tests 252

Assign statuses to test steps 253

Report defects during a run 254
Add attachments to a run or step 254
Stop the run and see results 255
Run and edit manual tests in Sprinter 256
Plan and run test suites 257
Plan a test suite run 257
Run a test suite 258
View the suite run results 260
Use versions of test scripts 260
Save test versions 261
View versions 261
Revert to a previous version 261
Compare versions 262
Manage releases assigned to versions 262
Automate Gherkin tests 263
Gherkin automation process 263
Prerequisites 264
Create and download the Gherkin test 264
Add the OctaneCucumber runner class to your automation project 265
Create a build job in Jenkins 266
Add the build job to a pipeline 266
Run the pipeline 266
Add automated tests 267
Overview 267
Creating automated test entities 268
Add UFT tests from an SCM repository 269
Add automated tests from runs in a pipeline 269
Add automated tests from external test runs 270
Assign tests to application modules and backlog items 270
Send automated test run results to ALM Octane 271
Set up API access 272
Prepare your test results 272
Decide how to send test results to ALM Octane 272
Download a Test Result Collection tool 273
Push results to ALM Octane 273
Track your test results in ALM Octane 273
Test results XML sample 274
Run automated tests from ALM Octane 275
Run automated tests as part of a pipeline 275
Run UFT tests as part of a test suite 276
Troubleshooting a UFT test run 277

Analyze automated test run results 278

What are you analyzing? 278
Examine failures from test runs 279
Examine test failures from a pipeline 281
Examine test results in an external tool 281
Examine overall automation test results 281
Analysis and reporting 282
Analyze release quality 282
Transition from release to product quality 283
Analyze product quality 285
Analyze build quality using pipeline data 286
Use-case scenario: Performing quality analysis 287
Use the ALM Octane Dashboard 290
What is the dashboard? 290
Set up the dashboard 290
Configure widget data settings 291
Use dashboard widgets for analysis 293
Integrations 297
ALM Octane DevOps integrations 298
Overview 298
IDE integrations 299
Source Code Management (SCM) integrations 299
Build automation: CI server integrations 299
Testing tool integrations 300
Security testing integrations 301
Integrations with Commercial Off the Shelf software (COTs) 301
Monitoring tool integrations 302
Additional integrations using the REST API 302
Functionality supported by CI integrations 302
Functionality supported by IDE integrations 304
Access and credentials 305
Set up API access 305
Overview 306
Integration types 306
SaaS: Internal integration types 307
Create API access keys 308
Modify API access keys 308
Revoke API access 309
Regenerate API access 309
Set up credentials 309

Overview 310
Add credentials 310
Delete credentials 310
Synchronization 310
Set up the Integration Bridge Agent 311
Synchronization 311
Trigger Webhook rules 312
Integration Bridge Agent system requirements 312
Download and install the Integration Bridge Agent 313
Prerequisites 313
Download the bridge from ALM Octane 313
Install the Integration Bridge 314
Installing multiple bridges 317
Integration Bridge security 317
Communication with ALM Octane using OAuth authentication 317
Communication via SSL 318
Password encryption 318
Security recommendations 319
Integration Bridge automatic upgrades 320
Manage connection setup 320
Endpoint Credentials Manager 321
Set ALM or JIRA credentials (Endpoint Credentials Manager) 321
Connecting to ALM using SiteMinder single sign-on (SSO) 322
Define ALM or JIRA credentials and proxy 322
Modify ALM Octane credentials and proxy 322
Set ALM or JIRA credentials (CLI) 323
list 323
listEndpointTypes 324
listCredentialIds 324
listEndpointTypeParams 325
create 326
update 328
delete 329
help 329
Configure a proxy for domain connections 329
Set ALM Octane credentials 331
setAuth 331
help 332
Configure a proxy for ALM Octane connections 332
setAddress 332
removeProxyConfiguration 333
setAuth 333

removeAuth 333
help 334
ALM Octane Synchronizer proxy support 334
Start and stop the Integration Bridge 334
Uninstall/Remove the Integration Bridge 336
To uninstall a bridge permanently 336
To uninstall a bridge to upgrade or move it 337
Upgrade the Integration Bridge 338
Upgrade process 338
Manual upgrade on the same server 339
Manual upgrade and installation in a new location 339
Integration Bridge troubleshooting 340
Synchronize ALM Octane with ALM or JIRA 343
Synchronization overview 344
Synchronization links and endpoints 345
Supported ALM and JIRA versions 345
Synchronization steps 345
Prerequisites 346
Synchronization workflow 346
Prepare for ALM synchronization 348
Optional: In both endpoints, create corresponding ID fields 348
Create a subset of requirements or releases 348
In ALM, prepare requirement types to match ALM Octane's (requirement synchronization) 350
Check for releases that already exist in both endpoints (Releases synchronization) 351
In ALM, create or modify fields 353
ALM version control 354
Notes for epics, features, teams, and attachments 355
Notes about maximum record sizes 355
Prepare for JIRA synchronization 355
Create mandatory entities in ALM Octane and JIRA 356
Create optional entities if needed 356
Synchronize sprints 357
Mapping multiple JIRA projects 357
Notes and limitations 360
Step 1: Define a Synchronizer Admin user 361
Step 2: Define the synchronization scope 361
Create favorites 362
Synchronize past releases 363
Step 3: Create a synchronization link 363
Define connection settings 364
Define link properties 365
Map requirement types (requirement links) 366

Set the rules that define which endpoint controls the synchronized entities 366
Optional: Select favorites (requirement and defect links) 368
Optional (ALM only): Define an alternate root folder (requirement and release links) 368
Optional: Specify how to handle requirements whose hierarchy does not match the backlog
tree (requirement links) 369
Specify how to handle existing or past releases (release links) 369
Next Steps 370
Step 4: View and edit link configuration 370
Edit general link settings 371
View or edit basic link details 372
View link status 372
Check connectivity to ALM or JIRA 373
View or modify synchronization favorites (defect and requirement links) 373
For ALM synchronization only: View or modify the alternate root folder 373
View the setting for handling requirement hierarchy mismatch (requirement links) 374
Edit requirement type mapping (ALM synchronization only) 374
Edit synchronization rules 375
Edit field mapping 376
Field mapping overview 377
Notes about Type, Attributes, and Required in the Field Mapping tab 377
Map a pair of fields or define constant values 377
Additional field mapping tasks 379
Field mapping guidelines 381
Examples of automatically mapped fields: ALM or JIRA defects 384
Example of mapping field values: ALM Octane Phase and ALM or JIRA Status 386
Map user list fields 387
Automatic user mapping 388
Manual user mapping 388
Step 5: Configure synchronizer notifications 390
Link notifications 390
Bridge upgrade notifications 391
Step 6: Run synchronizations 391
Step 7: Review link summaries and error details 395
Link status reference 397
ALM Octane Synchronizer FAQs and troubleshooting 399
DevOps integrations 403
Set up CI servers 403
Prerequisites: Obtain API access and make sure your CI server is supported 404
Install the ALM Octane CI plugin on your CI server 404
Add CI servers on ALM Octane 405
Manage your CI servers 405
Install and configure the ALM Octane CI plugin on your CI server 406

Plugin overview 407

Prerequisites 407
Install the ALM Octane CI plugin 408
Configure the ALM Octane CI plugin to access ALM Octane 409
Moving an existing CI server to a new address 412
Upgrade from the ALM Octane CI Jenkins plugin to the Application Automation Tools
plugin 412
Set up your SCM system 413
Enable linking to your repository viewer (Git or SVN only) 413
Customize commit message patterns 414
Create and manage test assignment rules 416
Introduction 416
Create test assignment rules 417
Run test assignment rules 418
Manage test assignment rules 418
Manage all build failure classification rules 419
Best practices for managing rules 419
Create a build failure classification rule 419
Modifying a rule that is already in use 420
Testing integrations 420
Set up UFT integration 421
ALM Octane-UFT integration flow 421
Before you set up the integration 422
In Jenkins, set up the connection to ALM Octane 423
In ALM Octane, add your Jenkins CI server 423
Create a testing tool connection in ALM Octane 423
Assign the tests to your backlog and application modules 424
Setup Jenkins and UFT so Jenkins can trigger UFT test runs 425
Set up security testing integration 427
Overview of the ALM Octane integration with Fortify on Demand 427
Prerequisite: Set up Fortify on Demand and ALM Octane to integrate with Jenkins 428
Create a Fortify on Demand security tool connection in ALM Octane 428
Create a pipeline with a Fortify on Demand Upload step 429
Configuration options 429
ChatOps integrations 429
Set up Slack 430
Overview 430
Configure integration with Slack 430
Create a Slack app for ALM Octane (on-premises) 431
IDE integrations 432
Work in IntelliJ IDEA 433
About the ALM Octane plugin for IntelliJ IDEA 433

Prerequisites 433
Download and install the ALM Octane plugin for IntelliJ IDEA 434
Connect to ALM Octane 435
Work on your ALM Octane items 436
Work in Eclipse Oxygen IDEs 440
Overview 440
Prerequisites 441
Download and install the plugin 441
Work in the Microsoft Visual Studio IDE 448
Overview 448
Prerequisites 448
Download and install the plugin 449
Reporting integrations 452
OData support for extended reporting (technical preview) 452
Overview 452
Supported OData versions 453
Prerequisites 453
The ALM Octane server base URI 453
Authenticating 453
Accessing ALM Octane data from a reporting or BI tool 454
Scenario: A template for ALM Octane OData and Power BI 454
Scenario: A traceability report with ALM Octane OData and Power BI 454
Configuration 464
Installation guides 465
Initial setup 465
Log in to Settings 465
Set preferences 465
Learn about spaces and workspaces 466
The configuration flow 466
Site configuration (on-premises) 467
Administer the site (on-premises) 468
About the site 468
Manage servers 468
Manage users at the site level 469
Manage spaces at the site level 471
Set configuration parameters 473

View sessions 473

Manage licenses (on-premises) 474
License modes: Standalone or shared 474
License types: Named or concurrent 474
Install a standalone license 475
View license and session details 476
Calculate license usage 476
Share licenses with ALM or Quality Center 477
Set configuration parameters (technical preview) 479
Overview 479
How to set configuration parameters 480
Configuration parameters 480
Set up LDAP (on-premises) 502
LDAP configuration flow 503
Plan how to set up LDAP user authentication 504
Export users from LDAP 507
Import LDAP users into ALM Octane 508
Include LDAP users in ALM Octane (on-premises) 509
Update LDAP user and server properties (optional) 510
Change passwords 511
Change your own password 511
Change another user's password (on-premises) 512
Space configuration 513
Manage spaces 514
About spaces 514
View spaces for a site (on-premises) 516
Create a space (on-premises) 516
Edit settings for a space 517
Create workspaces 517
Delete workspaces 517
Manage users 517
Manage storage 519
Upgrade spaces (on-premises) 519
See a space's background jobs (on-premises) 519
Manage workspaces 519
About workspaces 520
Create a workspace 522
Edit workspace settings 522
Manage users 522
Deleting workspaces 523
Managing workspace storage 523
Manage users 524

About managing users 524

Ways to add users 525
Sharing users between spaces (Enterprise Edition) 526
Add a user 526
Edit a user 527
Include existing users into a workspace 527
Activate or deactivate a user 528
Delete a user 528
Map ALM Octane users to SCM users 529
Assign roles and permissions 529
Overview 530
Sharing roles and permissions between spaces 530
Permissions 531
Predefined roles 533
View roles and permissions 533
Create roles 533
Edit permissions 533
Assign or remove roles 534
Set up a release 535
Sharing releases between spaces 536
Add releases 537
Update release information 537
Set the current and default releases 539
Deactivate a release 540
Manage teams 540
Overview 540
Sharing teams between spaces 541
Create teams 541
Assign a team to releases 541
Edit a team's details 542
Adjust a team's capacity per sprint 542
Design forms 543
Overview 544
Sharing forms between spaces 544
Predefined forms 545
Working with forms 546
Customize fields 547
Sharing UDFs between spaces 547
Add a user-defined field 549
Set attributes for the user-defined field 551
Delete a user-defined field 551
Change field display labels 552

Set up lists 553

Overview 553
Sharing lists between spaces 553
Create a user-defined list 554
Modify a system list 555
Delete a user-defined list 556
Set up workflow phases and transitions 557
Overview 557
Sharing phases and workflows between spaces 557
The workflow diagram 559
Sample workflows 561
Set up workflows 563
Create workflow rules 565
Set up rules 568
Overview 568
Accessing rules 568
Sharing rules between spaces 568
Define rules 569
Examples 576
Understand rule activation and performance 578
When are conditions evaluated and actions performed? 578
Does the order affect how the rules run? 580
My organization has many rules. Any tips on how to list them in the grid? 580
Do shared space rules or workspace rules take precedence? 581
Trigger webhooks for other applications 581
Overview 581
Configure proxies 581
Customize Trigger Webhook rules 582
Set up credentials 582
Install an integration bridge (on-premises) 582
Understand the webhook request payload format 583
Set up a web service at the endpoint 588
As you work in ALM Octane, webhooks are triggered 589
Listen for ALM Octane webhooks 589
Overview 589
Install the listener 590
Run the listener 591
Update the Trigger Webhook rule to call the listener 592
Trigger the webhook 592
Troubleshoot rules 595

Send Us Feedback 597

Welcome to ALM Octane
ALM Octane provides comprehensive quality, build, and test management to your organization.
You can track quality on a release-by-release basis, and also track overall product quality.
Here are some basics about what ALM Octane can do for you and how to get started using the
application.
In this topic:
• Introducing ALM Octane 23
• Get started 23
• Set up the environment 24
• Product versions 24
• Micro Focus DevOps Suite 24
• What's new in 12.60.4 25
• Roles and permissions 25
• Usability 25
• IDE integrations: Eclipse 26
• Pipelines and CI servers 26
• GDPR: Conditions For Consent 27
• Administration 27
• Synchronization 28
• LDAP (on-premises) 28
• REST API 28
• What's new in 12.55.32 (SaaS) 28
• What's new in 12.55.25 (SaaS) 32
• ALM Octane lifecycle 35
• Manage the backlog and track release quality 35
• Track build quality 36
• Incorporate test and build results into overall product quality 36
• Track product quality 36
• Analyze quality 36
• ALM Octane with Agile and waterfall 37
• ALM Octane modules 52
• ALM Octane editions 53
• Editions overview 53
• Trial license 55
• License management 55
• Team Edition 56
• System requirements 57
• Hardware 58
• Software 59
• Database and Elasticsearch 60
• Integrations 60
• Installation, setup, and synchronization 61

Introducing ALM Octane
• Set your language 62

• Change your own UI language 62
• Set another ALM Octane user's UI language 62
• Set the language for the ALM Octane site or a space 62
• Known issues 63
• Populate your system with demo data 63

ALM Octane is a web-based application lifecycle management platform that enables teams to
collaborate easily, manage the product delivery pipeline, and visualize the impact of changes.
In this topic:
l "Get started" below
l "Set up the environment" on the next page
l "Product versions" on the next page
Get started
Before you begin...
To get started, we recommend that you learn about the ALM Octane
lifecycle to gain a high-level picture of what you can do in ALM Octane.
For details, see "ALM Octane lifecycle" on page 35.
How do I use ALM Octane?
To understand how to use ALM Octane, read about the common

workflows. These describe how to use ALM Octane in your day-to-day
work.
For details, see "Common flows" on page 65.
Let's go!
When you're ready to begin, log in to ALM Octane and start working in
the modules that are relevant for your needs.
For details, see "ALM Octane modules" on page 52.

Set up the environment

Initial setup
Before users can work with ALM Octane, the administrator needs to perform
initial setup tasks.
For details, see "Initial setup" on page 465.
What are workspaces?
Administrators should have a basic understanding of shared spaces and

workspaces.
For details, see "Initial setup" on page 465 and "Manage spaces" on
page 514.
Generate demo data
To enable you and your users to get familiar with ALM Octane, you can
automatically generate demo data to use for experimentation.
For details, see "Populate your system with demo data" on page 63.
Product versions
The following table maps the product version with your on-premises installation:
On-premises Installation Software Version

ALM 12.55 CP6 12.55.17
ALM 12.55 CP5 12.55.8
ALM 12.55 CP4 12.55.4
ALM 12.53 CP3 12.53.20
Micro Focus DevOps Suite

ALM Octane is the cornerstone of the Micro Focus DevOps Suite: An integrated suite of agile and
DevOps tools in a single package.
The DevOps Suite helps your Agile and DevOps teams govern, test, and monitor your software.
For more information, or to arrange a demo, see DevOps Suite.

What's new in 12.60.4
Next steps:
l "ALM Octane modules" on page 52
l "Common flows" on page 65
l "ALM Octane lifecycle" on page 35

The following new features and enhancements are introduced in ALM Octane version 12.60.4.
On-premises: For other enhancements in the 12.60.4 (CP7) on-premises release, see also: What's
new in 12.55.32 and What's new in 12.55.25 in the online Help Center.
Roles and permissions

In the previous update we enabled you to create custom roles. In addition to that, you can now:
l Customize predefined roles. Assign and remove permissions of the predefined roles.
l Rename user-defined roles.
Usability
The following usability enhancements are now available:
Area Enhancement
Application Use the new Details tab to add user defined fields to an application module
Module Details and apply cross-filters in the Backlog and Team Backlog modules and in the
tab Dashboard.
Analyze You can now display Requirements data in custom summary widgets.
requirements
Select Requirements as the data source, or display test or test run coverage
of requirements.
Export test runs Export manual and Gherkin test run steps to an Excel spreadsheet. You can
export up to 20 test runs.
Toolbar We’ve moved the Choose Columns, Sort, Group By, and Full Screen buttons
changes to the right side of the toolbar.

High contrast You can now apply a high contrast theme to your UI from your personal
theme details area.
Cross filter You can now cross filter items according to a user’s team. For example:
users by team Create a filter that lists test runs that are assigned to all users in a team.
StormRunner When analysing results of automated StormRunner Functional tests, you

Functional can now open the detailed StormRunner Functional report directly from the
integration Tests tab.
IDE integrations: Eclipse
You can now modify items when working in the ALM Octane plugin for Eclipse. Download the
newest ALM Octane plugin for Eclipse to use this feature.
Pipelines and CI servers

The following enhancements have been made in the Pipelines and CI servers area:
Improved automated test assignment rules

You can now create test assignment rules to automatically populate automated tests with the
following fields: test framework, test type, test level, and testing tool. For details, see "Create and
manage test assignment rules" on page 416.
Expanded TFS support

In addition to Microsoft Team Foundation Server (TFS) 2017, ALM Octane now supports
integration with TFS 2015 as a CI server.
Pipeline UI enhancements
l The Analysis tab has been replaced with the Builds and Tests tabs, helping you troubleshoot
problems quickly. The main pipeline landing page is now called the Overview tab.
l The Tests tab now includes a Filter pane, to quickly focus on the tests that are most relevant to
you.
l In the Builds and Tests tabs, you can navigate between runs using the Run selector in the
upper right corner. Note that the Overview tab always shows the latest run.
l The Run pipeline button has been replaced with a menu command. To run a pipeline manually,
open the Pipelines module and select a pipeline in the left pane. From the pipeline's menu
options, select Run.
l The Failure analysis widgets were removed. Instead, this information is displayed in the

context of the Builds and Tests tabs.

l The Not Me button is available in the upper right corner of the Builds and Tests tabs on the
main Pipeline landing page. The button has been removed from the Pipeline run form.
GDPR: Conditions For Consent

ALM Octane can display customized terms indicating how personal data will be processed. The
user can consent or log out. If the user consents, the date and time at which the consent was
given is recorded and can be accessed using the ALM Octane UI or REST API.
Administration
The following administration and customization enhancements are provided:
Area Enhancement
Delete workspaces Space admins can now delete workspaces from the UI (Settings >
Spaces) and using the REST API.
Assign space admins Site admins can now view and assign space admins from the Site
module in the new Administrators column in the Spaces tab.
Easy navigation Easily navigate from Site > Spaces to the space settings by clicking the
Go to Space button.
Available for site admins who are also the space admin for the selected
space.
New mail format with The new email style supports customized headers and footers.
customized headers
and footers

Synchronization
When synchronizing with JIRA, you can now map multiple JIRA projects to a single ALM Octane
workspace. For details, see "Prepare for JIRA synchronization" on page 355.
LDAP (on-premises)
The following LDAP enhancements have been introduced:
Matching LDAP users to existing ALM Octane users

When importing LDAP users, ALM Octane matches the LDAP users to existing internal ALM
Octane users.
This means that all ALM Octane entities and actions associated with the original internal ALM
Octane users are kept. For example, backlog items owned by the users remain theirs, and history is
retained.
Wildcards
When filtering the list of users to include, you can now use the asterisk (*) as a wildcard that
represents any number of characters.
REST API
For a list of REST API changes, see the list of what's changed in the Developer Help.
What's new in 12.55.32 (SaaS)

What's new video

Watch the What's new video:

User management
The following user management enhancements have been introduced:
Custom roles
l Space admins can create new roles and customize their permissions.
l Permissions can be granted per module and per entity for create, update, and delete
operations, in addition to actions such as creating attachments and adding comments.
l Permissions can be granted for general system actions, such as sending emails and sharing
favorites
l Control which modules are visible to which custom role.
l Space admins can view the permissions granted to the default roles.
Coming soon: The ability to customize default roles will be provided in an upcoming
release.
User deletion
For SaaS, you can now request to delete users by opening a support ticket.
Administration
The following enhancements have been made in the administration area:

Rules
The Validate rule action has been renamed Alert User. Existing Validate rules are renamed
automatically during upgrade.
Shared customization (technical preview)

Working with shared entities is supported using the REST API and OData. This helps facilitate
cross-workspace reporting for shared spaces.
Shared entities include releases, user-defined fields, rules, and more.
For details, see the following in the Developer Help:
l The list of what's changed in the ALM Octane REST API.
l The information about the ALM Octane model.
Usability
Enhancement Description
Format text in Style text in manual tests using markdown. Display text in bold, italics,
test script underline, or colors.
Improved Browse through multiple attachments easily. For details, see .

attachments
interface
Search Search for an item using its URL. For details, see .
Filter out Done Work items that are Done are no longer displayed in selection lists. For
items example, when selecting backlog coverage for a test, Done items are not
displayed.
To display a Done item in a selection list, search for it using its ID.
Follow multiple Follow multiple items with one click. For details, see .
items
Gherkin tests Add scenario outlines in Gherkin tests with a click of a button. For details, see
.
Task default When you add a task to an existing user story, the task will be assigned, by
owner default, to the owner of the user story.

Testing
When analyzing results of StormRunner Functional tests, you can now drill down directly from the
Tests tab to the detailed StormRunner Functional report.

The following enhancements are now available in the Pipelines and CI areas:
Pipeline run analysis

l When you assign Who’s on it for a failed pipeline run, ALM Octane suggests the most relevant
people to handle the failure. This is based on their recent commits, areas of expertise, or
previous activity.
l For unstable tests, ALM Octane shows the last commit that included a change to the test file
before the test became unstable.

l For failed tests, ALM Octane shows related files to indicate files which were previously linked
to the test, by analyzing committers and "Who's on it" history.

For details, see "Expand your test failure analysis" on page 196.
Expanded pipeline support

l ALM Octane now supports the Jenkins Pipeline Multibranch plugin. When a new branch is
pushed to a source code repository and built for the first time, ALM Octane automatically
creates a corresponding pipeline. For details, see "Special pipeline types" on page 174.
l Enhanced support for Pipeline as a Code, with stages now displayed in the Topology tab.
These require version 5.4 or later of the HPE Application Automation Tools plugin, available here.
Integrations
You can now search for specific items when working in the ALM Octane plugin for Visual Studio.
GDPR-compliance enhancements (technical preview)

Examples are provided that demonstrate how to use the REST API to view the history of user
actions on entities in ALM Octane. This facilitates compliance with the GDPR "right to access"
article.
You can view the examples in this KB article.

REST API
What's new in 12.55.25 (SaaS)

What's new video

Watch the What's new video:
Usability
Board View
Both requirements and epics can now be managed using a board view.
Full-screen editing
Rich-text fields can now be edited in full-screen mode.
Dashboard grids
In the Dashboard, summary graphs can now be displayed in a grid format.

Test runs and reports

Improved user experience when running tests and viewing test reports.
We’ve placed the expected results and actual results of a test step side-by-side for better
readability.
l We made the actual results text box dynamic so it grows according to the text you enter.
Redundant fields removed

The following redundant fields were removed:
l Within Features, the following fields were removed because they were duplicates of other
fields: Defect Count, User Story Count, and Quality Stories. Instead, use the fields Defects, User
Stories, and the relevant quality story field (for example the number of defects under the
feature).
l Within Tests, the Requirements coverage field was removed because it is a duplicate of the
generic Backlog coverage field.

Note that if you used these fields as part of a business rule, the rule is no longer valid and will not
run. Instead, modify the rule to use the correct fields listed above.
Settings and configuration

The following configuration enhancements are now available:
Roles and permissions

A predefined Viewer role is now available. Assign it to users who need only viewing permissions.
Trigger webhook rules (formerly Call URL)

l The Call URL rule action has been renamed to Trigger webhook. Existing Call URL rules are
renamed automatically during upgrade.

l User-defined fields (UDFs) are now supported in the payload.

l A new tool is available for testing your Trigger webhook rule and the service you are
developing.

The following pipeline and CI server enhancements are available:
Support for new CI servers

The following CI servers are now supported. Click the links to download the ALM Octane plugins
for the CI servers.
l GoCD CI Server
l Bamboo CI Server 6
Pipeline run analysis

l The Analysis tab in a pipeline run now displays also test runs that did not fail.
UFT Integration
ALM Octane can now discover and run UFT tests stored in a Subversion (SVN) repository.
This requires version 5.3.5 or later of the Application Automation Tools plugin, currently available
as a beta version: https://mvnrepository.com/artifact/org.jenkins-ci.plugins/hp-application-
automation-tools-plugin.
Integrations
The ALM Octane plugin for Visual Studio now displays additional ALM Octane fields, not just the
name and description. You can select which fields you see, including comments.
REST API
Help Center search

The help center now includes advanced site search functionality:
l Intuitive friendly Google-like search
l Search across all ADM help centers
l Filter search results by selected products
l Get results from separate deliverables in one place, such as PDFs and APIs

ALM Octane lifecycle

The ALM Octane lifecycle can include the stages described below. ALM Octane is flexible, so you
can perform any stage at any point.
In this topic:
l "Manage the backlog and track release quality" below
l "Track build quality" on the next page
l "Incorporate test and build results into overall product quality" on the next page
l "Track product quality" on the next page
l "Analyze quality" on the next page
Manage the backlog and track release quality

Depending on your development methodology, you can create high-level requirements, or build a
detailed backlog tree with epics, features, and stories. Create tests to track release quality,
including functional, sanity, acceptance, security, and performance tests. You can also integrate
with a CI server to get results of automated tests. As you implement user stories, you can report
defects and monitor their progress.
When you run manual tests and CI server pipelines, results are automatically incorporated into the
dashboard. You can then use the dashboard to analyze release quality. For details, see "Backlog
management" on page 100.

Track build quality

To track build quality and collect automated test run results, integrate ALM Octane with a
CI server. When the pipelines run, ALM Octane collects test run results and SCM data. This
information can be used to analyze build, release, and product quality.
You can view CI server pipeline steps graphically, trigger pipeline runs, and label pipeline steps as
different types of jobs configured for different environments. The pipeline display lets you see the
status of builds and test runs that are included in the pipeline run, and to analyze failures. For
details, see "CI Pipelines" on page 159.
Incorporate test and build results into overall product

quality
After a release goes out, integrate the testing of individual new features into the testing of the
overall product. In the release backlog, assign features and defects to application modules, which
represent the functional parts of your product.
You can also incorporate manual and automated tests into the testing of the overall product, and
assign tests to application modules. For details, see "Assign items to application modules" on
page 150.
Track product quality

In ALM Octane, you group the functional areas of your product according to application modules.
To build an application module tree, create nodes for each area that is essential for testing the
overall quality of your product.
Connect tests to the application modules. When you run tests and CI server pipelines, results are
incorporated into the dashboard. You can then use the dashboard to analyze overall product
quality. For details, see "Quality management" on page 146.
Throughout your release lifecycle you continue to track release quality, build quality, and product
quality, as described above.
Analyze quality
You can analyze release progress and quality using the Overview tab, in both the Backlog and
Quality modules. You can also analyze product quality within and across releases using the ALM
Octane dashboard, which includes a wide range of useful charts and graphs. For details, see "Use
the ALM Octane Dashboard" on page 290.

Next steps:
l "ALM Octane modules" on page 52
l "Common flows" on page 65
ALM Octane with Agile and waterfall

ALM Octane can be used with whichever development methodology your teams use.
In this topic:
l "Agile development flow" below

l "Traditional waterfall development flow" on page 45
Agile development flow

If your team uses the Agile methodology, use ALM Octane to manage the development process.
Most Agile development processes follow a standard flow:

On a day-to-day basis, the process looks more like this:
This process repeats with continuous delivery of your application.
Plan
The first step in any Agile development involves planning. Because Agile focuses on continuous
delivery, clear planning is essential.
In ALM Octane, do the following in the Agile plan stage:
Create Before beginning work, it is important to define the workflow. This lets you
workflow specify and enforce:
l How backlog items proceed through the development cycle. This ensures that
all parties work with the same process.
l How an item moves to completion ("Done is Done").
Specify rules for completion of a phase, when an item is complete, and so on.
For details on setting workflow phases, see "Set up workflow phases and
transitions" on page 557. For details on using rules, see "Set up rules" on
page 568.

To commit to completing work, you need to know how much work a team or
individual can finish.
When you create a team, the workspace admin specifies:
l The expected velocity for the team. This number can be dynamic over time.
l The capacity per team member
For details on planning velocity and capacity, see "Balance release and sprint
workloads" on page 122.
Create and Before and throughout the development process, the product owner maintains
update the the product backlog. The Backlog is fluid and adjusts to changing priorities.
Backlog
In ALM Octane, you maintain the backlog in the Backlog module:
l Create epics that specify the large-scale part of your applications
l Create features for each deliverable part of the product
l Create backlog items for items to develop
l Organize items in a meaningful way
For details on using the Backlog, see "Backlog management" on page 100.
Rank the While maintaining the Backlog, the product manager ranks Backlog items.
Backlog Correct rank ensures that development teams select the highest priority items
when planning.
ALM Octane helps you rank the Backlog:
l Rank is displayed in Backlog lists or grids.
l Change the rank by dragging and dropping items within the list or grid.
l Manually enter the rank in the Rank column.
l For organizations using the WSJF methodology, use the WSJF fields to create
priorities based on WSJF criteria
For details on ranking, see "Rank the Backlog" on page 111. For details on WSJF
fields, see "Rank with WSJF attributes" on page 112.

Plan After you create the Backlog, plan each release and sprints.
releases
ALM Octane helps you assign Backlog items to releases, sprints, and teams:
and sprints
l Update the Release, Sprint, and Team fields in the Details tab of any item
l Drag the item from the list or grid into a release bucket:
For details on working with release and team assignments, see "Set up and
manage release plans" on page 118. For details on the release buckets, see
"Backlog planning buckets" on page 121.

Assign During the sprint planning meeting, assign work items to a user.
items to a
Assign items in ALM Octane:
person
l Update the Owner field in the Details tab of any item
l In the Team Backlog module, drag the item from the list or grid into a team
member bucket:
For details on managing a team's backlog, see "Manage the team backlog" on
page 128. For details on the team planning buckets, see "Team planning
buckets" on page 131.
Build
After you decide what to deliver, you must develop the assigned features and stories. In ALM
Octane you use this process:
Move As you work, it is important to update progress. This is especially true if you use
backlog daily scrum meetings where you discuss what was done and what to do next.
items
While working, update the phase of the backlog item:
through
the
workflow
Updating the item's phase ensures you have an accurate reflection of progress.
For details on workflow phases, see "Advance the phase of an item" on page 74.

Create When working on a backlog item, it is helpful to break down the item into
tasks manageable tasks. To do that, ALM Octane provides a task list and task board to
manage tasks:
l In the Tasks tab inside a backlog item
l From the Tasks tab of the Team Backlog module.
l Add tasks when you create a backlog item in the Add dialog
For details on managing tasks, see "Work on your stories" on page 132.
Track Track individual progress to make sure everyone is progressing according to plan:
task
l In the Epics or Features tab of the Backlog module, view the Progress column of
progress
the grid
l In the Team Backlog module, view the Team Progress graph or individual team
member bucket.
l In the Team Backlog module, set limits on the number of items in progress for a
phase (WIP limit) and on the number of days an item can be in a phase (cycle
time limit). Each phase in the Board View displays continuously updated
information on the number of items in progress and if any items are past their
cycle time limit.
l Create custom graphs in the Dashboard module.
l Later in the release, add the Release Forecast widget to the Dashboard to see
how ALM Octane predicts you will finish the planned Backlog items.
For details on tracking release progress, see "Analyze release progress" on
page 143. For details on the Dashboard, see "Use the ALM Octane Dashboard" on
page 290. For details on the Board View, see "Use the Board View" on page 135.
Track Check overall release progress for each team and its team members.
release
Add widgets to the Dashboard, such as the Stories Cumulative Flow graph, Burn
progress
Up and Burn Down widgets, Velocity Tracking, and so on
Test
To deliver high-quality features, you must test delivered content in parallel with development. In
ALM Octane there are multiple steps to build a test process:
Add tests to For each backlog item (including epics and features), add tests.
Backlog items
For details on adding tests, see "Create manual tests" on page 231 or "Create
Gherkin tests" on page 237.

Run tests Run tests in many ways:

l Manually run a test manually
l Schedule (plan) a test run or test suite run
l Add the tests as build steps in your CI server and run the tests as part of a
regular build process

For details, see "Run manual and Gherkin tests" on page 251 and "Run
automated tests from ALM Octane" on page 275.
Add and An important of testing is ensuring new features do not break existing
analyze build functionality.
processes on
To do this, add tests to your CI server builds. Then create a pipeline in ALM
CI/CD servers
Octane that represents the steps of the build. When the pipeline and build
run, view the details and results of the build jobs and tests.
The Pipelines module displays all details on the build processes:
l The build flow
l Success or failure of the build
l Connection of build activities and source code commits to existing items
For details, see "CI Pipelines" on page 159.
Analyze test After running a test, view the test results.

results
For manual and Gherkin tests or automated tests included in a pipeline,
ALM Octane displays the test results in the test run.
For tests run outside ALM Octane upload test results to ALM Octane. Once
the test results are available, view the results directly inside the ALM Octane
test.
For details, see "Stop the run and see results" on page 255, "Send automated
test run results to ALM Octane" on page 271, or "Analyze automated test run
results" on page 278.

Open defects If you find issues or errors in your application, open defects to resolve these
issues. This lets you use the errors and issues to improve the development
quality. Furthermore, add the defects to the Backlog to include the defect in
release planning.
Open defects from:
l The Backlog module
l The Defects module
l The test details, as part of the test run
For details on adding defects, see "Report and track product defects" on
page 154 or "Report defects during a run" on page 254.
View As you develop, check the application's quality. This information is displayed
application according to test results and defects.
quality
Use the ALM Octane widgets to view this information in:
l The Overview tab of the Backlog module
l The Overview tab of the Quality module
l The Dashboard
Analyze Analyze the quality of the current release. Filter the widgets in the Overview
release quality tab of the Backlog and Quality modules by release.
For details on configuring dashboard widgets, see "Use the ALM Octane
Dashboard" on page 290.
Release
After you decide you have completed all assigned backlog items, you are ready to release the
application to customers.
Use the feedback from these releases to inform future planning.
Hold a retrospective to present what was done and review the release or sprint. In the Team
Backlog module, use the Retrospective area to summarize the sprint or release and address
unfinished items.
For details on the retrospective area, see "Perform sprint closure and retrospective" on page 140.

Traditional waterfall development flow

If your team uses a traditional development methodology, such as waterfall, use ALM Octane to
manage the development process.
The traditional development process follows a structure like this:
1. Requirements: List the requirements of what the product needs to do. This may or may not
include a list of features.
2. Design: Define how the requirements work inside the product.
3. Implementation: Develop the product.
4. Testing/Verification: The quality assurance team tests and verifies the planned features.
Open defects for those problems encountered in testing.
5. Release/maintenance: Release the finished and approved product.
We recognize that not all traditional software development models follow such a linear
progression, However, these framework do keep a rigid separation between development phases.
ALM Octane helps you manage the development processes through each of these stages:
Requirements
In traditional software development, you define the requirements before beginning any work.
This lets you know exactly what your product needs to do for customers.
Also, you define the timeline and resources to see what it is possible to finish..
ALM Octane lets you do this planning before beginning work on the release.
Define the application requirements

When beginning development, you have a general idea of what the application should do. You
may know what tasks the application can perform, what things the user may want to do, and so
forth.
To help define requirements, use the Requirements module to describe the intended functionality.
For details, see "Requirement management" on page 94.
Build application modules

While adding requirements, create application modules. These application modules are functional
areas of the product. Application modules enable you to see application health and progress as

you proceed through development and testing.

Create and view application modules in the Quality module.
After you create the application module hierarchy, associate features, tests, and defects with each
application module.
For details on application modules, see "Quality management" on page 146.
Create releases, sprints, and timelines

Create the timelines for the product releases.
In ALM Octane, the space admin or workspace admin creates the timeline in the Settings area:
For details on defining releases and release timelines, see "Set up a release" on page 535.
Add teams and assign them to releases

You must also plan the workforce. In ALM Octane, the workspace admin adds teams, adds team
members, and assigns them to releases:
For details on creating and assigning teams, see "Manage teams" on page 540.

Design
Once you have planned requirements, releases, and teams, begin developing the application. This
involves creating the backlog of work items and assigning these work items.
Create First, create the product backlog to organize the development process.
the
In ALM Octane, you maintain the backlog in the Backlog module. Use the Backlog
Backlog
module to:
l Create epics that specify the large-scale areas
l Create features for each deliverable part of the product
l Create stories for each item to develop
l Organize epics, features, and backlog items in a meaningful way
For details on using the Backlog, see "Backlog management" on page 100

Plan After you create the Backlog, plan each release and sprints.
releases
ALM Octane helps you assign Backlog items to releases, sprints, and teams:
and
sprints l Update the Release, Sprint, and Team fields in the Details tab of any item
l Drag the item from the list or grid into a release bucket:
For details on working with the release and team assignments, see "Set up and
manage release plans" on page 118. For details on the release buckets, see "Backlog
planning buckets" on page 121.

Assign During the sprint planning meeting, assign work items to a user:
items to
l Update the Owner field in the Details tab of any item
a person
l In the Team Backlog module, drag the item from the list or grid into a team
member bucket:
For details on managing a team's backlog, see "Manage the team backlog" on
page 128. For details on the team planning buckets, see "Team planning buckets"
on page 131.
Implementation
After you decide what to deliver, you must develop the assigned features and stories. In ALM
Octane you use this process:
Move backlog While working, update the phase of the backlog item:
items through
the workflow
Updating the item's phase ensures you have an accurate reflection of

progress.
For details on workflow phases, see "Advance the phase of an item" on
page 74
Create tasks When working on a backlog item, it is helpful to break down the item into
manageable tasks. To do that, ALM Octane provides a task list and task
board to manage tasks:
l In the Tasks tab inside a backlog item
l From the Tasks tab of the Team Backlog module.
l Add tasks when you create a backlog item in the Add dialog
For details on managing tasks, see "Work on your stories" on page 132.

Track task Track individual progress to make sure everyone is progressing according
progress to plan:
l In the Epics or Features tab of the Backlog module, view the Progress
column of the grid
l In the Team Backlog module, view the Team Progress graph or
individual team member bucket.

l Create custom graphs in the Dashboard module.
For details on tracking release progress, see "Analyze release progress" on

page 143. For details on the Dashboard, see "Use the ALM Octane
Track release Check overall release progress for each team and its team members.
progress
Add widgets to the Dashboard, such as the Stories Cumulative Flow graph,
Burn Up and Burn Down widgets, and so on.
Later in the release, add the Release Forecast widget to the Dashboard to
see how ALM Octane predicts you will finish the planned Backlog items.
Testing and verification

To deliver high-quality features, you must test delivered content. In ALM Octane there are many
ways to ensure you perform adequate testing:
Add tests For each backlog item (including epics and features), add tests.
to Backlog
For details on adding tests, see "Create manual tests" on page 231 or "Create
items
Gherkin tests" on page 237.
Run tests Run tests in many ways:

l Manually run a test
l Schedule (plan) a test run or test suite run
l Add the tests as build steps in your CI server and run the tests as part of a
regular build process

For details on running tests, see "Run manual and Gherkin tests" on page 251 and
"Run automated tests from ALM Octane" on page 275.

Analyze After running a test, view the test results.

test results
For manual and Gherkin tests or automated tests included in a pipeline,
ALM Octane displays the test results in the test run.
For tests run outside ALM Octane upload test results to ALM Octane. Once the
test results are available, view the results directly inside the ALM Octane test.
For details, see "Stop the run and see results" on page 255, "Send automated test
run results to ALM Octane" on page 271, or "Analyze automated test run results"
on page 278.
Open If you find issues or errors in your application, open defects to resolve these
defects issues. This lets you use the errors and issues to improve the development quality.
Furthermore, add the defects to the Backlog to include the defect in release
planning.
Open defects from:
l The Backlog module
l The Defects module
l The test details, as part of the test run
For details on adding defects, see "Report and track product defects" on page 154
or "Report defects during a run" on page 254.
View As you develop, check the application's quality. This information is displayed
application according to test results and defects.
quality
Use the ALM Octane widgets to view this information in:
l The Overview tab of the Backlog module
l The Overview tab of the Quality module
l The Dashboard
Analyze Analyze the quality of the current release. Filter the widgets in the Overview tab
release of the Backlog and Quality modules by release.
quality
For details on configuring dashboard widgets, see "Use the ALM Octane
Release maintenance
After you decide you have completed all assigned backlog items, you are ready to release the
application to customers.
After a release, it is common to continue maintenance of released versions. To assist, ALM Octane
lets you:

ALM Octane modules
l Run tests against any version of your application

l Create a pipeline for previous versions which enable you to build and test fixes of that version.
For details on pipelines, see "CI Pipelines" on page 159
l Create dashboard widgets for past releases of the product to see the quality of that release.
See also:
l "Backlog management" on page 100
l "Quality management" on page 146
l "CI Pipelines" on page 159
l "Testing" on page 222
ALM Octane modules

ALM Octane is divided into modules, which enable you to perform the following:
Requirements Create requirement documents describing what you want to deliver at a high
level. You can link requirements to tests, providing you with coverage on each
requirement.
For details, see "Requirement management" on page 94.
Backlog The backlog is a list of the items you are handling during product
development. For each release you define the backlog, which includes epics,
features, user stories, quality stories, and defects and their tests.
For details, see "Backlog management" on page 100.
Team Manage the team backlog by assigning items to teams, designating specific
Backlog team members to perform the work, and tracking progress of the team.
For details, see "Manage the team backlog" on page 128.

ALM Octane editions
Quality Analyze and track the quality of the product with end-to-end testing, cross-
feature functionality testing, and regression tests.
For details, see "Quality management" on page 146.
Pipelines Track the status of builds and test runs included in pipeline runs, and analyze
build failures.
For details, see "CI Pipelines" on page 159.
My Work Quickly view the work assigned or related to you.

For details, see "Access your assigned work" on page 72.
Dashboard Use the ALM Octane charts and graphs to analyze quality in context.
For details, see "Use the ALM Octane Dashboard" on page 290.
Defects Report and fix defects when running manual tests or analyzing automated test
failures.
For details, see "Report and track product defects" on page 154.
ALM Octane editions

Your ALM Octane edition defines which activities you can perform in ALM Octane.
In this topic:
l "Editions overview" below
l "Trial license" on page 55
l "License management" on page 55
Editions overview
ALM Octane editions provide you with the following capabilities:

ALM Octane editions
Edition Description
Enterprise Allows you to scale ALM Octane to large groups with the benefits of cross-
workspace capabilities. These include:
l Shared customization (such as rules, user-defined fields, workflow, forms, and
lists)
l Shared entities (such as users, releases)
l Cross-workspace reporting on data from multiple workspaces using the same
widget.
For an overview of workspaces, isolated spaces, and shared spaces, see "Manage
spaces" on page 514.
Pro Provides you the same set of features as Enterprise Edition within isolated
workspaces. Shared space capabilities are not provided.
Team Lightweight ALM Octane version to enable DevOps teams to plan, track, build and
release applications using Agile and DevOps practices.
For details see "Team Edition" on page 56.
The following table describes the different editions in detail:
Module/Functionality Team Pro Enterprise
Dashboard
My Work
Backlog (epics and backlog management, cross-

release planning)
Team Backlog
Pipelines with build analytics

Basic Advanced Advanced
analytics analytics analytics
IDE plugins
ChatOps
Security integration - Fortify Suite

ALM Octane editions
Module/Functionality Team Pro Enterprise

Manual and Gherkin tests
Automated test execution (with UFT

integration) and test suites
Requirements
Quality module and Defects module
Synchronizer
Shared workspaces and cross-workspace

reporting
Trial license
When you first start using ALM Octane, you automatically receive a Trial license which gives you a
90-day trial for 100 users.
A trial can be Team Edition or Enterprise Edition. By default, your trial is Enterprise Edition, which
allows one shared space. If you want to start a trial with Team Edition, specify the Team trial type
during the installation process. For details, refer to the ALM Octane Installation Guide .
When starting a trial, keep the following in mind:
l If you create a shared space in an Enterprise Edition trial and then install a license for Pro
Edition, the sharing capabilities are no longer supported.
l If you start an Enterprise Edition trial, you may not install a license for Team Edition later. This
flow is not supported.
License management
SaaS: You can view license usage details in MyAccount.
On-premises: For details on how to manage on-premises licenses and how to allocate licenses
from ALM and Quality Center to ALM Octane, see "Manage licenses (on-premises)" on page 474.
See also:
l "Manage licenses (on-premises)" on page 474
l "Manage spaces" on page 514
l "Manage workspaces" on page 519

ALM Octane editions
Team Edition
Team Edition is a lightweight ALM Octane version which enables DevOps teams to plan, track,
build, and release applications using Agile and DevOps practices.
In this topic:
l "Team Edition overview" below
l "Working with Team Edition: End-to-end flow" on the next page
Team Edition overview

Team Edition provides you with the following basic ALM Octane capabilities:
My Work Quickly view the work assigned or related to you. For details, see "Access your
assigned work" on page 72.
Dashboard Use ALM Octane charts and graphs to analyze quality in context. For details,
see "Use the ALM Octane Dashboard" on page 290.
Team Manage the team backlog by assigning items to teams, designating specific
Backlog team members to perform the work, and tracking progress of the team. For
details, see "Manage the team backlog" on page 128.
Note: Team Edition does not include a separate Tests module.
Pipelines Track the status of builds and test runs included in pipeline runs, and analyze
with basic the results. For details, see "CI Pipelines" on page 159.
analysis
Note: Team Edition provides limited Pipelines module capabilities.
Before you begin with Team Edition, note the following:

l Team Edition cannot be mixed with other editions, and must be installed on a separate server.
On this server only Team Edition functionality is available.
l Team Edition supports the Named license model only.
l Team Edition has no restriction on the number of workspaces you can create. The number of
users is defined by your license capacity.

l Team Edition does not support creation of customized roles.
For a comparison of the different ALM Octane editions, see "ALM Octane editions" on page 53.

System requirements
Working with Team Edition: End-to-end flow

The following flow illustrates how different personas can take advantage of Team Edition
capabilities.
1. In ALM Octane settings, the Release Manager defines releases, milestones, sprints, and
teams.
2. In the Team Backlog module, the Product Owner defines features and priorities, and plans
the release content.
3. The Dev Team Lead now breaks the features into user stories, and assigns user stories to
team members, pushes, and sprints.
4. Each Team Member tracks their work using the My Work module. They break user stories
down to tasks, and use IDE plugins to integrate their development workflow with ALM
Octane.
5. Team Leads track progress using the board views and typical scrum workflows.
6. Testers track acceptance testing on each user story or feature, using manual tests and
Gherkin tests.
7. The DevOps Admin and Developers use the Pipeline module to track pipeline runs and
analyze pipeline failures.
8. At the end of a release, the Team Backlog module is used to conduct a comprehensive
retrospective.
See also:
l "ALM Octane editions" on page 53
l "Manage licenses (on-premises)" on page 474
System requirements
This topic provides the details about the necessary system requirements.
This topic includes:
l "Hardware" on the next page
l "Software" on page 59
l "Database and Elasticsearch" on page 60
l "Integrations" on page 60
l "Installation, setup, and synchronization" on page 61

System requirements
Hardware
Component Type Value
Screen resolutions Recommended 1920 x 1080
Screen resolutions between the
recommended and minimum values are Minimum 1024 x 768
also supported. supported
Production environments: 2 ALM Octane CPU: 4

server machines,
(Recommended values) RAM: 8 GB
minimum
Heap: Max 4 GB
Contact customer support for the most Disk space: At least 500 GB
up-to-date be benchmark (network storage
documentation. recommended)
1 database server CPU: 8

machine
RAM: 16 GB
3 Elasticsearch CPU: 4 and higher

server cluster
RAM: 8 GB
machines
1 load balancing component (load balancer or

reverse proxy) to enable cluster
Pre-production or test environments: 1 ALM Octane CPU: 4

server machine
(Recommended values) RAM: 8 GB
Contact customer support for the most Heap: Max 4 GB
up-to-date be benchmark
Disk space: 200 GB
documentation.
1 database server Can be an existing database
machine server.
CPU: 8
RAM: 16 GB
1 Elasticsearch CPU: 4 and higher

server machine
RAM: 8 GB

System requirements
Component Type Value

Virtual machines VMware or any virtual machine is supported,
provided it has dedicated resources.
Software
Component Type Version
Server Windows 2012, 2016

operating
system CentOS 6.5 or later
We strongly recommend 7.2 and later.
Suse 12 with SP1 or SP2
Red Hat Enterprise 6.5 or later

Linux (RHEL)
We strongly recommend 7.2 and later.
Browser Chrome Chrome: The two latest versions

(recommended)
. Chrome for business
Firefox Firefox: The two latest versions

(recommended)
ESR: 52
Internet Explorer 11
Apple Safari 10, 11
JDK Open/Oracle JDK 8

Java 8 only.
Make sure the latest security updates are installed on
the ALM Octane server at all times.

System requirements
Database and Elasticsearch

Database Oracle 12C Standard or Enterprise edition, with character set
AL32UTF8
SQL Server 2016, 2014 or 2012 SP3

Case-insensitive collations only.
Elasticsearch N/A 5.6.X
Integrations
CI Servers Jenkins 1.642.4 and later
TeamCity 9.1.6 and later
Bamboo 5.13 and later
Microsoft Team Foundation 2017, 2015

Server (TFS)
GoCD 17.9 or later
Automated Various testing tools are See the supported integrations:

testing supported.
https://plugins.jenkins.io/hp-application-
automation-tools-plugin
Performance Performance Center 12.55

testing
Manual Sprinter 14.03

testing

System requirements

IDE plugins IntelliJ IDEA 2016.02X
On the following operating systems:
l Windows 10, 8, 7 (Normal and Darcula
themes)
l MacOS 10.12
l Ubuntu 16.04
Eclipse Neon, Mars

On the following operating systems:
l Windows 10, 8, 7
l MacOS 10.12
Microsoft Visual Studio 2015 and 2017

All editions: Community, Professional, and
Enterprise
Installation, setup, and synchronization

Component Version
LDAP Server Active Directory, or any LDAP provider supporting the LDAP3
protocol
OPB Provided as part of the ALM Octane release. Compatible only with
the same ALM Octane version.
Synchronizer Provided as part of the ALM Octane release. Compatible only with
the same ALM Octane version.
JIRA synchronization JIRA 7.7, 7.6x, 7.5x
ALM/Quality Center ALM/Quality Center 12.55, 12.53, 12.50, 12.21, 12.01 patch 1
synchronization and later
ALM/Quality Center ALM/Quality Center 12.55, 12.53 (all patch levels), 12.21 patch 6
license sharing
Note that 12.53 versions require a hotfix.
Upgrade path Only from 12.53.20

Set your language
Set your language

ALM Octane lets you choose your preferred user interface (UI) language.
Supported languages are English, French, German, Japanese, Russian, Simplified Chinese, and
Spanish.
In this topic:
l "Change your own UI language" below

l "Set another ALM Octane user's UI language" below
l "Set the language for the ALM Octane site or a space" below
l "Known issues" on the next page
Change your own UI language

Specify your UI language. Your choice does not impact the UI language other users will see.
1. In the ALM Octane top banner, click your user avatar.
2. In the user details window, in the Language drop-down list, select the language to use.
3. Click Update to change the language.
The language change takes effect the next time you log into ALM Octane. If you do not want
to log out and log in again, click F5 or reload the browser window to change the language
immediately.
Set another ALM Octane user's UI language

Space and workspace admins can set the language for individual users in ALM Octane.
1. Click Settings and select Spaces.

2. Select the Users tab.
3. In the Users tab, click a user's ID.
4. In the Language drop-down list, select a UI language for the user.
The language change takes effect the next time the user logs into ALM Octane.
Set the language for the ALM Octane site or a space

Site admins and space admins can set the DEFAULT_LANGUAGE configuration parameter to
specify a default language for ALM Octane.
This parameter sets:

Populate your system with demo data
l The UI language for new users.

l The language for system-wide operations (such as emails sent from ALM Octane).
For details, see "DEFAULT_LANGUAGE" on page 485.
Known issues
l The following items are not translated: Demo data, Boolean value operators in certain fields,
and Response messages when performing an invalid entity operation with the REST API.
l If you are using an IME (Input Method Editor) keyboard, when you type @ or # in a memo field,
the IME assumes this is part of a text string and not an indication of a user or link. To add a user
or link, either switch to a non-IME keyboard to type the @ or # symbols, or insert a user or link
using the toolbar:

ALM Octane can automatically create a large set of demo data that you and your users can use for
experimentation, to help you get started with ALM Octane.
Tip: You can also use the GDPR Content Pack to import real-life demo data into ALM
Octane. The GDPR Content Pack contains the whole European Union General Data
Protection Regulation in 24 different languages. You can download it from the ADM
Marketplace at https://marketplace.microfocus.com/appdelivery/content/gdpr-content-
pack
To populate your system with demo data:

1. In Settings , click Spaces and select a workspace.
2. In the Demo Data tab, verify that you selected the correct workspace.
3. Confirm that you understand this action is irreversible and will significantly affect your
system.
4. Click the Populate button for the type of data you want to create.
The data that you can create is limited by your role in the workspace. Therefore, different
buttons are available based on your role.
When you are ready to use the system for your own data, create a new workspace and set it up
according to your needs.

Note: To prevent accidentally spoiling live workspaces, ALM Octane will not populate
demo data if the workspace already contains information.

Common flows
Here are some sample work flows that can help you learn how to set up ALM Octane and track
quality.

User help
Build your product backlog, assign content to releases and teams, and assign backlog items to
application modules.
Log defects and track the quality of your releases, builds, and the overall product.
In this topic:
• Basics 68
• Glossary of ALM Octane entities 69
• Access your assigned work 72
• Advance the phase of an item 74
• Attach files to items 75
• Attributes, tags, and environments 76
• Collaborate with an item's stakeholders 79
• Comment on items 80
• Date formats 81
• Duplicate an item 82
• Edit forms 83
• Receive notifications and emails 83
• Personalize your display 85
• Preview an item 87
• Relate items to other items 88
• Reporting in ALM Octane 91
• Search for information 92
• View an item's history 93
• When to use the Backlog and Quality modules 94
• Requirement management 94
• What are requirements? 95
• How are requirements related to backlog items? 95
• Working with requirements 96
• Author mode and Manage mode 96
• Define a requirement in Author mode 97
• Define a requirement in Manage mode 98
• Associate tags, releases, features, defects, and tests with a requirement 98
• Export requirements to Word and PDF formats 99
• Analyze requirements 100
• Backlog management 100
• What is the ALM Octane Backlog? 100
• The ALM Octane Backlog cycle 101
• Glossary of backlog entities 102
• Project management flow 106
• Build the product backlog 110
• Import backlog items 113
• Set up and manage release plans 118

• Balance release and sprint workloads 122

• Manage the team backlog 128
• Work on your stories 132
• Use the Board View 135
• Perform sprint closure and retrospective 140
• Create and run tests 142
• Analyze release progress 143
• Assign items to application modules 146
• Quality management 146
• How does ALM Octane measure quality? 146
• Working with application modules 147
• Work with application modules 148
• Create and run tests 154
• Report and track product defects 154
• Analyze application area quality 157
• CI Pipelines 159
• What are pipelines? 159
• How ALM Octane builds a pipeline's topology 161
• Displaying pipelines in ALM Octane 161
• DevOps CI server integration flow 162
• Create and configure pipelines 163
• Run pipelines 175
• View and analyze the pipeline overview 176
• Analyze builds 186
• Analyze tests 191
• Track changes committed to your Source Control Management system 199
• Track security vulnerabilities 212
• Track code coverage in pipeline runs 214
• Testing 222
• Manual testing flow 223
• Automated testing flow (pipelines) 226
• Create manual tests 231
• Create Gherkin tests 237
• Import manual tests and test suites 243
• Link manual and Gherkin tests to automated tests 248
• Create test suites 249
• Run manual and Gherkin tests 251
• Run and edit manual tests in Sprinter 256
• Plan and run test suites 257
• Use versions of test scripts 260
• Automate Gherkin tests 263
• Add automated tests 267
• Run automated tests from ALM Octane 275
• Analyze automated test run results 278
• Analysis and reporting 282
• Analyze release quality 282

Basics
• Transition from release to product quality 283

• Analyze product quality 285
• Analyze build quality using pipeline data 286
• Use-case scenario: Performing quality analysis 287
• Use the ALM Octane Dashboard 290
• What is the dashboard? 290
• Set up the dashboard 290
• Configure widget data settings 291
• Use dashboard widgets for analysis 293
Basics
This section provides introductory concepts and instructions for working in ALM Octane.
Topic Description
"Glossary of ALM Octane entities" on List of ALM Octane entities and their matching
the next page symbols.
"Access your assigned work" on Track and update your work with a personalized list of
page 72 work items.
"Advance the phase of an item" on As you develop items, update their phase with a click.
page 74
"Attach files to items" on page 75 Add attachments to entities to document the item on
which you are working.
"Attributes, tags, and environments" Use attributes, tags, and environments to apply
on page 76 identifiers to items.
"Collaborate with an item's Communicate with other users related to a backlog

stakeholders" on page 79 item or pipeline run failure.
"Comment on items" on page 80 Add comments to ALM Octane items for additional
discussion.
"Date formats" on page 81 ALM Octane’s date format depends on the language
or locale set in your browser.
"Duplicate an item" on page 82 Duplicate an existing item to save time when creating a
new one.
" Edit forms" on page 83 Select which fields are included in forms.

Basics
Topic Description
"Receive notifications and emails" on Follow items to receives updates on their progress.
page 83
"Personalize your display" on page 85 Filter, sort, and group items in each module, and save
your settings as favorite views.
"Preview an item" on page 87 Use the Preview pane to view basic details about an
item.
"Relate items to other items" on Relate items to each other to see how one item
page 88 impacts others.
"Reporting in ALM Octane" on Create reports to enable stakeholders to view and

page 91 analyze information.
"Search for information" on page 92 Search your ALM Octane workspace or grid.
"View an item's history" on page 93 View the history of ALM Octane items.
"When to use the Backlog and Quality Recommended best practice use of the Backlog and
modules" on page 94 Quality modules.
Glossary of ALM Octane entities

This topic lists ALM Octane entities and their matching symbols.
In this topic:
l "Backlog and requirement entities" below
l "Test entities" on the next page
l "Configuration entities" on page 72
Backlog and requirement entities

Requirement RF A folder grouping a number of requirements.
Folder
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.

Basics
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.
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.

Basics
Gherkin GT Gherkin tests are a type of manual test. They use the Gherkin syntax and
Test 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 AT Automated tests are edited and managed in external tools, such as UFT,
Test 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" on page 269.
Manual Test MR A manual run of a test.

Run
Gherkin GR An automated run of a Gherkin test.

Test Run
Test Suite SR A run of a test suite.

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

Test Run
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.

Basics
Build B A build is the result of a pipeline step run.

l A pipeline run consists of builds.
l 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.
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.
Access your assigned work

Track and update your assigned work with a personalized to-do list of work items in the My Work
module.
In this topic:
l "What does the My Work module include?" below

l "Manage your items" on the next page
l "Create a rule to assign items" on page 74
What does the My Work module include?

The My Work module displays any of the following:
Assigned User stories, defects, quality stories, or tasks in the New, In Progress, or In Testing
items metaphases.
To see items from other metaphases, have the workspace admin create a rule to
display the items included in these phases. For details, see "Set up rules" on
page 568.

Basics
Tests Tests in the New, In Design, Awaiting Revision metaphases or the Requires
update phase of a test awaiting automation.
Test runs Test runs with the Planned, In Progress, or Blocked status.
Mention Any comment that mentions your ALM Octane user name. View the mentions in
in the Comments tab.
comments
To receive an email each time you are mentioned in a comment, set the
appropriate option in the ALM Octane settings menu. For details, see "Receive
notifications and emails" on page 83.
Following Any item on which you set a Follow option. View the updated and followed
options in the Notifications tab.
For details on following items, see "Receive notifications and emails" on page 83.
Other Right-click an item in the Backlog module and select Add to My Work. ALM
user Octane displays this item in your My Work list and lets you edit it.
items
Manage your items
1. In the top banner, click My Work .
When an item is added to the My Work module, ALM Octane displays a notification . After
clicking on any item in the list, ALM Octane decreases the number by one.
2. Use the following to manage your work:
Action How to
Display item details Select an item. Then:
l Change an item's phase
l Update a user story, quality story, or defect
description
l Add comments
l Run a planned test run
Display your team members In the Select a member drop-down list, select the team
items (team leaders only) member to view. ALM Octane displays the My Work
items for that team member.
Go to item details Click the item's ID number or the item name.

Basics
Action How to
Dismiss an item After selecting an item, in the right pane click Dismiss.
ALM Octane removes the item from the list.
If you dismiss items from your list, they may be
reassigned again in your list depending on workspace
rules.
Create a rule to assign items

By default, ALM Octane displays items in the My Work page of the owner. It is also possible to
display an item in the My Work module of other users. To do this, your workspace admin creates a
rule to assign the item to these users.
To create a rule to assign items:

1. In Settings , select the Entities tab.
2. In the list of entities, select the entity for which you want to assign the rule.
3. In the entity details, select the Rules tab and click +.
4. In the Add Rule dialog, specify the rule details:
Action tab l Action: Select Assign to users

l Assign to: Select either Owner or Author
Condition tab l Field: Select Phase

l Operator: Select =
l Phase name (unlabeled): Select the phase from the list.
For full details on working with rules, see "Set up rules" on page 568.
Advance the phase of an item

ALM Octane uses phases to represent the current state of an item. As you develop items, advance
from phase to phase with a click of a button.
l To change the phase of an entity, open the details of the item whose phase you want to
change. Select the next phase by clicking the phase link in blue, or select a different phase using

Basics
the dropdown.
l To change the phase of a requirement or feature without accessing its details, select the entity
in the tree. In the upper right corner, select a different phase using the dropdown.
The phase is changed when you navigate to another entity, or when you click the Save button in
the details tab.
Note: Each entity has its own workflow. For example, a defect's phases include New >
Opened > Fixed > Proposed Closed > Closed > Obsolete.
For details on how the workspace administrator configures phases, see "Set up workflow
phases and transitions" on page 557.
Attach files to items

Add attachments to entities to better document the item on which you are working. This enables
others to see related information for this item as needed.
To attach a file:
1. Locate the item for which you want to add an attachment.
2. In the attachments tab, click Attach.
3. Select the files you want to attach.
ALM Octane supports the following file types:
jpg bmp png
word doc docx
msg pdf xml
xls xlsx ppt
pptx zip txt
wmv mp4 m4p

Basics
mkv vob log

wrf fbr jpeg
Customize the supported file types by modifying the ATTACHMENTS_FILE_EXTENSION_
WHITE_LIST configuration parameter. For details, see "Set configuration parameters
(technical preview)" on page 479.
4. Click Open.
After you add attachments to an item, you can view them by clicking the Attach button.
In the Grid or Smart List View, ALM Octane displays a paper clip icon indicating the attachment:
When working with attachments, the site admin can also:

l Limit the number of attachments per entity. For details, see the MAX_ATTACHMENT_COUNT_
PER_ENTITY configuration parameter under "MAX_ATTACHMENT_COUNT_PER_ENTITY"
on page 496.
l Limit the size of attachments and other files, at the site level. For details, see the STORAGE_
MAX_FILE_SIZE configuration parameter under "STORAGE_MAX_FILE_SIZE" on page 500.
Attributes, tags, and environments

Attributes, tags, and environments enable you to apply identifiers to items. ALM Octane displays
the identifiers in the Tags tab of each module.
In this topic:
l "Attributes " on the next page
l "Tags" on the next page
l "Environments" on page 78

Basics
Attributes
Attributes are characteristics of a particular item. The attributes are the ALM Octane system fields
available for each item type.
Example:
Attributes Possible values
Phase New, Opened, Awaiting Review, Ready...
Item type Pre-Release, Business...
Test type Regression, End to End ...
Severity Low, Medium, Urgent...
Testing tool Manual, Selenium, UFT, LeanFT, StormRunner Load,

StormRunner Functional, LoadRunner ...
Run status Native statuses for test runs, such as Skipped, Passed,
Failed...
Tags
Tags are user-defined identifiers.
You do not specify a value for a tag. Instead, use tags like a label or a flag on an item.
Example:
l Create a tag called FutureCandidate. Any user story or defect you are likely to postpone
receives a FutureCandidate tag.
l Create a tag called HighRisk. Any user story that can impact many features receives a
HighRisk tag.
To apply a tag to an item

Click Add tag in the item's Details tab. You can then search for and select an existing tag, or type
the name of a new tag to add to the list.
ALM Octane deletes unused tags from the system after a while.

Basics
To filter a list of items based on a tag

Click Add tag in the Tags pane. Search for and select an existing tag. For more details, see Use
filters.
Environments
Environments are identifiers applied to test runs or to pipeline steps that run tests. These
identifiers are grouped into categories and describe the environment on which the test ran.
ALM Octane provides a list of environments that you can use out-of-the-box.
Example:
Environment Examples
Browser IE, Firefox, Chrome
OS Android, iOS, Linux, Win7
DB IBM DB2, Oracle, MSSQL
Distribution Debian, Fedora, RedHat
To apply an environment to a test run

Apply environment details for a test run before it runs.
In the Environment field of a pipeline step or a test suite run you are planning, search for and
select an existing value, or enter a new environment to add to the list.
For details, see "Configure steps: Define test and test run information" on page 171, and "Run a
test suite" on page 258.
To manage the list of environments

Click Settings > Environment list.
Add categories + or environments , rename or delete them.

Items are added or deleted as soon as you confirm the operation. Name changes are saved only
when you click OK in the Manage Environment List dialog box.
If you delete an environment that was applied to existing items, the environment is marked
Inactive. You cannot apply it to any additional items but it remains on the existing ones. To

Basics
reactivate an environment, click the Inactive icon .

Once Inactive items are no longer applied to any items, ALM Octane deletes them from the
system.
Example: These are some environments you might want to add:
Environment Examples
Test objectives Beta testing, stress testing, security testing
Deployment environment QA, staging, production
Browser version 9.0, 5.0, 10.00
Operating system version 7.0, 10.00
Packaging / distribution type On-premises, SaaS, OEM
Next steps:
l Filter items
Collaborate with an item's stakeholders

When working on a backlog item or a pipeline run failure, whether investigating, testing, or
opening a defect about it, you may want to communicate with other users related to this item.
You can discuss new or known issues, find out whether someone is handling the issue, prompt an
investigation, or discuss changing the priority of an item.
Email. You can send emails directly from an ALM Octane entity to other users. The email contains
information about the entity as well as a link to the entity in ALM Octane.
Comment. If you mention someone in a comment they receive a notification about it and can
respond. For details, see "Receive notifications and emails" on page 83.
Chat. If your administrator Set up Slack integration for your workspace, the Chat w/ Slack button
is enabled for backlog items and pipeline run failures. For details, see "Set up Slack" on page 430.
Click Chat w/ Slack to create a Slack channel for an item or open an existing channel. The first time
you click this button, Slack requests authentication. This is not required for subsequent Slack
chats.
l In a backlog item, click Chat w/ Slack in the Details tab. ALM Octane opens a Slack channel with
this item's author and owner.

Basics
l In a pipeline run's Builds or Tests tab, click Chat w/ Slack . ALM Octane opens a Slack channel
with all the users whose commits were included in the pipeline run.
If the administrator approved publishing ALM Octane data on Slack channels, ALM Octane sends
information from the backlog item to the channel.
Comment on items
Add comments to any ALM Octane item for additional discussion.
To comment on items:
1. In the item, in the upper right-hand corner of the ALM Octane window, click .
2. Enter and format the comment.
Tip: Add an Emoji to a comment. Type a colon (:) to display a list of available Emojis.
3. If you want to tag another user in a comment, do one of the following:

Basics
l Type "@" and an alphabetical character
l From the Insert Image drop-down , click the Add Participant to Conversation icon
and start typing.
ALM Octane displays the list of users:
Select a user from the list. ALM Octane inserts a connection to the ALM Octane user name.
ALM Octane includes the comment in the Comments tab of the My Work module. The user
receives an alert in the ALM Octane title bar. For details, see "Access your assigned work" on
page 72.
4. Click Add.
You cannot delete comments from other users. Click X in the upper right corner of the selected
comment to delete your own comments.
Date formats
ALM Octane’s date format depends on the language or locale set in your browser.

Basics
If the date format is not what you expect, check your browser's language or locale settings.
Duplicate an item
You can duplicate the following entities to save time when creating a new item: user story, quality
story, requirement, defect, manual test, and Gherkin test. For example, duplicating is useful if you
have a defect that needs to be fixed in multiple releases or versions.
In this topic:
l "How to duplicate items" below

l "Duplicating requirements" below
How to duplicate items

l Right-click an entity and select Duplicate. The new entity appears at the top of the grid.
l Click Duplicate in an entity's Details tab. You will automatically navigate to the details of
the new entity.
The new entity is named Copy of <original entity name>. Its phase is New, and its creator is the
user who duplicated the original entity.
The following table describes which elements are copied to the new entity and which are not:
What is l Common fields - this varies depending on the entity type. Note that user-
copied? defined-fields (UDFs) are always copied.
l Attachments
l Tasks
What is l Comments
not l History
copied?
l Test runs and old versions
Tip: You can also duplicate a defect by copying it to a different workspace. For details, see
"Report and track product defects" on page 154.
Duplicating requirements
When you duplicate a requirement, the new requirement becomes a sibling of the original, and
does not contain its descendant requirements.
Only requirement document entities can be duplicated, you cannot duplicate a requirement folder.

Basics
Next steps:
l "Basics" on page 68
l "Report and track product defects" on page 154
l "Requirement management" on page 94
Edit forms
You can select which fields are included in forms.
For example, suppose you want the Owner field visible when you create new user stories, even
though it is not shown by default. You can customize the user story form so this field is always
included. Similarly, you can choose to hide fields that are not relevant to your work.
To edit a form:
1. Create or edit an entity such as a defect, user story, or test.
2. In the form, click the Customize fields button located in the top right corner.
3. Use the checkboxes to add or remove fields from the form. If you change the default fields,
the Customize fields button shows an orange indicator .
4. To restore the default fields, click and then click Reset.

Note:
l Within a form, any fields you have added are shown under the More heading.
l You can customize separate forms for creating new items and for editing items.
l Your customizations are applied each time you open the same form again.
l The customizations are specific to you, and do not affect other users.
For details on how administrators define the default form settings, see "Design forms" on
page 543.
Receive notifications and emails

Receive notifications for items that you are following and whenever you are mentioned in a
comment.
Follow an item
Follow items to receive notifications whenever the item is updated. You can follow a specific item
or multiple items.
These are the items that you can follow:

Basics
l Features
l Backlog items
l tasks
l Tests
l Requirements
To follow a specific item:

1. Open an item to view its details.
2. In the toolbar, click the Follow button.
3. To make your notification selections the default for all followed items, click Save as default.
To follow multiple items:

1. Click the tab for the item type that you want to multi-select.
For example, click Backlog Items under a feature.
2. If there is more than one item, select the checkbox on the right side of the items that you
want to follow.
3. Right-click on the screen to display the context menu, and then click Follow.
Configure notifications
You can configure which changes you get notified on.
To configure notifications:
1. "Follow an item" on the previous page.
2. Click the Follow button for that item, and select the notification options.
Get notified about comments

Users who are mentioned in comments can be notified by email. The comment is also added to the
Comments tab in the My Work area. For more details, see "Comment on items" on page 80.
To receive emails when you are mentioned in comments:

1. In the ALM Octane top banner, click the Settings button .
2. In the dropdown, select Email me when I am mentioned in a comment.
See also:
l "Comment on items" on page 80

Basics
Personalize your display

Filter, sort, and group items in each module, and save your settings as favorite views.
Filter
Filter the items you want displayed in the module.
Filter type Description

Release/ In the Backlog and Team Backlog modules: Select the release and sprint context.
Sprint
context
Filter bar
Click to open the filter pane.
Select a field, and define a filter condition based on values of that field. Add
more fields to the filter condition, using the AND or OR operator.
Cross-filters: Some fields allow you to define cross-filters. For example: in
addition to filtering items by Phase, you can filter items whose phase was
changed before a specified date.
Fields that support cross-filtering include this button .

Filtering is not possible on memo fields or long string fields.
Show In the Backlog and Quality modules:

descendants
l Show only direct descendants. Displays only children of the selected node in
the Backlog or Application Modules tree.

l Show all descendants. Displays all descendants of the selected node.
Tags In the Tags pane on the right, select tags to filter by. Tags include custom tags
defined for your project. The tags pane also lists field values from a number of
system fields, such as Team, Phase, Severity.
Tip: Right-click a tag or field value to exclude it from the filter.
Select grid columns
In grid views, click and select which columns you want to display in the grid.
Drag the columns to any position you like.

Basics
Sort
To sort by displayed columns:

1. In Grid View, click a column header to sort the items by that field's values.
2. Click again to reverse the sort order.
3. Shift-click another field to sub-sort by that field.
To sort by any field:

l In Grid View and Smart List View, click the Sort toolbar button and select a field to sort by.
l Select up to three fields to sort and sub-sort by.
l Click the direction icon in each selected field to reverse the sort order.
Note: Sorting is not possible on memo fields, long string fields, or multi-select fields.
Group
Click and select a field to group by. Select up to three fields to group and sub-group by.
If you sorted your view, items within each group are sorted accordingly.
Grouping is possible on:
l System fields of type String, List , Release, Team, and User.
l User-defined fields of type List , Release, Team, and User.
Grouping is possible on multi-select fields.
Favorites
Save a module's display settings as a favorite view. The favorite saves these settings: filter,
selected columns, sort order, and grouping.
Each module has its own set of favorites. You can share favorite settings with all users, or with
selected teams.
Note: Users with the pre-defined Viewer role cannot share favorites.
In the top banner, open the Favorites menu .

After you save or load an existing favorite, if you change your display settings, the favorite icon
changes to .

Basics
In the Favorites menu, select Update Favorite to re-save the favorite with the current settings.
Preview an item
When working in ALM Octane modules, use the Preview pane to view basic details about an item:
From the preview:

l Edit the item's description
l Tag an item
l Change the phase of the selected item
l Add comments

Basics
To preview an item:
1. Select an item in the grid.
2. In the right pane, select the Preview tab.
Preview is also available when selecting items inside another item, such as adding tests to a test
suite or defects to a test.
Relate items to other items

Relate items to each other for coverage and to see how one item impacts others. The Relations
tab of any ALM Octane item displays a graphical representation these relations.
ALM Octane creates some relations automatically, such as the links between a test and its runs.
In this topic:
l "Relate items" below

l "Examples" on the next page
l "Types of relations" on the next page
Relate items
1. In any ALM Octane item, click the Relations tab.
ALM Octane displays a graphical representation of all items linked to the current item.
If several items of the same type are related to the current item, ALM Octane groups these
items:
2. In the toolbar, click Add Relation and select the type of item to which you want to link.
3. Select the items from the displayed list, and click Select.

Basics
Examples
Tests l In the Backlog module, relate a test to a user story or a feature for tracking
coverage.
l Report defects while running a test. If you create the defects while using the
Manual Runner, defects are related to the test.
l View the relationship between a test and test suites to which it is linked.
Test l Relate a user story or feature to a test suite.

Suites l View relationships between a test suite and other items. To view a list of related
tests, go to the Tests tab.
Runs l Relate defects to a run, even if you didn't report them during the run.
l When you run a test, its corresponding test run is related to the test.
Defects l In the Quality module, relate a defect to an automated test.

l Relate defects to each other.
Types of relations
Inside ALM Octane, each type of item has specific relations to other item:
Entity Relation Descriptions

Requirements l Requirement (Trace to). A requirement created as a result of this
requirement.
l Requirement (Trace From). A requirement that necessitated the opening
of this feature.
l Linked feature: A feature linked to this requirement.
l Linked defect. A defect related to this requirement.
l Linked manual test: A manual test included in the requirement's tests.
l Linked test suite: A test suite included in the requirement's tests.
l Linked Gherkin test: A Gherkin test included in the requirement's test.
l Linked automated test: An automated test included in the requirement's
tests.
Epic l Epic (Trace to): An epic created as a result of this epic.

l Epic (Trace from): An epic that necessitated the opening of this epic.

Basics
Feature l Covering Manual Test/Gherkin Test: A test covering the functionality of

this feature.
l Covering Automated Test: An automated test that tests the functionality
of this feature.
l Covering Test Suite: A test suite that tests the functionality of this feature.
l Feature (Trace to): A feature created as a result of this feature.
l Original Feature (Trace from): A feature that necessitated the opening of
this feature.
l Covering requirement: The requirement associated with this feature.
User l Linked Defect: A defect related to this user story.

story/quality l Covering Manual Test/Gherkin Test: A test that tests the functionality of
story this user story.
l Covering Automated Test: An automated test that tests the functionality
of this user story.
l Covering Test Suite: A test suite that tests the functionality of this user
story.
l User Story (Trace to): A user story created as a result of this user story.
l User Story (Trace from): a user story that necessitated the opening of this
user story.
Defects l Linked User Story: A user story affected by this defect.

l Linked Manual Run: A manual test run during which someone reported
this defect.
l Linked Automated Run: An automated test run during which someone
reported this defect.
l Linked Gherkin Auto Run: an automated Gherkin run during which
someone reported this defect.
l Linked Suite Run: A suite run during which someone reported this defect.
l Defect (Trace to): A defect created as a result of this defect.
l Defect (Trace from): A defect that necessitated the opening of this defect.
l Linked requirement: A requirement to which the defect is attached.
Manual Tests l Covered user story: A user story that this test (suite) covers.
Gherkin Tests l Covered feature: A feature that this test (suite) covers.
Test Suites
l Covering automated test: An automated test connected with this test that
has the same general steps as the test.
l Covered requirement: The requirement associated with this test.

Basics
Manual run Linked defect: A defect discovered during this manual run.
Automated
run
Automated l Covered user story: A user story that this automated test covers.
test l Covered feature: a feature that this automated test covers.
l Covering automated test: An automated test connected with this test that
has the same general steps as the test.
l Covered requirement: The requirement associated with this test.
Linked defect: A defect created during this run.

Manual run
Suite run
Automated
run
Reporting in ALM Octane

As you work, you may want to prepare reports using ALM Octane data. These reports enable
different people to view relevant information and perform analysis.
In this topic:
l "Create dashboard views" below

l "Export information to Excel" below
l "Get items using the REST API" on the next page
Create dashboard views

In the ALM Octane dashboard you add widgets to perform release and product quality analysis.
Configure the necessary graphs and layout. Then, save the configuration as a private or public
favorite.
For details on using the Dashboard, see "Use the ALM Octane Dashboard" on page 290. For
details on using favorites, see Save filters in your favorites.
Export information to Excel

You can export items and test run steps to Excel.
Export items
1. In the relevant ALM Octane module, create filters to display the relevant items. For details on
filtering, see Filter items.

Basics
2. In the toolbar, click the Export to Excel button .

For summary Dashboard graphs, click the menu button and select Export report to view the
items highlighted in the graph.
Export test runs

Export manual and Gherkin test run steps to an Excel. You can export up to 20 test runs. Each run
displays in a separate tab in the file.
Note: You cannot import test runs back into ALM Octane.
1. Open the Tests tab from the Quality, Backlog, or Team Backlog modules.
2. Select the tests that you want to export, and then click the Export test steps to Excel
button.
Get items using the REST API

Use the ALM Octane REST API to retrieve information about Backlog items, tests, and test suites.
ALM Octane sends the data on these items to your API client and you extract this data as
necessary using your tool.
For details, see the Developer Help in the Help Center.
Search for information

You can search for an item globally or in the context of a grid or a tree.
In this topic:
l "Use the project global search" below

l "Search in context of a grid or tree" on the next page
Use the project global search

Use the global search to search across all areas of your current ALM Octane workspace.
To perform a global search:

1. Click the search button in the ALM Octane toolbar.
2. Do one of the following:

Basics
l Enter a string. You can click the menu button to limit your search to a specific module.
l Enter the URL of a specific item.
Tip: Use this option to open a specific item for which you received a notification by
email. Copy/paste the URL into the Search bar instead of clicking it from within the
email to avoid opening multiple ALM Octane tabs.
Search in context of a grid or tree

If you want to search within a grid or tree (Application Modules or Requirements), use the Search
in context capability.
Search in context is available from the grid toolbar or the tree toolbar.
For example:
To perform a context search:

In the grid toolbar or above the tree, in the Search in context or Search in field, enter the string.
The grid or tree displays items matching the string.
Search in context is not available when the grid is grouped.
View an item's history

View history for many ALM Octane items.
In an item, click the History tab to see:
Date Date of each set of changes. The newest changes are at the top.

Requirement management
User The name of the user that made the changes.

l If an API made the changes, the authenticated user who made the change.
l If a rule made the changes, the user that ran the rule.
l On-premises: If the site admin made the changes, @System User, which is the
default. (Your site may have renamed the site admin user.)
Set of Set of changes made at the same time.

changes
If changes were made to a rich-text field (for example to a description), click the
View changes link to see the exact text that was modified.
Note: SaaS: If the creation time in the History tab differs from the Creation time field in the
Details tab, this is because the Creation time field represents the actual creation time of
the entity inside ALM Octane. For example, if the item was created in ALM, and then
synchronized with ALM Octane a week later, the Creation time displays the original date,
one week earlier. History displays the date it was created in ALM Octane.
When to use the Backlog and Quality modules

Backlog module Quality module
Use Backlog to manage a specific release and Use Quality to analyze the quality of the
analyze its quality. product overall.
Use Backlog for testing new features in the Use Quality for testing end-to-end, cross-
content of a release. Once a release has been feature functionality of the product,
made available, tests can be associated with regression tests, and so on.
application modules and incorporated into the
overall testing for the product.
Dev-QA testers generally work with the QA testers generally work with the Quality
Backlog module to manage the quality of the module to manage the quality of the product.
release.
The Requirements module provides you with a central repository for documenting and tracking all
aspects of your project, from conception to delivery. This can include business goals, customer
requests, functional requirements, or any other requirements whose approval and progress you
want to track.
In this topic:

l "What are requirements?" below

l "How are requirements related to backlog items?" below
l "Working with requirements" on the next page
l "Author mode and Manage mode" on the next page
l "Define a requirement in Author mode" on page 97
l "Define a requirement in Manage mode" on page 98
l "Associate tags, releases, features, defects, and tests with a requirement" on page 98
l "Export requirements to Word and PDF formats" on page 99
What are requirements?

Requirements can be high-level descriptions or formal documentation for your release, depending
on your development methodology.
For example, you might have a requirement to send an astronaut to Mars and bring them back to
Earth, and your backlog will be comprised of a huge number of detailed features, user stories, and
tasks.
You can also use requirements to document business-oriented information rather than simply
defining deliverables. For example, within requirements you might enter business objectives,
executive briefs, risk factors, or market opportunities.
You can link requirements to tests and defects, providing you with coverage on each requirement.
If your team works with both requirements and backlog, the two can be linked to one another,
showing which backlog item implements which requirement.
How are requirements related to backlog items?

From a use-case perspective, the Backlog module is project-management oriented. Backlog items
are defined in a hierarchy of epics, features, and stories, and different backlog items are created
for different teams (for example back-end vs. client).
Requirements contain the overall story of what you want to deliver, rather than a hierarchy of
tasks. For example, you might define a requirement as "Multi-language support," and this could be
mapped to ten different items in the backlog.
This is also reflected in the personas using these modules; backlog items may be written by project
owners or PMOs, while requirements may be written by business analysts or PMs.
From the perspective of test coverage, you could work with both backlog and requirements in
parallel. Alternatively, you could choose one of these modules to reflect quality implementation,
and link your tests to that module.

Working with requirements

First you create a framework of high-level requirements. You then add additional child
requirements to break these into manageable parts and give team members a better
understanding of the specific objectives. Requirements can also be formed in traditional ways
such as goals, use cases, security effects, or performance changes.
You can associate each requirement with releases, tags, tests, defects, and features.
The Requirements tree (left pane) contains a hierarchy of folders and requirements.
Within the requirements tree you can drag and drop requirements as needed. ALM Octane
highlights locations for dropping the requirement in green or red, depending on whether you are
able to drop a requirement in that location. Top level requirements cannot be moved out of the
containing parent folder. Child requirements can be moved under a different parent requirement.
Author mode and Manage mode

The Requirements module lets you work in two modes: Author mode, and Manage mode. Both
modes show the same content, but use a different visualization with different functionality.
Author mode
Author mode enables you to define requirements in a document view. You define the full details
for the parent requirement, and add child requirements and their details in the same document. In
author mode you can use rich text capabilities, such as adding diagrams, tables, images, and links.
In Author mode each requirement is displayed in a single document that extends from the
highest-level requirement until the lowest-level child. Numbering inside the document indicates
the requirement hierarchy (1, 1.1, 2, and so on). The title of the document is the title of the
highest-level requirement.

Manage mode
Manage mode lets you create and work with requirements within a grid, similar to the Backlog
module. Each requirement is an item in the grid, and you can perform operations on one or more
requirements using the Preview pane on the right.
You create a container folder for a set of requirements, and then add additional child
requirements to the folder. In this grid view you can filter items and perform bulk operations.
In the Children tab you can also work with a Board View, similar to the Backlog module. The Board
View can help you manage the phases of your requirements.
For an overview, see "Use the Board View" on page 135.
Define a requirement in Author mode

Use Author mode to define detailed requirements in a rich-text document view.
1. Within the Requirements module, select Author in the title bar.
2. In the requirements tree, select a folder and click + to add a requirement. Create a folder if

needed.
3. Enter the requirement details in the Add Requirement dialog box. Within the description you
can use the text editor to format text and to add tables, images, and links.
When you finish defining your high-level requirement, you will see it as a document in the
right pane. Note that Author mode displays all the contents of a requirement as one
document, but each child and sibling requirement is managed within a separate box. As you
move your mouse between requirements, a dotted line is displayed showing which further
actions you can take.
4. To create a child requirement in the right pane, click Add Child below an existing
requirement. To add a sibling, click Add Sibling below an existing requirement.
For example, if you are in requirement 1 and you add a child, the new requirement will be
labeled 1.1. If you add a sibling, it will be labeled 2.
5. Click Save to save your changes. Alternatively, when you leave a requirement your changes
are saved automatically.
Define a requirement in Manage mode

Use Manage mode to define a requirement in a grid view, and then perform operations using the
Preview pane.
1. Within the Requirements module, select Manage in the title bar.
2. In the requirements tree, select a folder and click + to add a requirement. Create a folder if
needed.
Alternatively, select the Children tab and click + Requirement.
3. Enter the requirement details in the Add Requirement dialog box. Within the description you
can use the text editor to format text, and add images or links.
4. Select a requirement in the tree. The right pane lets you do the following:
l Details tab. View a requirement's details and assign it to a release.
l Children tab. View a requirement's children, add a child requirement, and perform
operations on requirements using the Preview pane.

l Tests tab. Assign a manual test, Gherkin test, or test suite to a requirement, and track
progress using the Preview pane.

l Defects tab. Assign defects to a requirement and track progress.
Associate tags, releases, features, defects, and tests

with a requirement
You can associate requirements with different work items in several ways:
l From a test, in the Covered requirement field, select the associated requirements.
l In Author mode, you can select a requirement and assign tags using the Preview pane.

When viewing a requirement's details (in either mode) you can assign tags and releases in the
Details tab. In the Relations tab you can associate a requirement with a feature, defect, or test.
Export requirements to Word and PDF formats

You can export requirements to Word or PDF files to help you document them for legal purposes,
or share them within your organization.
Supported versions: Acrobat version 11.0.23 and higher.
In Author mode, select and click Export to Word or Export to PDF in the toolbar. ALM
Octane creates a Word file or PDF using the hierarchy of the selected requirement.
Limitations:
l East Asian languages are not supported when exporting from a Linux server.
l The styling in ALM Octane does not automatically generate identical styling in Word or PDF. If
you want to generate output with particular fonts and sizes, select the relevant region in ALM
Octane and apply a specific font and size to the text before exporting.
l When you export tables, Word and PDF use their default table style rather than the style in
ALM Octane.
l Very wide tables and images in ALM Octane are not always exported correctly. If tables and
images exceed A4 width, they are cut off when exported.

Backlog management
Analyze requirements
Create custom graphs to display requirement status and test run coverage according to
requirements.
You can create graphs only for a current status.
To create a requirements status graph:

Create a custom graph using Requirements as the Item type and group by Phase. For details, see
"Set up the dashboard" on page 290.
The requirements are displayed in alphabetical order.
To create a coverage graph:

Create a custom graph using Test runs as the Item type and Covered requirement as the X axis.
For details, see "Set up the dashboard" on page 290.
See also:
l Traditional software development flow
l "Backlog management" below
Backlog management
The Backlog and Team Backlog module help you manage product development, rank
development items, and plan development cycles.
In this topic:
l "What is the ALM Octane Backlog?" below

l "The ALM Octane Backlog cycle" on the next page
What is the ALM Octane Backlog?

The backlog is a list of items to handle during product development. In ALM Octane, you manage
the backlog in the Backlog module.
The Backlog module contains:
l The tree containing the hierarchy of epics and features, regardless of release.
l A grid with separate tabs for Epics, Features, Backlog Items, and tests. The items displayed in

Backlog management
the grid update based on the item selected in the tree and any filters:
The Backlog module lets you:

l Create epics and features, user stories, or quality stories
l Open defects for problems encountered during development, testing, or application
deployment
l Rank items and plan development cycles
l Add tests to epics, features, user and quality stories, or defects
l Track release and sprint development progress
The ALM Octane Backlog cycle

As you work in the Backlog in ALM Octane, follow these work phases:
Build the product Add epics, features, user stories, quality stories, defects, and tests.
backlog When you complete or update the list, rank items.
For details, see "Build the product backlog" on page 110.
Plan a release Assign features, user stories, quality stories, and defects to specific
releases. Then, assign them to a sprint and a team.
For details, see "Set up and manage release plans" on page 118.
Manage the team Select specific team members to perform the work. While the team
backlog works, track progress of the team.
For details, see "Manage the team backlog" on page 128.
Work on your stories Locate items assigned to you, add tasks, and update your progress.
For details, see "Work on your stories" on page 132

Backlog management
Create and run tests While working on your items, add tests to check that your development
works as expected.
For details, see "Create and run tests" on page 142.
Track progress View progress throughout the Backlog module.

For details, see "Analyze release progress" on page 143.
Assign items to Assign items to application modules to help assess application quality.
application modules
For details, see "Assign items to application modules" on page 146.
See also:
l "When to use the Backlog and Quality modules" on page 94
l "Glossary of backlog entities" below
l "Build the product backlog" on page 110
Glossary of backlog entities

You use many types of items in the Backlog module.
In this topic:
l "Backlog root" below

l "Epics" below
l "Features" on the next page
l "Backlog Items" on the next page
l "User stories and quality stories" on the next page
l "Defects" on page 104
l "Tasks" on page 105
l "Tests" on page 105
Backlog root
The backlog root is the highest-level point of the backlog. It is not associated with a specific epic
or feature, but serves as the container for all backlog items.
In the Backlog tree in the Backlog module, the root is the highest level in the hierarchy.
Epics
Epics are the product's high-level functional areas. These areas are top-level objectives of your
product development.

Backlog management
You define epics under the root of the backlog tree.
Example:
An online store workspace may list the following epics:
l Music Store
l Billing Module
l Security Compliance
Epics are release-agnostic.
Features
Features are a useable part of an application.
ALM Octane supports two types of features:
l Business features for customer facing changes.
l Architecture features for changes required in your system
Define features under an epic or under the root of the backlog tree.
Example:
The Music Store epic could include the following Business features:
l Album selection (in the Album database)
l Play a selected song (in the Song Playback section of the application)
l Purchase a song (in the Shopping section)
To support the Music Purchase feature, you might also develop a Secure Browsing
feature.
You can assign features to releases.
Backlog Items
Backlog Items is a collective term that includes User Stories, Quality Stories, and Defects.
User stories and quality stories

In features, add user stories and quality stories. These user stories are a specific functionality
(either customer-facing or internal).

Backlog management
l A user story describes a customer-facing functionality or an action a user performs.

l A quality story describes internal work for developers or testing engineers to do. These items
do not affect the product's customer-facing functionality.

User stories and quality stories are always associated with a feature, even if you do not assign one.
Note: You view user stories and quality stories in the Backlog Items tab of the Backlog
module.
However, user stories, defects, and quality stories are described collectively as Stories.
When you configure ALM Octane dashboard graphs to show data from Stories, the graph
includes details for user stories, quality stories, and defects.
Example:
The Album Database feature could include the following user stories:
l As a user, I can recommend a song to my friends
l As a user, I can rate an album I downloaded
l As a site admin, I can delete an album from the album database
Defects
Defects are the faults or bugs detected in the product.
View defects in the Backlog Items tab of the Backlog module. If you prefer to view defects
separately, use the Defects module.
Example:
The Album Database feature could include the following defects:
l When selecting a song to recommend, songs names are cut off
l The album rating stars are too close to each other
l When I delete an album from the album database, the artist is also deleted
Note: However, user stories, defects, and quality stories are described collectively as
Stories. When you configure ALM Octane dashboard graphs to show data from Stories,
the graph includes details for user stories, quality stories, and defects.

Backlog management
Tasks
It is possible to divide a user story, quality story, into tasks. Use tasks to describe the steps
necessary to complete the user story or defect.
View tasks in the Tasks tab of a user story or the Tasks tab of the Team Backlog module.
Example:
For the user story As a user, I can recommend a song to my friends, you could add
the following tasks:
l Design UI for recommendation
l Create code to query database with recommendation information
l Add component to installation
Tests
Add tests to all types of backlog items check their quality.
ALM Octane lets you add manual or automated tests to any backlog item. ALM Octane
aggregates test results to provide quality analysis of the associated backlog items.
View testsin the Tests tab of the Backlog module or the Tests tab of a selected item.
Example:
For the user story As a user, I can recommend a song to my friends, you could add
the following tests:
l Display success message when a user clicks on the Recommend link
l Recommendation is displayed in friends' lists
l Recommendation is displayed in my list of recommended items
See also:
l "Analyze release progress" on page 143

Backlog management
Project management flow

ALM Octane offers a project management solution that lets you plan, execute and track projects
throughout your development lifecycle:
In this topic:
l "Set up releases, teams, and workflows" below

l "Build your backlog" below
l "Plan your release" on the next page
l "Track progress" on page 108
l "Analyze and monitor your release quality" on page 110
Set up releases, teams, and workflows

Before you can begin preparing the framework for your development, the space admin or
workspace admin must create a number of things:
l Time frame: Create releases, sprints, and milestones.
l Workforce: Create teams, assign their members, assign teams to releases, and specify their
capacity per sprint.
l Workflow: Each type of item is assigned specific phases, and an order to follow when advancing
through those phases.
For details, see:
l "Assign roles and permissions" on page 529
l "Set up a release" on page 535
l "Manage teams" on page 540
l "Set up workflow phases and transitions" on page 557
Build your backlog

After your space and workspace have the proper releases, teams, users, and workflow configured,
you create the product backlog, prioritize it, assign backlog items, and track the development
process.
The backlog is made up of epics, features, and stories that describe the work required to complete
your project. In addition, you can add defects and tests to the backlog to enable you to manage all
project assets in one place.
In the Backlog module, you create your backlog in the hierarchy necessary for your organization:

Backlog management
l Define epics that describe the high-level areas of the application.

l Inside each epic, define features that describe a useable part of the application.
l Inside the features, define stories that contain the different things that need to be done to
complete a feature.
l Add defects per epic, feature, or story.
l Add tests per epic, feature or story to test these product areas.
After you create the backlog, rank the items to prioritize the backlog items. Prioritizing your
backlog can assist you in planning the order in which to implement them
Note: If you want to work on a single release or sprint, filter your view by release and
sprint. For details, see Filter items.
For details, see "Build the product backlog" on page 110.
Plan your release

Make a plan for implementing the backlog items that you defined for your project. First, decide
which features and user stories, quality stories, or defects you plan to implement in a release.
Then, assign each item to a specific sprint and team.
Take into account:
l The estimated effort for the backlog item

l The length of your release and its sprints
l The capacity of the teams assigned to the release
l The ranking order of your backlog
Use planning buckets in the Backlog module to set up your plan, and make sure you do not
exceed the available capacity.
1. Before a release begins, assign features and user stories to your release.
2. Assign features and user stories to specific teams, and assign user stories to sprints.
When you are ready to plan your work for a specific sprint, reevaluate the estimated effort you
assigned to each backlog item, and assign them to people in your teams.
1. Break your stories into tasks. Estimate the effort needed for each task, and assign them to
specific team members.
2. On a per-team and per-sprint basis, assign user stories to specific team members.
Note: The Team Backlog provides team member buckets to help you assign stories
and tasks and make sure not to exceed the teams' capacity.
3. Use the Task Board to update and follow your task phases.

Backlog management
To open the Task Board, select the Board view in the Tasks tab. The Tasks tab is available
inside stories, and in the Team Backlog module.
For details on these steps, see "Set up and manage release plans" on page 118, "Manage the team
backlog" on page 128, and "Work on your stories" on page 132.
Track progress
As items are designed and developed, advance the phase of the item.
As you work and advance through the development process, track the progress:
l Add the Phase column to your backlog grids.
l View the Progress column in epic and feature grids.
l Follow progress in the planning bucket widgets in the Backlog module and the Team Backlog
module

Backlog management
l Use chart and graph widgets in the backlog Overview tab.
Note: These widgets are context-sensitive and they display only data relevant to the
selected node.
l View widgets in the Dashboard module. Select from the predefined widgets offered by ALM

Backlog management
Octane, or create your own. Configure the widgets to filter the data according to your needs.
l Track your team's progress in the Team Backlog module.
For details, see:

l "Manage the team backlog" on page 128
l "Use the ALM Octane Dashboard" on page 290
Analyze and monitor your release quality

As your development progresses, you can run tests on the application you are developing, and
open defects to report any issues that need handling.
l Track the defect progress as part of your backlog.
l Assign tests to backlog items and analyze your release quality by following the status of the
test runs.
l Analyze the release quality with the latest test results.
For details, see "Use the ALM Octane Dashboard" on page 290.
Build the product backlog

The first step in the development process is building and prioritizing the product backlog. Use the
Backlog module to perform this work.
In this topic:
l "Create the Backlog" below

l "Fill in Backlog fields automatically" on the next page
l "Rank the Backlog" on the next page
l "Rank with WSJF attributes" on page 112
l "Update multiple backlog items" on page 113
Create the Backlog

Follow the procedure below to enter backlog items in ALM Octane's forms, or see "Import backlog
items" on page 113 to import your backlog from an Excel file.
To enter backlog items in ALM Octane:

1. Open the Backlog module, and select either the Epics, Features, or Backlog Items tab.
2. Add epics, features, and user stories, according to your specifications.
3. Customize the form with the fields that you want to have displayed.

Backlog management
4. Use the Autofill feature to populate all your new backlog items with predefined values. For
details see...
5. Optionally, create tasks for a user story in the Tasks to generate field.
Tip:
l You can create the backlog items in any order, and organize them hierarchically later.
l To change a backlog item's parent, either drag the item to a different node in the tree,
or edit the item's Feature or Epic field.
l To view user stories that are not associated with a feature, or features that are not
associated with an epic, select the root Backlog node, and open the User Stories or
Features grids.
l To associate a backlog item with a closed parent, find the feature or epic by its ID in the
dropdown list.
Fill in Backlog fields automatically

You can create autofill templates that help you fill in new items with predefined field values.
Example: In a data set for a user story, you can include a list of tasks in the Tasks to
generate field. Those tasks will be automatically created in every story that you create
using this data set.
To save an autofill template:

1. Fill in an Add <item> form with the field values that you want to repeat.
2. At the top of the form, click Save as template.
3. Choose a name for the template, and select whether you want to share the template with
other users.
To apply an autofill template:

While creating a new item, select the autofill template that you want to use. The fields are
automatically populated with the saved values.
Rank the Backlog

Backlog items in ALM Octane do not have a fixed rank number. Instead, in any given grid, items
are listed by order of their relative ranking, and numbers them from 1 to [no. of items in the grid].
New items are added to the backlog with the lowest rank.

Backlog management
To rank backlog items:

1. Click the Rank column header to sort the grid by rank.
2. Use these methods to change rankings:
l Drag one or more items up or down the Grid View or Smart List View.
l Click the rank number and type in a new value.
l Right-click an item and select Rank Highest or Rank Lowest.
Note: ALM Octane does not support ranking for grouped items.
After you set ranks, ALM Octane preserves the ranking even after you sort the grid by another
field. When you sort again by rank, ALM Octane restores the ranking.
Rank with WSJF attributes

The WSJF formula is a well-established method for determining epic and feature priorities. It uses
parameters and a calculated measurement to determine an WSJF score for an item.
In the feature or epic details, set the value of WSJF-specific fields:
WSJF fields
Business The item's value to customers or the business. For example, how the epic or feature
Value affects revenue.
Time The urgency to deliver the epic or feature.

Criticality
RR | OE The epic or feature's value in eliminating risks or creating new opportunities.

Calculated measurements
Cost of The difference between an epic or a feature being available now or later. The Cost
delay of Delay is the sum of the above components:
Cost of Delay = Business Value + Time Criticality + RR | OE
Job size The estimated length of time need to finish the epic or feature. You measure this
using your own unit (hours, story points, and so forth).
WSJF The ratio of the cost of delay and the job size. The higher the WSJF score, the
Score higher the priority of the epic or feature.
WSJF Score = Cost of Delay / Job Size OR
WSJF Score = (Business Value + Time Criticality + RR | OE)/Job Size

Backlog management
For the WSJF fields (Business Value, Time Criticality, and RR | OE), select a value from the list. For
the Job Size measurement, enter any integer value.
Update multiple backlog items

When working in the Backlog module, you may want to update a common attribute of many items.
To update multiple backlog items:

1. In the Grid View or Smart List View, select up to 200 items.
2. Right-click and select Bulk Update.
3. In the Bulk Update dialog box, select up to 5 fields
4. Click Update to apply the changes.
Some fields cannot be updated with Bulk Update, including user-defined fields.
Next steps:
l "Set up and manage release plans" on page 118
l "Create and run tests" on page 142
l "Assign items to application modules" on page 146
Import backlog items

Import user stories, quality stories, and defects into your ALM Octane backlog from an MS Excel
file.
In this topic:
l "Step 1: Prepare the import file" below

l "Step 2: Import backlog items" on page 117
Step 1: Prepare the import file

In an Excel (.xls or .xlsx) file, list the user stories, quality stories, and defects to import. If you
exported this file from another tool, you must change the file according to the specifications
described below.
ALM Octane supports importing Excel sheets from Microsoft Excel versions 2010 and higher.
Import file example. A template file is available to help you construct your import file. In
the ALM Octane menu, click Import Backlog Items. In the Import dialog box, click View
import file example to download the example Excel file.

Backlog management
To prepare the import file:

1. In an Excel file, create a separate named tab for each item type to import: User stories, Quality
stories, and Defects.
You only need to create tabs for the item types you want to import.
2. In Row 1 of the sheet, add a header row for the fields whose values you want to import. See
the tables below for a list of possible fields. The mandatory fields required for a successful
import are noted.
Note:
l The values described in the tables below are the default system values. Your ALM
Octane workspace may use different values depending on the workspace
configuration.
l Localization: You must use the English field names, even if your UI is in a different
language.
3. On separate rows, enter field values for each user story, quality story, and defect to import.
Each entity in ALM Octane has required fields, as determined by the entity form settings. If
you do not enter values for all the required fields of an entity, ALM Octane imports the entity
in Draft status. After the import, open these items and fill in values for all required fields.
Tip: Use the Is Draft column to find items in Draft status.
Localization: If your user language is set to another language, use localized values in the
Excel sheet.
By default, you can import up to 1000 backlog items in a single import. If you have more,
prepare other Excel files to import all the items.
If you want to import more than 1000 backlog items, have your site admin set the IMPORT_
WORK_ITEMS_FUSE configuration parameter to the necessary number. For details, see
"IMPORT_WORK_ITEMS_FUSE " on page 490.
User/Quality story fields

In the User stories or Quality stories tab, enter some or all of the following fields. Field names are
not case-sensitive.
Mandatory fields
name Free text field, maximum of 255 characters.

Backlog management
Optional fields (recommended)

epic An existing or new epic or feature name.
feature
If the value matches an existing epic and feature name, ALM Octane
associates the imported story with the epic and feature. If the value does not
match, ALM Octane creates a new epic and feature.
The epic and feature must both be in the import file to import the values. If
one of the columns is not present, ALM Octane does not import either value.
description Free text field.
author The login name in the ALM Octane space settings for the person who created
the story.
If there is no value entered, the user story sets the value as the person
performing the import.
owner The ALM Octane login name for the item's owner
phase A list value. Possible values include: New, In Progress, In Testing, and Done.
If you do not enter a value, ALM Octane sets the phase to New.
product_areas The application modules of your workspace.

The name of or path to (for second-level modules) the application module. If
you associate the story with multiple application modules, separate the names
with a comma.
release The name of a release already created in ALM Octane.
sprint The name of a sprint in the relevant release.
story_points Positive integer.
team The name of the team. You must assign the team to the specified release and
sprint.
user_tags Free text specifying the name of tag to attach to the item.
If the value matches an existing tag, ALM Octane adds the tags to the
imported story.
Tip: Create a special tag for imported items to filter these items.

Backlog management
<User defined The label name (as set in the ALM Octane workspace settings for a user story)
fields> of any user-defined fields in the user story form.
<Other You can add any REST API-editable fields to the Excel sheet.
system-
See your space admin or workspace admin for the possible values for these
defined
fields.
editable
fields>
Defect fields
In the defects tab, enter some or all of the following fields. Field names are not case-sensitive.
Mandatory fields
Optional fields (recommended)
epic An existing or new epic or feature name.
feature
If the value matches an existing epic and feature name, ALM Octane
associates the imported story with the epic and feature. If the value does not
match, ALM Octane creates a new epic and feature.
The epic and feature must both be in the import file to import the values. If
one of the columns is not present, ALM Octane does not import either value.
severity A list value. Possible values include: Low, Medium, High, Very High, and
Critical .
defect_type A list value. Possible values include: Pre-release or Escaped.
detected_by The ALM Octane user name of the user who opened the defect.
owner The ALM Octane login name for the defect owner
phase A list value. Possible values include: New, Deferred, Opened, Proposed Close,
Closed, Rejected, and Duplicated.
taxonomies The environment tags for the defect. Enter the tag names for the
environments defined in your workspace, separated by a comma.

Backlog management

The name of or path to (for second-level modules) the application module. If
you are associating the story with multiple modules, separate the names with a
comma.
release The name of a release already created in ALM Octane.
sprint The name of a sprint in the relevant release.
story_points Positive integer.
team The name of the team. You must assign the team to the specified release and
sprint.
user_tags Free text specifying the name of tag to attach to the item.
imported story.
<User defined The Name value defined for the user-defined field (as set in the ALM Octane
fields> workspace settings) of any user-defined fields in the form.
<Other You can add any REST API-editable fields to the Excel sheet.
system-
defined
fields.
editable
fields>
Step 2: Import backlog items

1. In the ALM Octane menu, click Import Backlog Items.
2. In the dialog box, click Browse and navigate to the folder with the Excel file.
When you click Import, ALM Octane performs a validation to check correct formatting of the
Excel file and that you have not imported the same file before.
ALM Octane does not support updating Backlog items via import. You can import each Excel
file only once.
When ALM Octane finishes the validation:

Backlog management
If there are ALM Octane displays a report of the validation with the sheet and line
errors of the error.
At the bottom of the error report, click the Export to Excel link to save
the error report.
Fix the errors and try the import again.
If there are no The import begins.

errors
Next steps:
l "Set up and manage release plans" below
l "Work on your stories" on page 132
Set up and manage release plans

After you set up the product backlog, use the Backlog module to manage release work plans.
In this topic:
l "Build the release backlog" below

l "Split unfinished features" on the next page
l "Move items to another release" on page 120
Build the release backlog

Build your release backlog by assigning the existing items to releases.
To assign features to a release:

1. In the Backlog module, open the Planning tab and display the releases to plan.
The Planning tab contains the release's planning bucket:

Backlog management
2. Expand the release bucket, using the down arrow at the bottom, to view the sprint and team
buckets:
Select a specific sprint or all sprints.

3. Drag items:
l Into a release bucket to assign them to release without a sprint or team
l Into team buckets to assign them to the selected sprint and team.
Drag stories to the No team bucket to assign them to a sprint without specifying a team. Drag
items to a team in the All sprints bucket to assign them to a team but not a sprint.
Caution: Assigning a feature does not assign its user stories, quality stories, or
defects.
The features, user stories, quality stories, and defects are now ready for work.
Split unfinished features

Usually, at the end of a sprint or release period (like a push), you should close all features and user
stories. If you are unable to complete all the user stories and defects, split the feature.
To split features:
1. In the Backlog module, select the feature to split.
2. In the toolbar, click the Split Feature button .

3. In the Split Feature dialog, specify the details for the current feature and the new feature.
4. If necessary, use the options to instruct ALM Octane how to resolve all open user stories and
defects.
5. Specify the number of total story points to assign to the new feature.
When you split the feature, ALM Octane creates another feature set to the New phase.
ALM Octane adds the following attribute values and items to the new feature:

Backlog management
l The value of any field other than the Name, Release, or Phase.
l Tests associated with the feature
l Attachments included in the original feature
Note: ALM Octane does not copy values of user-defined fields to the new split feature. If
your feature form requires a user-defined field, you cannot use the Split Feature
command. Instead, create a new feature.
Move items to another release

Sometimes, you may need to reevaluate what content to deliver. When this happens, you may
need to move stories to a different release.
To move items to another release:

1. If necessary, in the Backlog module tree, select the epic or feature to move.
2. In the grid, select the features, user stories, quality stories, or defects.
3. In the toolbar, click the Planning button .

4. In the Plan Stories dialog box, reassign the feature or story to a new release, sprint, and team
as necessary.
Note: When you reassign a feature to a new release, ALM Octane assigns all
unfinished stories to the new release. ALM Octane does the reassignment in the
background. Continue working on other entities while ALM Octane reassigns the
feature and stories.
After the reassignment, ALM Octane updates the release buckets for the previous and new
releases.
Next steps:
l "Balance release and sprint workloads" on page 122
l "Backlog planning buckets" on the next page

Backlog management
Backlog planning buckets

When you plan a release or a sprint, use the planning buckets in the Backlog module. Planning
buckets are widgets that represent assigned work.
As you assign items, ALM Octane refreshes the planning bucket to reflect the new contents. ALM
Octane also updates the bucket if you change the item's phase, story points, and so on.
In this topic:
l "Open planning buckets" below

l "What does the planning bucket display?" below
Open planning buckets

1. In the Backlog, open the Planning pane on the right.
2. Click the number of displayed releases to select the releases to plan. ALM Octane opens a
separate bucket for each release you select.
3. To view the sprint and team buckets, click the expand arrow beneath the release bucket.
What does the planning bucket display?

The planning bucket displays details about the current release progress:

Backlog management
Release Click to filter the grid and backlog tree by this release. This is helpful when you
name want to assign the release items to specific teams and sprints.
Release The number of days left in the release

countdown
Release Each bar represents a sprint. ALM Octane highlights today’s date and the
timeline current sprint.
Release Displays aggregated data from the backlog items assigned to this release.
progress
Hover over the widget to see an explanation of each area.
widget
Sprint filter Select one sprint or all sprints.

To assign backlog items to a sprint by dragging them into the sprint bucket,
you must select a sprint.
Team The progress of individual teams, in story points.

progress
Hover over the widget to see an explanation of each area.
bars
See also:
Balance release and sprint workloads

When planning work, effective planning involves assigning the correct amount of work.
In ALM Octane, each team has a release and sprint velocity, which helps determine the release
capacity. In parallel, you estimate each user story, quality story, and defect in story points. Using
these estimations, create optimal work plans by assigning the correct amount of work for the
available capacity.
In this topic:
l "Velocity vs. capacity" on the next page

l "Set the default sprint velocity" on the next page
l "Set sprint velocities" on the next page
l "Plan release and sprint backlogs" on page 125
l "Track velocity and capacity" on page 125
l "Use-case scenario: Setting your team's velocity" on page 126

Backlog management
Velocity vs. capacity

Planning involves different measures of workload for your teams:
Velocity Velocity is the expected amount of work to complete during a specified period. You
measure velocity in total story points.
Velocity is an over-time calculation. This means that you calculate the velocity for
your team by looking at completion over time. If a team increases the amount of
work finished, then the velocity increases. Likewise, if the amount of work finished
decreases, the velocity goes down.
In ALM Octane velocity is the default for a team's workload. You assign each team a
velocity as a starting point for all planning.
Capacity Capacity is the actual amount of available time for work during a specified period.
You measure capacity for a team in story points. You measure capacity for an
individual team member in hours.
Capacity is a calculation based on a specific, finite period. Capacity is a dynamic
measure according to manpower and availability changes.
In ALM Octane, you adjust capacity for each release and sprint. This lets you plan
the releases and sprints for the available resources and time.
Set the default sprint velocity

Estimate what you think your team can complete in a sprint (based on past performance).
For details on setting the default velocity, see "Adjust a team's capacity per sprint" on page 542.
Set sprint velocities

For each sprint, edit the individual sprint velocity. If your team has variable work rates, edit the
expected capacity for these periods.

Backlog management
To set sprint velocities:

In the Backlog In the release buckets, hover over a team line in the grid and click the
module Edit button:
In the Team In the Team Member Buckets area, click the Capacity Settings button:
Backlog module
If you do not see the team member buckets, ensure you select a
release, sprint, and team in the module filters.
2. Update any the following:
l In the Details tab, update the Estimated velocity value.
l In the Velocity tab, update the Available in Sprints value and the Expected Velocity

Backlog management
column.
l In the Members tab, update the Capacity per day (hr) field value for any team member.
Plan release and sprint backlogs

Assign stories to a release and sprint to fill available capacity.
To balance the workload:

l Remove stories from a release or sprint
l Break large user stories into parts, and leave only a part in the current release or sprint
l Increase the team velocity
Track velocity and capacity

As you work, track the progress of each release, sprint, or team. Compare the actual work
completed against the expected work completed.
To track velocity and capacity:

In the Space settings (for In the Teams tab, the Velocity tab displays a table of actual
Shared space and velocity and expected velocity. ALM Octane updates this table
workspace administrators) across releases and sprints, per team:
In the Team Backlog
module (for team leaders)

Backlog management
In the Dashboard Add the Velocity Tracking widget. This widget shows the
expected and actual velocity. Display the graph for one or more
releases, sprints, or teams:
The yellow line indicates the actual velocity average (in story
points) across sprints. ALM Octane calculates this average from
previously completed sprints.
Use-case scenario: Setting your team's velocity

You are managing a team working on the development of an online shopping application. Your
team is assigned to the first release with four members. How do you plan your team's velocity and
capacity?
Before the release begins, you or the workspace administrator enters an expected velocity:

Backlog management
To get this number, you realize and decide:

l There are 3 sprints in this release, each 2 weeks long.
l Each person can achieve 1 story point per day.
l Each person is available for 5 days each week, for a total of 10 days per sprint.
Each person achieves 10 story points per sprint. During the release each team member can
complete 30 story points. As a result, the team can achieve 120 story points.
In addition, you set the daily capacity (measured in hours), for each team member:

Backlog management
This ensures you do not exceed each member's available work time and jeopardize their progress.
As you work, monitor the actual progress by comparing the expected velocity vs. the actual
velocity, using the Velocity Tracking widget in the Dashboard.
Next steps:
l "Manage the team backlog" below
l "Backlog planning buckets" on page 121
l "Team planning buckets" on page 131
Manage the team backlog

After creating a release plan, work with your team's items. Do this from the Team Backlog module
or the Backlog module.
In this topic:
l "Edit your team's capacity per sprint" below

l "Assign items to team members" below
l "Track team progress" on the next page
Edit your team's capacity per sprint

If your team has variable work rates, edit the expected capacity for these periods instead of using
the default velocity capacity.
For details, see "Set sprint velocities" on page 123.
Assign items to team members

After setting up your release plan, assign each user story to a team member. Do this on a team-by-
team and sprint-by-sprint basis.
To assign items to team members:

l In the Details tab of the item, set the item Owner.
l From the Backlog Items tab, drag the item to a team member bucket in the Teams tab.
Team member buckets are updated with the story details:

Backlog management
For details on what the team member buckets display, see "Team planning buckets" on page 131.
Caution: Assigning stories to a team member does not assign its tasks.
Track team progress

As a sprint progresses, track the team and individual progress.
To track team progress:

How? Where? What?
Backlog Backlog In the Overview tab, use available widgets, including:
dashboard module
l Story points by metaphase
widgets
l Feature status in order of rank
Release Backlog In the Planning tab, the Release planning buckets display progress of
planning module each team. The graph reports the total number of story points in each
buckets phase:
For details on the release planning buckets, see "Backlog planning

buckets" on page 121.

Backlog management
Team Team In the upper left corner of the Team Backlog module, view a graph that
sprint Backlog displays the development status for the selected sprint. This graph
progress module displays the number of story points. It also shows the number of critical
graph defects assigned to the team:
You measure the progress by story points assigned to all members of

the team in the current sprint cycle.
Team Team Each team member bucket displays the progress of the items, tasks, and
member Backlog defect assigned to a team member:
buckets module
Team Team The commits widget shows you the work your team has committed
commits Backlog during the current time frame. ALM Octane breaks down the commits
widget module by story type:
Hover over the widget title for a reminder of the commit message
format used to associate commits with each type of story.
See more information about changes committed by your team in the
Commits column. For details, see "Use the Commits tab to track
committed changes" on page 202.

Backlog management
Next steps:
l "Balance release and sprint workloads" on page 122
l "Work on your stories" on the next page
l "Team planning buckets" below
Team planning buckets

In the Team Backlog module, use planning buckets to assign items and tasks to team members.
During the sprint, view team member progress..
View the team planning buckets in the Team pane to the right of the Team Backlog.
The buckets display information for all sprints or a selected sprint in the release. Each bucket
represents one member of your team.
Each team member bucket displays the following:

l The total number of items assigned, including the number of story points
l Number of items still in progress
l The total amount of task hours marked as complete (green) and in progress (blue)
Tip: Click the team member name in a bucket to show that user's items in the grid.
In the team member buckets, ALM Octane displays the team member's progress and capacity in
hours.
ALM Octane assumes each team member works 6 hours per day. Update this in the Members tab
of the Team settings. The total capacity for a sprint is the daily capacity times the number of
working days in a sprint.
If the bucket does not display the expected results, check:
l The Team member has capacity defined
l You assigned the item to the correct owner

Backlog management
l You assigned story points to the item

l You added tasks to the item
l You assigned tasks to the correct owner
l You estimated hours for the item's tasks
Work on your stories

Once you have assigned items, manage your own individual backlog. Do this from the Team
Backlog module or the Backlog module.
In this topic:
l "Break items into tasks" below

l "Use the task board to manage work" below
l "Work on assigned items" on the next page
l "Block an item" on the next page
l "Track work completion progress" on page 134
l "Split unfinished user stories" on page 134
Break items into tasks

Tasks enable you to work on an item in more manageable chunks.
To create tasks:
1. In the Tasks tab of a user story, quality story or defect or the Team Backlog module, add
tasks.
Tip: In the Tasks to generate field, add one more lines to add tasks when creating an
item. ALM Octane adds each line in the field as a separate task.
2. If necessary, assign a task to yourself or another user.

In the Team Backlog module, drag a task card to a bucket to assign it.
3. Estimate the effort needed for each task, in hours.
Use the task board to manage work

Use the Board View to manage task progress.
To use the Task Board:

ALM Octane displays the Board View by default:

Backlog management
l In the Backlog: in the Tasks tab when you open an individual user story, quality story, or
defect
l In the Team Backlog: in the Tasks tab
ALM Octane groups tasks per user story, quality story or defect. The board displays each task
phase in its own column. Drag the tasks from column to column to update the phase.
To add tasks, click the + Task button in a Task board column. Provide a name for the task. Then,
click on the task number link to define other necessary attributes.
Note: You can view up to 100 lanes of tasks in a given period. If ALM Octane does not
display the necessary lanes, add a filter. If you have a filter set, the Board View displays
only stories that contain tasks.
Work on assigned items

In the item, advance the phases as you complete work. For details, see "Advance the phase of an
item" on page 74.
Tip: If you are working in the Team Backlog module, use the Board View for a visual,
customized display of work items. For details, see "Use the Board View" on page 135.
Block an item
Sometimes, when working on a story, you cannot proceed in your work. In these cases, update the
item to show you cannot work on this item.
To block an item:
1. Open the item and navigate to the Details tab.
2. In the Details tab, set the following fields:
l Blocked: Select Yes from the drop-down list
l Block reason: The reason why you cannot keep working.
3. Save your changes.
In both the Grid view and Board View, ALM Octane displays an icon:

Backlog management
Tip: If the icon is not displayed, ensure that you have added the Blocked column to the list
of visible items in the grid.
Track work completion progress

Track your work completion progress to ensure you finish items at the right time.
To track work completion progress:

Chart/graph Where? Description
Task board Backlog module and The story details show the completion status of the
Team Backlog module tasks in the selected story:
Team Team backlog module Each team member bucket shows the progress for
buckets assigned items (stories and tasks):
Tip: Hover over the graph to see a

numerical breakdown of progress by hours.
This graph does not show the individual per-story

breakdown.
Split unfinished user stories

Usually, at the end of a sprint, you should close all user stories. If you are unable to complete all
the tasks, split the user story.

Backlog management
To split user stories:

1. In the Backlog or Team Backlog module, select the user story to split.
2. In the toolbar, click the Split Backlog Item button .

3. In the Split Story dialog, specify the details for the current user story and new user story.
4. If necessary, use the Move open tasks option to instruct ALM Octane how to resolve all open
tasks.
When you split the user story, ALM Octane creates another user story in the New phase.
ALM Octane moves all items not marked as Done to the new story. ALM Octane also adds these
attributes and items to the new feature:
l The value of any field other than the Name, Sprint, or Phase.
l Tests associated with the user story
l Attachments included in the original user story
Note: Values of user-defined fields in a user story form are not copied to the new split user
story. If a user-defined field is a required field in your user story forms, the new user story
is created in Draft mode and you will need to add the required information in order to edit
it.
Next steps:
Use the Board View

Use the Board View to manage items in a visual way.
In this topic:
l "What is the Board View?" on the next page

l "About the Story Board" on the next page
l "Customize the Story Board display" on the next page
l "Set Story Board workflow rules" on page 138
l "Add items" on page 139
l "About the Story Board" on the next page

Backlog management
What is the Board View?

The board view provides a visual, interactive display of items. It is divided into lifecycle phases.
Items are displayed as individual cards, which you progress through the phases until completion.
The board view is available for epics, features, backlog items, tasks, and requirements.
About the Story Board

The Story Board is a board view that displays your team's backlog lifecycle. It displays work items
according to context, meaning a specific release, sprint (in case of Scrum), and team.
The board displays the four metaphases: New, In Progress, In Testing and Done.
By default, the different item types are merged into a single column per phase:
l New merges the New columns for user stories, defects, and quality stories.
l In progress merges the Opened column for defects and the In Progress columns for user stories
and quality stories.
l In Testing merges the Fixed column for defects and the In Testing for user stories and quality
stories.
l Done merges the Closed column for defects and the Done column for user stories and quality
stories.
You can divide into additional phases to reflect your team's workflow.
The board supports both Kanban and Scrum methodologies.
The Story Board can be accessed from The Team Backlog in the main menu, or by clicking the
Board View button in the Backlog Items tab.
Customize the Story Board display

You can customize the display to include more columns representing more phases, to merge
phases for different item types, rename a column, and hide a column.
You can also set the Work in Progress (WIP) limit and the cycle time limit, as described in "Set
Story Board workflow rules" on page 138.

Backlog management
Note: You need the Customize Story Board permission to perform the following
customizations.
To merge phases into a single column

1. Right-click the column of the phase you want to merge, and then click Edit.
2. In the Select Phases dialog box, select the phases for the relevant item types, and then click
OK.
3. If required, click on the column name to rename it.
To split a column
1. Right-click the column header of the metaphase in which you want split a phase, and then
click Edit.
2. In the Select Phases dialog box, for a specific item type, clear the phase field that you want to
display as a separate lane, and then click OK.
For example:
A new lane is added for the phase that you cleared.

Hover over the column header to see the workflow phases for that specific column.
3. The column name is a duplication of the existing column. Click on the column name to rename
it.
To hide a column
Right-click the column that you want to hide, and then click Hide.

Backlog management
To restore the column, in the toolbar, click the Choose Columns button, and select the
column.
Set Story Board workflow rules

When you work with the Story Board, specify rules to structure your workflow, including:
A work-in- A per-team limit for the number of items allowed (WIP) in each metaphase and
progress phase. Each team can have different limits for each metaphase and phase.
(WIP) limit
Cycle time A per phase limit on the cycle time for an item in each phase. The cycle time is the
limit time spent working on an item. This is the time take from when work begins on
an item to when you complete it.
ALM Octane measures the cycle time as the number of days in which the item is
in the In Progress or In Testing phases.
To set board rules:

1. At the top of the Team Backlog module, select a release and team from the drop-down lists.
2. In the header of any Board View column, below the WIP limit indicator, hover over the
displayed number:
3. In the displayed tooltip, click the infinity symbol in the relevant field and enter a new limit.
4. If the team violates one of the limits, ALM Octane displays an alert:
For ALM Octane displays an alert icon in the phase column header:
WIP limits

Backlog management
For cycle l The Board View header displays an alert

time limits l The individual Board View card displays an alert with a clock icon.
Hover to see details on the limit violation:
Hover over the alert to see the details.

5. For cycle time limits, track completion using the Control Chart widget in the Dashboard:
Note: This widget is per release and sprint, not per team.
Add items
Use the Board View to add items as in any other ALM Octane view.
To add items in the Board View:

In the toolbar, click the down arrow next to the + and select the type of item to add.

Backlog management
Also, add existing items from the release backlog or sprint backlog:
l In the main Backlog module window, drag an item to a release bucket or sprint bucket (if
necessary).
l In the Details tab of an item, assign the item to a release and/or sprint.
l Hover on a column in the Board View and click the Add + button. Select the item to add (defect,
user story, or quality story), and name.
To continue editing details for an item, click the entity link.
If you want to rank these items, drag and drop items within any column to set the rank. As you
move the items, ALM Octane adds or updates the number to reflect the item rank.
See also:
Perform sprint closure and retrospective

When nearing the end of a sprint, it is important to review progress and evaluate the sprint. Use
the Retrospective area of the Team Backlog module to do this.
Note: To access the Retrospective area, you need Leader role permissions.
In this topic:
l "Enable the team retrospective area" below

l "Address incomplete items" below
l "View a sprint scope change report" on the next page
l "Perform sprint retrospective" on page 142
Enable the team retrospective area

By default, the retrospective area is not visible.
To enable the team retrospective area:

1. In the Team Backlog module, select a release, sprint, and team.
2. In the module title bar, enable the toggler for the Retrospective area.
ALM Octane hides the standard tabs and displays the retrospective area.
Address incomplete items

When you finish a sprint, you should finish or move all items.

Backlog management
When you open the Retrospective area, ALM Octane displays a summary of the current sprint
items:
This summary is a complete list of all items in the team and sprint. To address the incomplete
items, isolate these items.
To address incomplete items:

1. In the Retrospective area, open the Incomplete items tab.
2. In the Smart List View or Grid View, change the item attributes:
l In the toolbar, click the Planning button and move the item to another sprint.
l Open the item and reassign the item in the Details tab.
l If necessary, split the item into a new user story. For details, see "Split unfinished user
stories" on page 134.
View a sprint scope change report

If you are team leader, use the Scope Change report to watch changes in your team's sprint
content. Use this information to improve your sprint plans.
To use the sprint scope change report:

1. In the space settings, ensure that you or the workspace administrator assigns the team to the
sprint. In addition, ensure that each sprint is entered correctly in the Release details.
2. Set the planning deadline for the team.
a. In the Team tab, click the Team Management button .

b. In the Details tab, in the Planning deadline field, specify the number of days after the
sprint starts as the baseline point for the sprint.
If you do not set a deadline, ALM Octane uses 0 days as the default.
ALM Octane uses any changes made to sprint content after this deadline in calculating
the sprint scope change.
3. Have your workspace administrator assign the team to the appropriate releases.

Backlog management
Note: Once your team is associated with the appropriate releases, you cannot change
the planning deadline for past and in-progress sprints.
4. In the Team Backlog module, select the appropriate sprint.

5. Above the grid or retrospective report, view the Scope Change report widget.
Each bar in the widget represents a different status:
Planned You added the item to the sprint before the planning deadline.
Unplanned You added the item to the sprint after the planning deadline.
Descoped You moved this item to another sprint or team after the planning deadline.
Split You split the item into an extra item after the planning deadline.
Perform sprint retrospective

When finishing a sprint, it is important to discuss as a team what went well and what to improve in
future sprints. Use the retrospective area to help.
To perform a retrospective:
1. In the Retrospective area, open the Retrospective tab.
2. In the What went well and To improve edit fields, list the takeaways from the sprint.
3. Click the Save button.
See also:
Create and run tests

Add manual and automated tests to items in the Backlog module to test and track the quality of
your release.
ALM Octane displays manual and automated tests in Tests tab of the Backlog module or the
Tests tab of any item. Add tests to any item in the Backlog module.
ALM Octane incorporates test run results dashboard analysis. This lets you track your release,
build, and product quality.
For full details on testing, see "Testing" on page 222.

Backlog management
Next steps:
l "Run manual and Gherkin tests" on page 251
l "Run automated tests from ALM Octane" on page 275
Analyze release progress

In the Backlog and Team Backlog modules, use different ALM Octane widgets to analyze release
progress.
In this topic:
l "Progress column" below

l "Planning buckets" below
l "Overview tab widgets" on page 145
l "Release Forecast widget" on page 145
Progress column
View the Progress column for any feature or backlog item. Hover over the progress bar to see
more detail about a specific item:
Note that ALM Octane measures progress for Epics and Features by story points, and progress
for Backlog Items in hours.
View the Progress column in both the Grid View and Smart List View.
Planning buckets
In the Backlog module, view the release progress bucket:

Backlog management
In the Team Backlog module, view the Team Progress widget:
In the Team Backlog module, view the planning buckets for each of your team members:

Backlog management
Overview tab widgets

Add the relevant widgets to the Overview tab of the Backlog module or the ALM Octane
Dashboard, including:
l Burn down and Burn Up graphs
l Release and sprint cumulative flows
l Feature status in order of rank
l Feature story points by feature type
l Control Chart
l Velocity Tracking
In the Backlog, use the release filter to update each of the widgets for a current release and sprint.
Release Forecast widget

Add the Release Forecast widget to the Dashboard module.
This widget displays a line with the forecasted progress of user stories or defects through the end
of selected release. This graph also includes details on the release, including finished story points
and expected completion.
ALM Octane displays the forecast line after you mark enough Backlog items as Done.
How is the forecast calculated?

l The forecast is based on the state of the release’s actual story points until now, together with
the planned story points for the team. This is based on the team manager’s expected velocity,
as defined in the Team Backlog module. The gap between actual and planned velocity is used
to forecast when the release content will be complete, based on the assumption that this gap
will remain constant in the future.
For example, if the expectation to date is 50 points and actual completion is 45, the gap shows
that the current pace is 90%. The forecast assumes that at the planned date of completion,
90% of the content will be done.
l If there is no expected velocity available for calculation, the forecast is based on the assumption
that the actual points-per-day rate will remain constant in the future.
What do the colors represent?

l The solid green line shows actual progress, and the yellow line shows expected velocity as
defined by the team lead.
l If the forecast (dotted) line is green, this means the release content is expected to be done by
the release date.
l If the line is red, the content will not be complete on time, at the current rate of progress.

Quality management
Where can I see forecasting?

Forecasting is available on Agile graphs, and not on Custom graphs. Forecasting is available for a
release, and not for a sprint. You can see forecast data on burn-up graphs only.
If there are too few story points to generate a release forecast, your graph will be empty. Clear the
Forecast checkbox to show data in the graph.
Next steps:
l "Assign items to application modules" below
l "Analyze application area quality" on page 157
Assign items to application modules

Assign item to application modules to get an overview of product quality.
To help you assess product quality, assign Backlog items to application modules
For details on how to work with application modules, see "Work with application modules" on
page 148. For details on application modules, see "Quality management" below.
Next steps:
l "Create and manage test assignment rules" on page 416
l "Quality management" below
Quality management
In ALM Octane, you have the ability to monitor development progress and also to track product
quality.
In this topic:
l "How does ALM Octane measure quality?" below

l "Working with application modules" on the next page
How does ALM Octane measure quality?

ALM Octane measures quality in many ways: test results, defects, or feature quality status. Use
application modules and associate items with these application modules to help ALM Octane
analyze product quality.

Quality management
Application modules are the functional areas of the product. You create these areas based on user
processes, areas of the product, and so forth.
Using application modules is important because experience shows that most defects and test
failures in products are limited to a small number of areas in an application. When you set up
application modules and associate items with these modules, you see problematic areas and
concentrate testing efforts and development effort toward these areas.
Application modules are release-agnostic. This means the details you view reflect all releases of
the product.
Working with application modules

In the Quality module, you organize application modules in a tree:
For details, see "Work with application modules" on the next page.

Quality management
Next steps:
l "Work with application modules" below
Work with application modules

To track product quality, set up application modules and assign items.
In this topic:
l "Plan the application module structure" below
l "Build the application module tree" on the next page
l "Create and manage rules to assign automated tests" on page 151
Plan the application module structure

When deciding how to structure your application models, consider the following:
l How you currently manage the quality of your product. In particular, focus on the areas of the
product whose quality you want to track.
Example:
l End-to-end user processes

l User navigation within the product
l Consistency and syntax of messages and warnings
l Performance and load
l Regression
l How you structure the application - windows, panes, and so forth. These areas can help you
decide which and how many application modules to create.
l How users use the application. Is it a per-module use? Are there special areas and functionality
in the application that they need? These decisions influence whether you need application
modules.
l How you want to account for your organization's internal development processes. Do you need
to test these areas?

Use this information to design your application module tree in the next step.

Quality management
Build the application module tree

Before you can perform any analysis, build the application module tree.
To build the application module tree:
1. From the ALM Octane title bar, open the Quality module .
2. In the toolbar above the tree, click the Add button +.
3. In the Add Application Module dialog box, specify a Name, Description, and Parent.
If you selected an item in the tree, ALM Octane uses the selected node as the Parent
application module.
Tip: Did you create an application module at the wrong place in the tree? Click the
Edit button and update the Parent field. You can also drag items to new parent items
as needed.
If you reorganize the tree, ALM Octane rearranges the order by rank.
4. Repeat as necessary to create the full tree.
5. In the toolbar, click the down arrow on the Define subset button .
6. From the drop-down list, select the application modules to display.
You can select only the first level application modules.

Quality management
7. In the toolbar, click the Show all descendants button to display the application modules
created as children of the currently selected item.
Add user defined fields to the application module

Application modules include a Details tab, which by default, include the Description and Parent
fields.
Customize this tab to include additional fields, including user defined fields. For details, see
"Customize fields" on page 547.
Use these fields to create cross-filters in the Backlog and Team Backlog modules and in the
Dashboard. For details, see Create a cross filter.
Assign items to application modules

In order for application modules to be useful, add features, tests, and defects. After you assign
items, ALM Octane can assess product quality.

Quality management
To assign items manually:

When In the item, in the Application modules field, select a relevant application module:
creating a
single item
For 1. Do one of the following:

multiple l In the Backlog module, select tests in the Tests tab, features in the
items from Features tab, or defects in the Stories tab
the grid
l In the Quality module, select items in the Defects, Features, or Tests tab
2. In the toolbar, click Assign to Application Modules.

3. In the dialog box, select the relevant application modules and click OK.
If you are assigning automated tests, the Assignment Rule button is
enabled. Use this to create a rule that assigns automated tests. For details,
see "Create and manage rules to assign automated tests" below.
Tip: To find unassigned items, in the application module tree click the Unassigned link.
Create and manage rules to assign automated tests

Assigning tests to application modules may be tedious and time-consuming. Create a rule to
assign tests to specific application modules.

Quality management
To assign tests:
1. In the Tests tab (in the Quality module or the Backlog modules), select one or more tests.
2. Click Assign to Application Modules.

3. Select one or more application modules.
4. Click Assignment Rule. The Create or Edit Assignment Rule dialog box opens:
5. Add a new rule, or locate an existing one that you can adjust or copy.
Example: You have some tests that should be assigned to the Shopping Cart
application module, but they are not.

Quality management
Before you create a new test assignment rule for this, check if you already have a rule
for tests of class My*Cart.
This rule might currently assign tests to other application areas and you can quickly
modify the rule and add the Shopping Cart application module to it.
l To create a new rule, enter a meaningful name in the Rule name, such as End2End Tests.
l To search for an existing rule, start typing a filter property value or a rule name. From the
list that opens, select the rule.
Tip: To view the full list of rules, enter only *.
To create a new rule based on the one you selected, change the Rule name.
To update the selected rule, leave the Rule name unchanged.
6. (Optional) Edit the list of application modules to assign with this rule.
You can also add a Test owner to assign, or one or more test fields: Test framework, Test
type, Test level , and Testing tool .
7. If you selected many tests without opening an existing rule, ALM Octane creates an initial
filter. ALM Octane bases this filter on the properties of the selected tests.
Click Add filter to add conditions to the filter, or edit the existing conditions. Use these fields
to create the conditions: Class name, Component, Name, and Package.
Filters can be multipart and complex and can include '*' as a wildcard. If necessary, click the
Add filter button again to add more items to the filter.
You must meet all conditions for the rule to assign the selected values to an automated test.
8. Select if the rule assigns application modules and a test owner if those fields already have
values, or only if they are empty.
9. As you edit the rule, view how many currently existing tests you will change with the new rule.
10. Click Create Rule. The rule affects all current and future tests that match the filter. This
includes tests currently in the system, as well as new automated tests added in the future.
To manage test assignment rules:
1. In the Tests tab select one or more tests, and click Assign to Application Modules
2. Select one or more application modules and click Assignment Rule. The Create or Edit
Assignment Rule dialog box opens.
3. Click the Manage Rules link in the lower left corner.
4. To edit a rule, click the rule ID link and modify its definitions as described above.

Quality management
To sort, filter, group, delete, and export rules, use the toolbar options similar to other entities
in grids.
Tip: DevOps administrators can manage tests assignment rules in the ALM Octane
settings area. For details, see "Create and manage test assignment rules" on page 416.
Next steps:
l "Create and run tests" below
l "Run pipelines" on page 175
l "Report and track product defects" below
Create and run tests

ALM Octane displays manual and automated tests in Tests tab of the Quality module.
ALM Octane incorporates test run results dashboard analysis. This lets you track your release,
build, and product quality.
For details on managing the entire testing process, see "Testing" on page 222.
Next steps:
l "Testing" on page 222
Report and track product defects

This topic describes how to submit and manage defects in ALM Octane.
In this topic:
l "Report defects" below

l "Track and analyze defects" on the next page
l "Copy a defect to a different workspace" on page 156
Report defects
You can submit defects at all stages of your work.

Quality management
Work area How

Backlog module In any of the backlog grids, select + > Defect.
The new defect is associated with the feature selected in the tree.
Quality module In the Defects tab, create a new defect.

The new defect is associated with the application module selected in
the tree.
Inside a story or test In the Details tab of a user story, quality story, or test, click the Report
(after the test ran)
Defect button .
ALM Octane associates the defect with the current item's feature.
During a manual test

run Click and then Add new defect.
In the Tests tab of a In the Pipelines module, open the pipeline run and select the Tests
pipeline's latest run tab.
1. Select one or more automated test runs.
2. Click Report Defect.

ALM Octane links the new defect to the selected runs and contains a
link to the Tests page of the relevant pipeline run.
Track and analyze defects

Watch defects like any Backlog item:
l Add filters to view relevant defects.
l Track defect progress in the Dashboard Module or the Overview tab.
l Connect defects with features, user stories, or application modules.

Quality management
Copy a defect to a different workspace

You can copy defects from one workspace to another.
Copying a defect to another workspace is useful, for example, if you are dependent on users in
other workspaces to handle parts of your defect. You can create a defect for the other users in
their workspace, and then verify the fixes before closing the defect in your workspace.
You can only copy to a different workspace if:
l You have access to it.
l It is associated with the same shared space as the workspace with the original defect.
How to copy a defect to another workspace:

1. For the defect, click Copy to Different Workspace .
2. Choose the target workspace and click Copy.
3. Click the link in the message to open the new defect in the other workspace.
The new defect created with the same name as the original defect, in the New phase. The Detected
By is the user who copied the original defect.
A comment is automatically added that contains a link to the workspace of the original defect. If
you have access, click the link to open the original defect.

Quality management
What is l Common fields.

copied? This varies depending on the entities that the workspaces share.
Example: If the release of the original defect is defined at the shared

space level, the value is copied. If the release of the original defect is
defined at the workspace level, the release is not available in the other
workspace and is not copied.
l User-defined fields (UDFs) that are defined at the shared space level and are
common to both workspaces
l Attachments
l Tasks
What is l Comments
not l History
copied?
l Test runs and old versions
See also:
l Filter items
Analyze application area quality

Use the aggregated data from your application modules to analyze product quality across
In this topic:
l "Analyze specific application area quality" on the next page
l "Identify application modules affected by recent development" on the next page

Quality management
Analyze specific application area quality

View quality for each of your application modules. Assign items to application modules to analyze
product quality across releases. From the associated items, ALM Octane aggregates the data in
different quality analysis graphs.
To view graphs of application-specific quality:

1. In the application module tree, select the relevant node.
2. Click Overview.
3. Add relevant graphs, including:
l Open defects by application module
l Run status by application module
Identify application modules affected by recent development

Even after you release your application, track quality while you continue development. ALM
Octane helps you find application modules affected by recent activity.
To find application modules affected by recent work:

l Commits by application module dashboard widget.
Shows how many changes committed in your SCM system during a certain time frame are
associated with each application module.
Note: To use this widget, you must assign user stories and defects to application
modules. ALM Octane connects commits to application modules by reading the user
story or defect name in a commit's message.
l Application Modules widget in the Pipelines > Overview tab.

Lists the application modules currently associated with automated tests that failed in this
pipeline run. The widget shows how many of the tests assigned to the application module
failed.
Note: To use this widget, automated tests must be assigned to application modules. For
details on assigning items to application modules, see "Work with application modules"
on page 148.
l Application modules column in a pipeline run's Tests tab.

CI Pipelines
Add the column to the grid of Test Runs to see which application module is affected by each
test run. You can filter for failed test runs if you want to see which application modules are
associated with failing tests. See also "Analyze tests" on page 191.
Next steps:
CI Pipelines
Pipelines in ALM Octane represent the jobs or steps that run on your CI server. ALM Octane
incorporates data from your pipelines into your application delivery process, helping you analyze
quality, progress, change impact, code coverage and more.
In this topic:
l "What are pipelines?" below
l "How ALM Octane builds a pipeline's topology" on page 161
l "Displaying pipelines in ALM Octane" on page 161
What are pipelines?

After you set up ALM Octane to integrate with your continuous integration (CI) server, you can
create pipelines in ALM Octane.
Pipelines represent the flow of your CI server jobs. If you are working with Jenkins, Bamboo, or
GoCD, the graphical representation of the pipeline also shows the hierarchy of the jobs in the
flow.
When you run pipelines after adding them to ALM Octane, ALM Octane collects build, test run,
and commit information from the pipeline run.
Note: Creating, configuring, and deleting pipelines require workspace admin or DevOps
admin permissions in the relevant workspace.
Using pipelines in ALM Octane, you can:

Action Where? Comments
Collect pipeline run Pipelines View a summary of the pipeline run details, test run
and automated test > Pipelines tab statistics, a graphical representation of the pipeline
run results from the steps' flow, and more.
CI server.

CI Pipelines
Action Where? Comments

Configure test Inside a You can later filter the test run results based on this
properties and pipeline: data, in the Tests tab (Quality or Backlog module).
environment data on Topology tab
pipeline steps that
run automated tests.
Track and analyze Pipelines View a summary or breakdown of build results, as

build results. > Pipelines tab well as suggested reasons for failures and areas that
need attention. Assign failures to users for
Inside a
investigation, and use build failure classification to
pipeline run:
share investigation conclusions.
Builds tab
Include automated Dashboards Requires assigning automated tests to application

test run results in and Overviews modules (Settings > DevOps > Test Assignment
product and release throughout Rules) or backlog items.
quality analysis. ALM Octane
Track commits Pipelines Requires working with a CI server that integrates

associated with > Pipelines tab with an SCM system.
specific build runs
Team Backlog
and specific user
stories and defects. Inside stories
or pipeline runs
Additional
customization
in Settings >
DevOps page.
Track security issues Pipelines Requires working with a Jenkins server that
discovered in your > Pipelines tab integrates with Fortify on Demand.
code
Inside a
pipeline run:
Vulnerabilities
tab
Code Pipelines Requires integration with a Jenkins server with

coverage: Track how > Pipelines JaCoCo or LCOV code coverage reports.
much of your code is tab: Dashboard
covered by
Inside a
automated tests
pipeline: Runs
tab

CI Pipelines
How ALM Octane builds a pipeline's topology

When you add a pipeline, you specify a job on the CI server to use for the root of the pipeline.
ALM Octane then follows your pipeline structure, and builds a visual representation of the
pipeline.
l The pipeline's structure is dynamic. If additional jobs are added in the CI server after you
created the pipeline in ALM Octane, these steps are added the next time the pipeline runs.
l If the pipeline runs jobs that ALM Octane did not initially detect as part of the pipeline, they are
added to the pipeline during the run.
In both cases, the new steps are visible the next time you open the pipeline.
Tip: A step that no longer runs as part of the pipeline flow is not removed from the
pipeline.
If, over time, the pipeline structure displayed in the Topology tab is no longer helpful, click
. This instructs ALM Octane to redraw the topology based on the current pipeline steps
defined on your CI server.
Displaying pipelines in ALM Octane

In ALM Octane, in the Pipelines module, you can see all the pipelines that are being tracked, and
filter to see the ones that interest you.
After a pipeline runs ALM Octane displays information about the pipeline run status, its run
history, related code changes, affected application modules, and more. You can also find analytic
information about failed tests and tools to help you analyze the pipeline run results.
Next steps:
l "Set up CI servers" on page 403
l "Create and configure pipelines" on page 163
l "Analyze build quality using pipeline data" on page 286
l "Track changes committed to your Source Control Management system" on page 199
l "Track security vulnerabilities" on page 212
l "Track code coverage in pipeline runs" on page 214

CI Pipelines
DevOps CI server integration flow

This flow describes how to collect information from your CI server and use it in ALM Octane to
measure your release and product quality and to follow your build progress.
In this topic:
l "Overview" below
l "Collect data from your CI server" below
l "Connect the CI data to ALM Octane entities" below
l "Reflect the integrated data in ALM Octane's dashboards and grids" on the next page
Overview
ALM Octane integrates with your CI/CD processes, enabling you to:
l Collect data from your CI server.
l Connect the CI data to the application modules and backlog items defined in ALM Octane.
l Reflect the product quality based on the automated test run results in ALM Octane's
dashboards and grids.
Collect data from your CI server

Install and configure the ALM Octane CI plugin or the Application Automation Tools Jenkins
plugin on your CI server, and create pipelines in ALM Octane.
ALM Octane pipelines collect build and test run results, as well as SCM data and code coverage
reports from your CI server. For more detail on what you can do with pipelines, see "CI Pipelines"
on page 159.
Alternatively, use the Test Result Collection Tools to send your automated test run results to
ALM Octane. For details, see "Push results to ALM Octane" on page 273.
Based on the collected test run results, ALM Octane creates automated test and test run entities.
For details, see "Creating automated test entities" on page 268.
Connect the CI data to ALM Octane entities

Assign tests to application modules, backlog items, and ALM Octane users. You can assign items
manually or set up rules to automatically assign automated tests to specific application modules
and test owners. For details on application modules and the backlog tree, see "Work with
application modules" on page 148 and "Build the product backlog" on page 110.
The automated tests results are then incorporated into your product and release quality reports.

CI Pipelines
You can then use these results to analyze the quality of your product or release in ALM Octane in
dashboards and grids.
Note: We also recommend associating user stories and defects with features and
application modules. The association of SCM commits with features and application
modules is made via the user story or defect mentioned in a commit's message.
Reflect the integrated data in ALM Octane's dashboards and grids

After you create, configure, and run pipelines, ALM Octane reflects your build, product, and
release quality based on the collected information.
What can I do? Where

View graphs and charts that reflect your product In ALM Octane's Dashboard module, and
and release quality based on automated test run in Overview tabs in each module of ALM
results. Octane.
Use pre-defined widgets from ALM Octane's
widget gallery, or design your own.
Study your pipeline results, including code In ALM Octane's Pipelines module.
changes and failures they may be related to.
If available, you can also see code coverage
reports and newly discovered security
vulnerabilities.
Next steps:
l "Create and configure pipelines" below
l "Assign tests to application modules and backlog items" on page 270
l "Set up your SCM system" on page 413
l "Analysis and reporting" on page 282
Create and configure pipelines

ALM Octane pipelines represent the flow of your CI server jobs and steps. Use pipelines to get a
clear, multi-level, analytic view of your pipeline runs and their status. This helps monitor quality
and progress, quickly identifying and fixing issues as they occur.

CI Pipelines
To learn more about pipelines in ALM Octane before creating them, see "CI Pipelines" on
page 159.
In this topic:
l "Add a pipeline in ALM Octane" below
l "Customize your pipeline display" on page 166
l "Explore a pipeline's graphical representation" on page 166
l "Label and configure pipeline steps" on page 169
l "Filter pipeline steps " on page 174
l "Delete a pipeline" on page 174
l "Special pipeline types" on page 174
Note: If you are working with Jenkins: You can similarly create and configure pipelines
using the Application Automation Tools plugin on the Jenkins CI server. For details, see
the section on creating and configuring pipelines on the Application Automation Tools
wiki page.
Add a pipeline in ALM Octane

Once connected to a CI server, you can create a pipeline in ALM Octane. Specify the root job for
the pipeline, and ALM Octane builds a pipeline that represents the job flow starting from that root
job.
The result of a pipeline run is determined by the result of its root job. Therefore, for the pipeline
run result to reflect the results of other jobs in the flow, make sure that on your CI server, the
results of those jobs are aggregated up to the root job.
To add a pipeline in ALM Octane:

1. Prerequisites:
l Make sure an ALM Octane CI plugin is installed on the CI server.
For details, see "Install and configure the ALM Octane CI plugin on your CI server" on
page 406.
l Make sure at least one CI server exists in the Settings area. For details, see "Add CI servers
on ALM Octane" on page 405.
2. In ALM Octane, go to the Pipelines module and open the Pipelines tab.
3. Click + to add a pipeline.
4. Select a CI server. The list displays the servers created on the CI Servers settings page of the
current workspace.
5. Select the root job from which you want ALM Octane to start the pipeline. The list displays

CI Pipelines
the jobs defined on the CI server you selected. If the communication with the server fails, the
list will not be available.
6. Enter a name for the pipeline and, optionally, assign the pipeline to a release.
The release assigned to the pipeline is automatically assigned all test runs collected from this
pipeline. This lets you view the results in the context of a release and asses the release quality.
Tip: If you assign the pipeline to the Default Release, the pipeline will always be
associated with whichever release is currently set as the default release.
7. Specify the pipeline's type. Select one or more types from the list: Build, Test, Integration,
Deploy, Security.
l Most types are optional. This definition helps you remember the lifecycle stages that this
pipeline handles.
l You must select Security if you want this pipeline's runs to show security vulnerabilities
discovered by Fortify on Demand.

8. Connect the pipeline to Fortify on Demand (optional).
Specify whether This pipeline includes a Fortify on Demand job that uploads your code for
a security assessment.
If this option is selected, ALM Octane retrieves Fortify on Demand results and displays the
new vulnerabilities found for each pipeline run.
This option is available only if:
l You set the pipeline's Type to Security.
l You set up integration with Fortify on Demand. For more details, see "Set up security
testing integration" on page 427.

Enter the Application and Release that you used when configuring the Jenkins Fortify on
Demand Upload step. These details identify the application whose code Fortify on Demand is
scanning.
9. Set up notifications (optional). Instruct ALM Octane to send emails to relevant users when
builds or automated test runs fail.
l Notify committers upon run failure. Notify people whose commits were included in a
pipeline run that failed.
l Notify test owners if their tests fail. Notify people who are owners of failed automated
tests.
You can edit these options later in the pipeline's Details tab.
For more details, see "Track commits associated with a pipeline run" on page 201.
ALM Octane retrieves the information from the CI server and creates the pipeline. Click the pencil
next to pipeline's name or release to edit it.

CI Pipelines
After the pipeline runs, you can see a comprehensive overview of the run results. For details, see
"Run pipelines" on page 175.
Customize your pipeline display

If you have a large number of pipelines defined, it may be helpful to view less information at once.
In the Pipelines module, open the Pipelines tab and use the toolbar above the list of pipelines.
What do you want to do? How to do it

Filter the list of pipelines to display only Click the down arrow on the Select pipelines button
the ones you want to work with
and select the pipelines to display.
Select to display less information about Click to show more or less information
each pipeline in the list
about pipelines in the list itself.
Your selection is retained for future sessions as well.
Explore a pipeline's graphical representation

When you create a pipeline, ALM Octane creates a graphical representation of the pipeline steps,
starting from the root job of the pipeline.
If you are working with Jenkins, Bamboo, or GoCD, you can see the flow of the steps, including
which steps run in sequence and which steps run as parts of other steps.
Open the pipeline by clicking its ID and select the Topology tab.
Jenkins example

CI Pipelines
Note: The pipeline is initially built based on the structure ALM Octane discovers on the
CI server. When the pipeline runs on the CI server, ALM Octane adds any additional steps
it discovers during the run. You will see these steps the next time you open the pipeline.
Here are visual clues for understanding and working with the display as you explore the pipeline in
the Topology tab.
Visual clue Description
The pipeline's ID and name.
Click to view the pipeline in a Flat view or

Tree view.
Tree view. Displays the hierarchy and flow of
the pipeline.
Flat view. Displays the pipeline steps side by
side without describing the hierarchy or flow.
This view is useful for gaining an overview of
complex pipelines.
In this view, you can also filter pipeline steps.
For details, see "Filter pipeline steps " on
page 174.
A step in the pipeline.

Click the step's name to open the job on the
CI server.
For a pipeline that displays hierarchy, click to

expand and collapse the steps that run as
part of their parent step. (inner jobs)
Steps on the same side of a dotted line run in

parallel to each other. (parallel jobs)
Steps on the right side of a dotted line run
after the steps on its left side end. (sequential
jobs)

CI Pipelines
Visual clue Description

Steps that run as part of the pipeline.
In a pipeline that displays hierarchy, the steps
after this arrow run only after the calling step
and its children end. (sequential jobs)
Click to label the step type as Compile,

Package, Deploy, Security, or Test.
Click to configure step information, which is

added to the pipeline step as a tag. You can
use tags later, for example, for filtering test
run results.
You can specify:
l Test-related information: Framework, test
type, testing tool, and test level.
l The environment on which the step runs
(browser, operating system, database, and
so on). You can also define conditional
environment tags that are set according to
build parameter values when the step runs.
l A way to link to build reports created by
your build.
For details, see "Configure steps: Define test
and test run information" on page 171.
Click to instruct ALM Octane to redraw the

topology based on the current pipeline steps
defined on your CI server.
This is useful, for example, if you changed the
pipeline flow on the CI server a few times and
the pipeline structure in ALM Octane includes
steps that no longer belong in the flow.
When redrawing, ALM Octane attempts to
maintain the pipeline step configuration.
However, for steps that moved significantly,
the configuration may be lost.

CI Pipelines
Label and configure pipeline steps

Enhance the pipeline's usefulness in ALM Octane by labeling and configuring. This makes it easier
to understand the purpose of the steps and provides additional contextual information for test
run results.
Label steps according to job type

1. Open the pipeline by clicking its ID and select the Topology tab.
2. Click the label at the top right of a step, and select a job type for the step. The label helps you
understand the pipeline flow. In the flat pipeline view, you can also filter the pipeline to show
only steps with specific labels.
Job types include: Compile, Package, Deploy, Test, and Security.
When the pipeline runs, the labels are added to the resulting builds. When analyzing pipeline
run results in the Builds tab, the labels help you understand the context of the builds.
Configure steps: Ignore or hide results of specific steps

Your pipeline may include steps or tests whose results you do not want to track in ALM Octane.
You can instruct ALM Octane to ignore such steps or hide their results from the quality analysis.
In a pipeline's Topology tab, click the Configuration button on the bottom right of the step.
Then select one of the following options:
Ignore this step and the ones that follow it

Configure pipelines to ignore the status, duration, and test results of certain steps and those that
follow them.
For example, a pipeline might include post-build or downstream steps that you do not need to
track. If these steps are ignored, the pipeline run status and duration is updated without waiting
for them to finish running.
Hide failed builds when analyzing build failures

Sometimes, the failure of a specific step's build is not interesting when analyzing pipeline run
failures. For example, a parent step's failure is not interesting if it indicates only that the child step
failed.

CI Pipelines
Configure the pipeline step so its build failures are not included in the pipeline's Overview and
Builds tabs. This helps focus on the failures that matter.
To hide build failures resulting from specific steps:
In a pipeline's Topology tab In a pipeline run's Builds tab

Right-click a build that you want to hide and select
1. Click the Configuration button Hide builds from this pipeline step.
on the bottom right of the step.
2. Select Hide failed builds when
analyzing build failures.
Builds resulting from this step are hidden in all pipeline runs.
To unhide a step's build failures:
In the pipeline's Topology tab:
1. Click the Configuration button on the bottom right of the step.

2. Clear the Hide failed builds when analyzing build failures option.
Ignore test run results

If a step runs tests that you do not want to track in ALM Octane, select Ignore test run results.
When this step runs tests, the results are not sent to ALM Octane, and it does not create the
corresponding tests.
For example, we recommend that you use this option to ignore unit tests. This will prevent
unnecessary load on your ALM Octane, which could result in performance issues.
Specify whether to delete test run results that were previously collected from this step. If all of a
test's run results are subsequently deleted, the automated test is deleted as well.
Caution: Deleting test results will affect your pipeline's build run history. In addition, failure
analysis will not be available for steps whose test results are ignored.
In the pipeline's Topology tab, the pipeline step reflects the selected option. For example:

CI Pipelines
Configure steps: Define test and test run information

For pipeline steps that run tests, add environment and testing information about the step.
l Test Fields and Testing Environments. This adds tags to your pipeline step. When this pipeline
step runs tests, its tags are added to the tests, test runs, and builds. You can then filter builds
and test run results in ALM Octane according to these tags, and enhance your product and
release quality analysis.
Example: This Jenkins step, QA-Functional-Chrome, is labeled as a Test and has the
following tags configured:
l Test fields: Framework = TestNG, Test type = End to End, Test level = Integration
Testing, Testing tool: Selenium.
l Testing Environment: WinServer2012 (OS), MSSQL (DB), QA (AUT Env), Chrome
(Browser).
l Custom Build Report. If your build creates reports, ALM Octane can add a link to your report in
the relevant automated test runs. This report can be stored on your CI server or elsewhere, and
may help analyze test run failures.
Configure a URL or URL template for custom report links in your pipeline step. ALM Octane
adds the links to the test runs that are created as part of this pipeline step and to the build that
is the result of this step.
To configure a pipeline step:
1. Open the pipeline by clicking its ID and select the Topology tab.
2. Click the Configuration button on the bottom right of a pipeline step.

3. In the Test Fields tab, add information about the type of tests the step runs, and the tools
and framework it uses to run them.
Select from the predefined values:

CI Pipelines
Field Possible values
Framework Select from the list. Example: JUnit, TestNG, UFT.
Test type One of: Acceptance, End to End, Regression, Sanity, Security, Performance.
Testing Select from the list. Example: Manual Runner, Selenium, UFT, LeanFT, StormRunner Load,
tool StormRunner Functional, LoadRunner.
Test level Select from the list. Example: Integration Test, System Test, Unit Test.
You can add values to the Framework and Testing tool lists. To do this, add tags to the
pipeline step using the API, or the Jenkins plugin UI.
ALM Octane automatically sets the following fields for test runs discovered on Jenkins
pipelines:
Field Set for test results from
Testing UFT
tool LoadRunner
StormRunner Load
Performance Center
StormRunner Functional (requires version 5.3.3 or later of the Application Automation
Tools plugin)
Framework UFT
Test type Performance Center
If you manually added tags to the pipeline step that runs these test, your tags override the
automatic ones.
4. In the Testing Environment tab, add information about the environment on which the step
runs. For example, the operating system, browser, and database.
Environments are grouped by category. ALM Octane provides a list of environments out-of-
the-box. You can also define your own environments details, according to your project
developing model.
Do one of the following:
Use an existing environment Click the Environment box and select existing
environments.
Tip: Type in the box to search for a specific

value.

CI Pipelines
Add a custom environment a. Click the Environment box, type the name for the
new environment and select it in the list.
b. Select a Category for your new environment and
click OK.
Example:
l Add a Lab Machine category with tags for

each machine you use for nightly runs.
l Add environments for specific browser
versions or development branches.
Administrators and leaders can modify the list of

environments. For details, see "Environments" on
page 78.
Create conditions for setting In the table, add a row for each environment that you
environments during the build want to assign dynamically.
run, based on build parameter In each row, specify:
values
Parameter name + value ==> Environment
Select the build parameter name from the list of build
parameters available for this step.
Note:
If you use the Matrix plugin on Jenkins, the
pipeline displays child steps, generated during
the build run. Each one represents a set of
build parameter values.
Configure conditional environments on the

parent step. These are applied to the
generated child steps. You cannot modify a
child's configuration.
5. In the Custom Build Report tab, enter a URL or a URL template that ALM Octane can use to
create a link to reports generated for your builds.
If you include {JobName} and {BuildNum} placeholders in the template, ALM Octane replaces
them in the URL with the relevant job name and build number when creating the link.
For example:

CI Pipelines
http://myServer:myPort/jenkins/job/{JobName}/
{BuildNum}/reports/logs/jenkins-test-reports.html
ALM Octane adds the links to the test runs that are created as part of this pipeline step and
to the build that is the result of this step.
Filter pipeline steps

Filter a pipeline by label or job name, to display only pipeline steps with a certain label and/or steps
with a specific string in their name.
If you set up a filter on a specific pipeline, that filter is used again the next time you view the
pipeline.
Open the pipeline by clicking its ID and select the Topology tab.
In the pipeline flat view:
l Filter by label. Select from the labels on the right to specify the type of pipeline steps you want
to see.
l Filter by job name. Type in the context search box to see only steps whose name contains the
specified string.
If you filter by label and by job name, the pipeline displays only steps that match both filters.
Delete a pipeline
In the Pipelines > Pipelines page, click X in the toolbar on the left. The selected pipeline is deleted
(after confirmation).
If you delete a pipeline:
l All of the pipeline's labels and configuration information are lost.
l The pipeline runs and the automated test runs from this pipeline are deleted. The automated
test entities remain.
Special pipeline types
Pipeline as Code
Pipeline stages are shown in the ALM Octane pipeline topology. Tests and commits are linked to
the root jobs, as they are in Jenkins. Note that you cannot add tags to stages because tests are
linked to the root job.

CI Pipelines
Pipeline Multibranch plugin

If you are working with the Pipeline Multibranch plugin, ALM Octane automatically creates a
corresponding pipeline whenever a new branch is pushed to a source code repository and built for
the first time. Multibranch support requires Jenkins 2.7 or later, Git 3.8.0 or later, and Pipeline
Multibranch Plugin 2.16 or later.
For example, suppose you have a pipeline in ALM Octane for your master branch, and you create
a branch off the master in GIT and run tests on the custom branch. In this case, ALM Octane
automatically adds a branch pipeline to the master pipeline, and shows your tests on the branch
pipeline. If you merge your branch and delete it, ALM Octane automatically deletes the related
pipeline.
To filter which branches will be created, click the master pipeline in ALM Octane and select the
Filter by branch menu action. Use the filtering options to define which branches will be shown in
ALM Octane. Note that the filtering is not retroactive.
Next steps:
l "Run pipelines" below
l "Work with application modules" on page 148
Run pipelines
After creating and configuring pipelines in ALM Octane, run the pipelines on your CI server. You
can then view and analyze the pipeline run results, and begin tracking your build quality.
In this topic:
l "What happens when a pipeline runs?" below
l "Trigger a pipeline run from ALM Octane (Optional)" on the next page
What happens when a pipeline runs?

When a pipeline runs, the following occurs:
l ALM Octane collects the results of the pipeline step runs. These are the builds that comprise
the run.
The pipeline run's number is the build number of the root step in the pipeline.
The pipeline run's status is determined by the result of the root job. Therefore, for the pipeline
run status to reflect the results of other jobs in the flow, make sure that on your CI server, the
results of those jobs are aggregated up to the root job.
l ALM Octane collects the results of the automated tests that run as part of the pipeline. ALM

CI Pipelines
Octane creates automated test and test run entities associated with the test run results it
collects. If a relevant automated test already exists, the results are associated with that test. For
more details, see "Creating automated test entities" on page 268.
View the automated tests alongside the manual tests in ALM Octane. View the test run results
when tracking the quality of your products and releases.
l ALM Octane collects any available SCM commit information.
l If you set up security testing integration, a pipeline run triggers a security assessment of your
application's code, and ALM Octane displays the newly found vulnerabilities in the pipeline run.
This enables you to quickly identify and correct security vulnerabilities introduced into the
code.
For details, see "Set up security testing integration" on page 427
l If you set up code coverage tracking, your JaCoCo and LCOV reports are sent from Jenkins to
ALM Octane. For details, see "Track code coverage in pipeline runs" on page 214.
l After the pipeline run ends, ALM Octane displays detailed information about the pipeline
status, the status of the pipeline's builds and test runs, commits that may be related to failed
test runs, code coverage information, and more.
This information helps you analyze the quality and status of your build, product, and release.
Trigger a pipeline run from ALM Octane (Optional)

1. In the ALM Octane Pipelines module, open the Pipelines tab and select a pipeline in the left
pane.
2. From the pipeline's menu options, select Run.
ALM Octane triggers the CI server to run the pipeline's root job.
On all CI servers besides TeamCity, the pipeline steps run under the CI Server user, or TFS PAT
that you specified when configuring the ALM Octane CI plugin on the CI server. The pipeline run
is limited by the permissions assigned to this user.
Next steps:
l "View and analyze the pipeline overview" below
l "Analyze builds" on page 186
l "Analyze tests" on page 191
View and analyze the pipeline overview

After a pipeline runs, ALM Octane displays information about the pipeline run status, its run
history, related code changes, affected application modules, and more. You can also find analytic

CI Pipelines
information about failed tests and tools to help you analyze pipeline run results.
In this topic:
l "View pipeline run results " below
l "Analyze pipeline run results" on page 180
l "Additional information on pipeline overview widgets" on page 181
l "Track code changes" on page 182
l "View and share a live summary of your pipelines" on page 182
l "Failure Analysis Insight cards" on page 183
View pipeline run results

In ALM Octane, go to the Pipelines module and click Pipelines.
Tip: You can filter the list to see only the pipeline that interest you. See "Customize your
pipeline display" on page 166.
Use the options below to track and analyze the quality of your build.
Check the pipeline status (in the list of pipelines on the left)
For each pipeline that ran after it was added to ALM Octane, you can see details about the last
pipeline run. The expanded view shows the run number, date, status, and duration.
You can also see the status of automated tests that ran as part of the build. The pipeline run
results are aggregated (combined) at the highest level, the pipeline root.
A progress bar above the pipeline box indicates that a new run of the pipeline is
currently in progress. The color of the progress bar indicates the status of the previous run.
l The estimated percentage of completion in the progress bar is based on the duration of
previous runs, if available. Otherwise, a striped bar is displayed.
l Hover over the progress bar to see which pipeline step is currently running.
l Pipeline run results are updated automatically when the run is finished.
Example:
A pipeline fails on the CI server. This pipeline runs 255 automated tests. Of these tests,
252 passed, 2 failed, and 1 was skipped.
A new run of this pipeline is in progress, currently running the QA-Provision-Env step.

CI Pipelines
Tip: Click the number of test runs to open the tests in the Quality module. The total
number of tests may be different than the number of test runs, as the same test may run
more than once in a pipeline.
To filter the list of pipelines, click the filter icon and select a release.
Overview tab: Get a quick comprehensive view of your pipeline's latest run

Use the Pipelines > Pipelines tab to quickly review the overall status and trend of your pipeline
run, see a break down of pipeline runs by status and duration, and gain insights into what might
be causing failures.
Select a pipeline from the list of pipelines in the left pane to see its overview data on the right.
What's in this view?

l In the upper section you can see the most critical problem that ALM Octane identified as the
source of the pipeline failure: Compilation Issue, Environment Issue, or Quality Issue.
l You can modify the pipeline's name (on top) or release (bottom right, click the pencil to edit).

CI Pipelines
If you modify a pipeline's release, future pipeline runs are associated with this release. Existing
runs are not modified.
l Click Builds to open the latest run's Builds tab and further investigate build failures. For details,
see "Analyze builds" on page 186.
l Click Tests to open the latest run's Tests tab and further investigate problems and analyze the
run results. For details, see "Analyze tests" on page 191.
l A recent pipeline history timeline shows the status (by color) and duration (by size) of each
run.
Hover over a specific column in the timeline to see detailed information about that run.
Click on a column to open a run and investigate it.

l The Failure Analysis Insights cards show you the most critical problems in the selected pipeline
so you know what to fix first. ALM Octane analyzes information regarding failed tests,
problematic tests, build failure classification, related committers, and more. This data is then
used to give CI owners actionable information, to fix failed pipelines quickly. For details, see
"Failure Analysis Insight cards" on page 183, below.
l The Dashboard shows summary information about the selected pipeline's latest or most recent
pipeline runs. By default, the dashboard shows how many failed tests and builds are currently
being investigated, which tests are problematic, and which application areas are affected.
For more details about the Application Modules with Failed Test Runs and Failed Builds
widgets, see "Additional information on pipeline overview widgets" on page 181, below.
Press + to add other widgets from the DevOps & Analytics widget gallery or create your own
widgets.
For example, you could add widgets that show code coverage per package and file, as well as
code coverage trends over time, based on code coverage reports from Jenkins. For details, see
"Track code coverage in pipeline runs" on page 214.
Tip: To remove a widget, click the widget menu button in the right corner of the widget,
and select Remove.
l The panel on the right shows details about the selected pipeline's latest run: Time, duration,
release, how many commits were included in this run, which application modules were affected,
and so on.

CI Pipelines
If the pipeline is set up to collect Fortify on Demand security testing results, then when the scan
is complete, you can see how many new vulnerabilities were found in the scan triggered by the
latest pipeline run. Click the number to open the Vulnerabilities tab for that pipeline run. For
details, see "Track security vulnerabilities" on page 212.
Drill down into the pipeline for more information

Click the pipeline's ID to open a pipeline and view more details about the pipeline and its runs:
l The Details tab displays information about the pipeline's definitions, as well as the Pipeline run
success rate and Average success duration. These are based on all pipeline runs, since the
pipeline was created.
l The Follow button enables you to receive notifications in email and in MyWork, according to
your preferences. You can receive notifications if your commit was involved in a failed run, if
your test fails, or if the pipeline run fails.
l In the Runs tab, you can see a list of all the pipeline runs, dating back to when you added the
pipeline to ALM Octane.
For each run, you can see its status, duration, and more.
Learn more about a specific pipeline run

Open a specific pipeline run to view more details and to analyze test failures.
1. In the Pipelines module, open the Pipelines tab and select a pipeline.
2. Open a specific pipeline run:
l To open the last run, click the pipeline's Run number.
l To open a previous run, click the pipeline's ID to open the pipeline. In the Runs tab, click
the ID of a specific run.

In the Details tab, you can see an overview of the pipeline run information. Time, status, number
of changed files included in commits on this run, pipeline run history and more.
l Add tags to label the run. The tags are displayed in the pipeline's list of runs, and can be used to
group pipeline runs in dashboard widgets.
l Click the build number to open the specific run on the CI server.
l "Track code changes" on page 182 using the Commits and Backlog Items tabs.
l "Analyze pipeline run results" below using the Builds and Tests tabs.
Analyze pipeline run results

In a specific pipeline run, use the Builds and Tests tabs to learn more about builds and automated
tests that were part of this run.

CI Pipelines
You can see how many of your tests ran successfully, how many were skipped or unstable, and
how many failed. You can find the reasons that tests are failing.
For details, see "Analyze builds" on page 186 and "Analyze tests" on page 191.
Additional information on pipeline overview widgets

l Application modules with failed test runs:
See which application modules have the most failing tests.
Lists the application modules currently associated with automated tests that failed in this
pipeline run. The widget shows how many of the tests assigned to the application module
failed.
Note: To use this widget, automated tests must be assigned to application modules. For
details on assigning items to application modules, see "Work with application modules"
on page 148.
l Failed builds classification:

Displays the number of failed builds included in this pipeline run, broken down by type of
failure. You can also see how many of the failures are currently assigned to someone for
investigation.

CI Pipelines
To use this widget, failed builds must be classified in the Builds tab. Classification can be done
automatically by ALM Octane, or manually, based on your own failure analysis. For details, see
"Analyze builds" on page 186.
Tip: Some builds might not be included.
DevOps admins can configure hiding builds failures resulting from specific pipeline steps.
For details, see "Configure steps: Ignore or hide results of specific steps" on page 169.
To check whether a step's builds are hidden, look at the step in the pipeline's Topology
tab:
Track code changes

If your CI server is set up to work with an SCM system, open a pipeline run to see commit changes
and backlog items associated with that run.
Based on the SCM data, ALM Octane helps you analyze the effects of the changes on your
product, and identify Hotspots in your code. Hotspots are sensitive areas of code that are risky to
change.
For details, see "Track changes committed to your Source Control Management system" on
page 199.
View and share a live summary of your pipelines

In the Pipelines module, click Live Summary to see a summary of your pipeline runs. If you have
multiple pipelines running, you can click Choose Pipelines to view a subset of them, or to search
for a specific one.
The summary provides information about the pipeline's history, its status, and progress. You can
see:
l The status of the last few runs.
l What triggered the last run (system or commit).
l If triggered by a commit, you can see who committed and what files changed.

CI Pipelines
l The progress of the current run.

l After the tests are completed, an aggregated summary of the test run results.
This view is suitable, for example, for displaying on a group plasma screen. This enables the whole
group to view the overall build status and quality.
Note: This information is obtained from the CI server and may include information from
runs that occurred before the pipeline was added to ALM Octane.
Failure Analysis Insight cards

ALM Octane analyzes information regarding failed tests, problematic tests, build failure
classification, related committers, and more. The Failure Analysis Insights cards give CI owners
actionable information to fix failed pipelines quickly.
ALM Octane categorizes pipeline failures into three types: Compilation, Environment, or Quality
issues. The cards for each of these are displayed in order of urgency. Each card shows you the
problem and its root cause, the users directly related to the problem, and the percentage of issues
being handled. This information tells you if a problem needs immediate attention and whom to
contact in order to deal with it.
Click the right and left arrows to navigate between the cards.
Note: To provide data for Failure Analysis Insights, you need to manually classify failed
builds. For details, see "Build failure classification" on page 187.
Compilation Issues
Compilation issues include any failure with at least one build which failed due to compilation
issues. Related users includes anyone who may have caused the issue (generally committers in the
pipeline run), as well as anyone assigned in the compilation build's Who's on it field.

CI Pipelines
For each build that was classified as a compilation issue, the card shows if it failed in an earlier run,
so you know when the failure started. The bottom of the card indicates the percentage of builds
that have someone assigned in the Who's on it? field, indicating that the problem is being
handled.
You can click on the number of builds, or on a specific build name, to drill to the relevant details.
Environment Issues
Environment Issues include any build failures classified as Environment issues. The cards are
divided into subgroups based on the out-of-the-box tags (such as Environment - Database, and
Environment - Network), or custom tags you added. Each card shows all the problematic jobs in
the relevant category, with the oldest jobs listed first.
Related users includes anyone assigned in the relevant builds' Who's on it? field. The bottom of
the card indicates the percentage of builds that have someone assigned in the Who's on it? field.
You can click on the number of builds, or on a specific build name, to drill to the relevant details.
Quality Issues
If any tests failed in a pipeline run, and the build is not classified as a compilation or environment
issue, you will see a Quality Issue card. The cards are divided into two types: Quality - Builds with
most failed tests, and Quality - Committers related to most test failures.

CI Pipelines
Tip: Admins can define a percentage threshold that determines which test failures are
displayed on the card. For details, see the FAILURE_ANALYSIS_INSIGHT_TEST_
FAILURE_THRESHOLD configuration parameter under "FAILURE_ANALYSIS_INSIGHT_
TEST_FAILURE_THRESHOLD" on page 487.
You want to focus your attention on test failures that are stable and indicate a regression that
needs to be fixed quickly. The Quality - Builds with most failed tests card therefore shows you
the number of test failures that are stable, out of the total test failures. These are either tests that
are failing consistently or failed for the first time in this run.
Related users include any committers who may have caused the issue or anyone assigned in the
test runs' Who's on it? field. The bottom of the card indicates the percentage of tests in these
builds that have someone assigned in the Who's on it field.
You can click on the number of builds, or on a specific build name, to drill to the details of stable
test failures.
The Quality - Committers related to most test failures card shows you which committers are
related to the most test failures. Committers are listed in order of the number of stable test
failures that they impacted, so you know whom to contact to resolve problems.
The bottom of the card indicates the percentage of tests that are being handled, regardless of
who is handling them.
You can click on a line showing a number of tests to drill to the details on test failures related to
the selected committer.

CI Pipelines
See also:
l "Analyze builds" below
l "Identify problematic tests" on page 205
Analyze builds
The Builds tab lists all of the builds that ran as part of a pipeline run. The following section
describes how to use the build log and build failure classification to pinpoint the source of build
failures.
In this topic:
l "Build details" below
l "Build failure classification" on the next page
l "Classify build failures manually" on page 188
l "Create rules to classify build failures automatically" on page 189
l "Edit or delete classification rules" on page 190
Build details
Each build in the Pipelines > Builds tab is the result of a specific pipeline step. For each build you
can see the build's status, number, and duration, the build run history , the percentage
of failed tests in this build that are being handled , and so on.
Each build includes a link to the build log (also known as console log) on the CI server. If you are
working with a Jenkins server, expand the build's row to see the build log link. This is a local copy

CI Pipelines
of the build log, in which you can add rules that map specific log messages to build failure
classifications. For details, see "Create rules to classify build failures automatically" on page 189.
If configured, a custom report link to a build report stored externally is also available. For details
on configuring custom build report links, see "Label and configure pipeline steps" on page 169.
Set the Who's on it? field to assign someone to investigate a failed build, as described in the
section "Assign someone to investigate failures" on page 194. This is useful in case the build failed
for reasons that are not related to a specific test. For example, the environment may need
attention, or the build may have failed during compilation. For details, see "Build failure
classification" below below.
You can navigate between runs to help troubleshoot problems, using the Run selector in the
upper right corner. Note that the Overview tab will always show the latest run.
Tip: Some builds might not be included.
DevOps admins can configure hiding builds failures resulting from specific pipeline steps.
For details, see "Configure steps: Ignore or hide results of specific steps" on page 169.
To check whether a step's builds are hidden, look at the step in the pipeline's Topology
tab:
Build failure classification

A build failure classification label on a failed build indicates the type of issue that caused the
failure. For example, Test code issue, Code issue, and Environment issues.
Use the build failure classification to determine who needs to handle the pipeline run failures and
what issues need to be addressed.
You can classify builds manually to document the result of an investigation. For Jenkins builds,
you can create rules that enable ALM Octane to automatically classify your builds based on the
build logs. For details, see "Create rules to classify build failures automatically" on page 189.

CI Pipelines
The build failure classification is also presented at the pipeline run level. You can see the number
of failed builds in this pipeline run, broken down by type of failure.
To view only build failures with a specific build failure classification, add a cross-filter using the
CI build. Build fail classification field:
To understand what are the most common reasons for your build failures over time, add the
Pipeline build failure classifications over time widget to your pipeline's dashboard. Hover over a
specific run to see its classification details. Use this widget to determine whether your network or
database is causing a lot of problems, tests are changing too often, code errors are being
introduced and so on.
Tip: By default, this widget is set to show builds from the past week and to hide
Unclassified builds if there are any classified builds.
Classify build failures manually

After you investigate a build failure and know what caused it, use the Build Failure Classification
button to label the failed build. This helps you share the results of your investigation and keep
track of them for future analysis.
To add, replace, or clear the classification label:
1. In a pipeline run, open the Builds tab.

2. Select one or more failed builds.
3. Click the Build Failure Classification toolbar button.
If you have DevOps Admin permissions, you can add new classification labels to the list.
4. Select a classification label from the drop-down list.
If the build was previously classified automatically, your manual classification overrides the
automatic one.
Tip: To clear the classification label, click Clear

CI Pipelines
Create rules to classify build failures automatically

For Jenkins builds, you can create rules that enable ALM Octane to automatically classify your
builds based on Jenkins build logs.
Open a build log file and create rules that map log messages to the failures they indicate:
2. Expand a build and click build log.
3. In the build log, select a log message to classify.
4. Click + to add a rule.
5. Give the rule a meaningful name, such as Illegal Number.
6. The Rule pattern contains the text from the selected log line.
Modify the Rule pattern to identify the log lines you want to map to a specific build failure
classification.
Replace parts of the text with wildcards (*) and add a \ before special characters.
Example: *illegal number*
As you edit the pattern, the matching text in the Selected log line area is highlighted. You
can only save a rule if your pattern highlights the entire line.
7. Select a classification to assign to log lines that match the pattern.
Example: Environment - Other
Tip: Admins can add classification labels to the list using the manual Build Failure
Classification button.
8. Click OK.
The classification you specified is assigned to:

CI Pipelines
l The selected log line in the build log file

l All log lines that match the rule in future failed build logs.
If a line matches more than one rule, it is classified by the most recently updated rule.
All future failed builds are automatically labeled with the first classification mapped in their
log.
Edit or delete classification rules

When you open a Jenkins build log on ALM Octane, you can see any classification labels that were
applied by existing rules. If you are the author of the rule, you can modify or delete it.
A DevOps admin can see and modify all of the build failure classification rules in the ALM Octane
settings area. For details, see "Manage all build failure classification rules" on page 419.
To view and change rules in a build log file:

2. Expand a build and click Build log.
3. In the build log, hover over a specific line's classification label to see whose rule assigned that
label.
4. If you are the author of the rule, click Delete Rule or Edit Rule to make changes to the rule.
Otherwise, click the author to send him or her an email about modifying their rule.
Edit the rule's details as described in "Create rules to classify build failures automatically" on
the previous page.

CI Pipelines
What happens when I change a rule that is in use?

If you change a rule's classification, any log line already assigned by this rule is labeled with the
new classification.
This affects log files from previous builds, but does not affect the classification of any existing
builds. The change in the rule affects the classification of future builds only.
What happens when I delete a rule that is in use?

If you delete a rule that has already assigned a classification to a build log line, the classification is
removed from all log files, but remains on any builds is was assigned to.
See also:
l "View and analyze the pipeline overview" on page 176
l "Analyze tests" below
l "Manage all build failure classification rules" on page 419
Analyze tests
In a specific pipeline run, use the Tests tab to learn more about automated tests that were part of
the run. The following section describes how to use the tests analysis tools to pinpoint the source
of tests failures.
In this topic:
l "Overview" below
l "Prerequisites" on the next page
l "Test run details" on the next page
l "Assign someone to investigate failures" on page 194
l "Best practice: Involve committers in pipeline failure analysis" on page 195
l "Expand your test failure analysis" on page 196
Overview
In the Pipelines > Tests tab, you can see how many of your tests ran successfully, how many were
skipped or unstable, and how many failed.
You can learn more about the failures, what may have caused them, and what application modules
they affect.
After analyzing failures, you might decide to edit an automated test, roll back a committed
change, create a defect for an area in your application, or even extend you project's timeline or

CI Pipelines
reduce the planned content.

In the Tests tab, you can do the following and more:
l Filter the display to include only the test runs that interest you.
l Find SCM commits related to failing test runs.
l Make sure all failures are being investigated by specific users (Who's on it? field).
l Hold committers accountable for the effects of their changes (Related users widget).
l Identify problematic test runs, which have not been consistently successful over time.
To open the Tests tab:

1. Open the Pipelines module and select the Pipelines tab.
2. Select a pipeline from the list on the left.
l Open the Tests tab of the latest pipeline run.
l To open a previous run, click its column in the Recent Pipeline History widget, and select
the Tests tab.
Prerequisites
To benefit from all of the analysis abilities ALM Octane offers, you must:
l Use commit messages to associate SCM changes with ALM Octane stories. For details, see
"Track changes committed to your Source Control Management system" on page 199.
Test run details

The Tests tab lists all of the test runs that ran as part of this pipeline run.
For each run you can find information such as:

l Test name, class, and package.
l The build number in which the test ran.
l The ID and name of the build job that ran the test.
l The number of builds for which the test run has been failing consecutively.
Tip: If a test has been failing consecutively, it is probably better to analyze its first
failure. To navigate to that failure, right-click on the test and select Go to pipeline run

CI Pipelines
where the test first failed.
l The test run history, in the Past status column . The tallest column represents the run
you are currently looking at.
l Any tags you added to the test or test run in ALM Octane.
Add columns to the grid to see information that is not displayed by default.
You can navigate between runs to help troubleshoot problems, using the Run selector in the
upper right corner. Note that the Overview tab will always show the latest run.
Filter the display to include only the test runs that interest you
Use the Filter panel on the right to quickly focus on specific issues that are of interest to you, such
as failed test runs or regression problems.
You can also use the toolbar filter options as follows:
What can I do? How?

Separately address unstable, skipped, or failed test runs. Filter by Status.
View only runs of tests that you own. Click My tests.
View test runs whose failures are related to changes Filter the test runs by Related
committed by selected users. committers.
Separate newly failing tests from ones that failed in previous Filter by New Failure.
pipeline runs as well.
Tip: Click Show filter pane to see which properties are included in the filter. This helps
you understand which failures are being displayed and which are hidden.
Use clustering to analyze test run failures

Group test runs by cluster to group together failed test runs that failed for a similar reason. ALM
Octane clusters failed test runs as similar failures based on test package hierarchy, stack trace,
exception, the job that ran the test, and the run in which the test started failing.
l The number of clusters gives an idea of the number of problems that need fixing. This is a
better indication than the number of failed test runs.
l When analyzing failing tests in your pipeline run, start with the large clusters. Fixing one failed
run in this cluster is likely to fix all failures in the cluster and significantly reduce the number of

CI Pipelines
failures in the next run.
Note:
l Admins can define the number of tests to be used as a threshold for test clustering
analysis using the CLUSTERING_MAX_TESTS_THRESHOLD site configuration
parameter. If the number of test failures specified in this parameter is exceeded
during a pipeline run, ALM Octane does not analyze clustering. For details, see
"CLUSTERING_MAX_TESTS_THRESHOLD" on page 484.
l In each pipeline run, clusters are named C1, C2, and so on, according to cluster size
(Cluster C1 has the largest number of failed test runs). Test runs from different
pipeline runs with the same cluster name, are not related to each other.
l When assigning a failed run to someone for handling, you can assign all of the failures in the
same cluster to the same person.
For more details on analyzing failures in the Test Runs tab, see "Expand your test failure analysis"
on page 196.
Assign someone to investigate failures

Users can assign themselves or others to investigate a build or test run failure. ALM Octane
provides information about each failure to help the investigation.
If you assign someone to a pipeline step's latest build or a test's latest run, the assignment remains
on subsequent failures. The assignment is cleared automatically when the build or test run passes
successfully.
To assign a user to investigate a failure

In the Builds or Test Runs tab, select one or more failed builds or failed test runs and do one of
the following:
What can I do? How?

Assign yourself to the selected Click
builds or test runs. I'm on it

CI Pipelines
What can I do? How?

Assign someone else to the
selected builds or test runs. Click Who's on it? and select a user. At the top of
the list, ALM Octane suggests recommended users based
on their recent commits, areas of expertise, or previous
activity.
Select whether to send an email to that user.
If you add a comment (test run only), it's included in the
email.
Clear the user from Who's on it? Click and then click .
Who's on it? Clear Assignment
Indicate that you completed your Click Not me in the upper right corner, near the Run
investigation and are not related number.
to any of the failures in the
This clears any Who's on it? assignment you had on any
pipeline run.
failed builds or test runs in this pipeline run.
Note that Not Me is available in the Builds and Tests tabs
on the main Pipeline landing page, but not in the Pipeline
run form.
Tip: When assigning someone to investigate a test run failure, ALM Octane lets you
choose to assign the same person to all of the test runs that failed for a similar reason.
Best practice: Involve committers in pipeline failure analysis

When a pipeline fails, you want someone to investigate as soon as possible, and get the pipeline
back on track.
If your pipeline is configured to send pipeline failure notifications to all committers, you can
require all committers to respond.
l Each committer must open the Tests page, and use the information available there to
determine whether their change caused the failure.
l The CI owner should check as well, in case the failures are caused by an environment issue he or
she is responsible for.
A user can respond with I'm on it for each relevant build or test run failure, or with Not me for the
entire pipeline run.

CI Pipelines
Tip: If, as a user, you think you might be responsible for a failure or able to fix it, click I'm
on it . You can clear the Who's on it? assignment or set Not me for the pipeline run if
after further investigation you decide it's not your issue to fix after all.
Expand your test failure analysis

Select a test run failure and use the data in the right panel to investigate the failure.
Check the build context of the test run in the Preview tab
For example:
l Next Runs. When investigating a failure of a test run that is not from latest pipeline run, a quick
glance shows the test run status from the following pipeline runs . Tooltips
on each run show pipeline run number and date.
If a subsequent run passed successfully, you probably do not need to invest more in this
investigation.
Note: This is different from the widget on the test run itself, which displays the status of
past runs .
l Build . Displays the overall status of tests in this build. This provides a build context for you,
while you are looking at a specific test run. For example, if most tests in the build are failing, the
issue may be at the build level, and there is no need to analyze this specific failure.
l Cluster: The number of additional tests that failed for the same reason. Click to view all similar
failed runs together and handle them in bulk.
View error data from the failure, such as error message and stack trace, in
the Report tab.
In the stack trace, you may see highlighted file names. These files may be related to the failure, as
they contain changes committed in this build.
If available, view more detailed reports:
l Click Testing tool report to open an external report with more details about the failure, from
UFT or StormRunner Load, for example.
l Click Custom build report to open a build report stored on your CI server or elsewhere. This link

CI Pipelines
is provided if a DevOps admin configured a template for such links on the pipeline step. For
details, see "Label and configure pipeline steps" on page 169.
View commits related to your pipeline run and to test failures

The Commits tab in the right panel displays details about committed changes related to this
failure. Commits most closely related to the failure are listed first.
Each commit includes a reason which explains why ALM Octane considers it related to the failure
(for example, error in stacktrace). A tooltip on the reason indicates the degree of confidence in
this association, so that the more ALM Octane is confident that the commit is related to the
failure, the higher the percentage displayed in the tooltip. Commits with a higher degree of
confidence are displayed higher on the list than those with lower confidence.
Tip: A dotted line around a committer indicates that the related commit is from a previous
build.
The following table explains why ALM Octane would highlight a specific commit:
Change in test When a test is unstable, ALM Octane shows the last commit that changed
file before test the test file before it became unstable. This commit is likely to be related to
became the initial failure that caused the current instability.
unstable
Error in The commit includes changes to files listed in the current failure's stack
stacktrace trace.
Historical The commit includes changes to files listed in the stack trace of a previous
association failed run.
Related files The commit includes changes to a file which has previously been linked to
this test, by analyzing committers and Who's on it history.
Whenever a committer is manually assigned as on it for a test failure, a
relation is built between their committed files to the test. This is then used
to identify related commits for new failures.
Same The commit is related to an application module that is assigned to the test.
application
Commits are related to application modules via the stories mentioned in
module
the commit message, and the features that those stories belong to.
Same feature The commit is related to a feature that is assigned to the test.
Commits are related to features via the stories mentioned in the commit
message.

CI Pipelines
If this test has been failing consecutively, related commits include commits from this pipeline run
and from the pipeline run in which the test started failing. For commits from a previous build, the
build number is displayed.
You can filter the commits in this view:
l All commits (this pipeline run). All of the commits, not only the ones ALM Octane related to
the selected test run failures.
l My commits (this pipeline run). All of your commits, not only the ones related to the selected
test failures.
l Related commits (previous runs too) only commits related to the selected test run failures.
A risk icon indicates that a commit includes changes to hotspot files. For details, see "Identify
risky commits and features at risk" on page 210.
Create a defect
If you are looking at a pipeline's latest run, you can create a defect related to one or more of the
failed test runs:
Select the relevant rows in the grid and click Report Defect.
The new defect is linked to the runs you selected and contains a link to this pipeline run's Tests
tab.
Add additional columns to the grid of failed test runs

For example:
Add this
column to...
Pipeline links navigate to the pipeline and to a particular run of the pipeline.
Application see which application modules are currently associated to the tests that failed.
modules
Problem see whether the test has a history of unsuccessful runs. For details, see
"Identify problematic tests" on page 205.
Who's on it? see who's investigating this failed run.
Linked see defects that are linked to the failed run.

defects

CI Pipelines
See also:
l "Analyze automated test run results" on page 278
Track changes committed to your Source Control

Management system
If your CI server is set up to work with a Source Control Management (SCM) system, such as Git or
Subversion (SVN), ALM Octane can help you track committed changes. See also "Source Code
Management (SCM) integrations" on page 299.
In this topic:
l "Overview" below
l "Use cases for tracking commits " on the next page
l "Prerequisites" on page 201
l "Track commits associated with a pipeline run" on page 201
l "Track commits associated with backlog items" on page 202
l "Use the Commits tab to track committed changes" on page 202
l "Use the dashboard to analyze your commit activity" on page 204
l "In the Tests tab, find commits related to failures" on page 204
l "Map SCM users to ALM Octane users" on page 204
l "Troubleshooting" on page 205
Overview
ALM Octane pipelines display the commits associated with each run of the pipeline.
In your SCM system, use commit messages to associate changes with specific ALM Octane
backlog items (user stories, quality stories, or defects).
In ALM Octane, you can now track the committed changes and their affect on release and build
quality. You can view the following information in ALM Octane:
l In pipelines:
In a pipeline run, the list of backlog items and commits associated with the pipeline run.
In a pipeline overview, the number of committers and commits included in the pipeline's latest
run.
In a pipeline run's analysis, the commits that are related to failed automated test runs.

CI Pipelines
l In the backlog:
Inside a backlog item, the list of commits related to the item.
Inside an epic or feature, the list of commits associated with backlog items defined under the
epic or feature.
l In the Team Backlog module, the list of commits committed by the members of the selected
team.
The risk indicator near commits or features indicates changes committed in sensitive areas of
code.
Note: When working with GoCD, ALM Octane displays commits and their associations with
ALM Octane entities. The list of files included in each commit is not available.
Use cases for tracking commits

Here are a few ways that you can use commit tracking information:
l As a developer, when you commit a change to your SCM system, enter a commit message with
the ID of the defect, user story, or quality story related to this change.
When the pipeline associated with your change runs, this information is passed to ALM Octane.
When you open the backlog items in ALM Octane, you and your team leader get a clear picture
of the files that you changed for each backlog item you worked on.
l As a development team leader, view the team members' commits and how they relate to the
items in the team backlog.
l As a developer or DevOps engineer, match build failures to specific changed files and specific
backlog items.
l As a tester, after verifying that a pipeline run was successful and automated tests passed,
determine the areas that contain significant changes and require manual testing.
l As a developer, identify sensitive areas in your code, which are risky to change. You may want
to simplify and refactor the code and increase testing around the functionality it covers. This
should reduce the risk of future changes causing quality issues. For details, see "Identify
hotspots in your code" on page 207.
l As a developer or Dev tester, identify commits that seem to be related to failing automated
tests. You can also see which commits are riskier than others because they affect hotspot
files.
l As a project manager or PMO, identify features with risky commits and consider increasing
testing on these features, or postponing their release.

CI Pipelines
Prerequisites
l Make sure the workspace admin or DevOps admin has created a pipeline on a CI server that
works with an SCM system. For details, see "Create and configure pipelines" on page 163.
l If you want to associate changes with ALM Octane backlog items, include the ID of the related
ALM Octane backlog item in your commit message.
When committing a change to your SCM system, the commit message should include one of the
Commit message patterns defined on the DevOps > Commit Patterns settings page. A
workspace admin can modify the default commit message patterns using Java regular
expressions. For details, see "Customize commit message patterns" on page 414.
The default commit message patterns are:
defect #<defect id>
user story #<user story id>
quality story #<quality story id>
The message syntax is not case sensitive.
You can also associate your commit with multiple backlog items, like in these examples:
Defect #1001, User story #1002: I changed all of the blue icons to green ones.
Fixed the issue of screen not refreshing. Defect #1001, Defect #1002.
Track commits associated with a pipeline run

1. In the Pipelines module, open the Pipelines tab and select a pipeline.
2. Open a specific pipeline run:
l To open the last run, click the pipeline's Run number.
l To open a previous run, click the pipeline's ID to open the pipeline. In the Runs tab, click
the ID of a specific run.

You can find the following information, and more:
l In the Tests tab, view commits that seem to be related to failing automated tests. For details,
see "Analyze tests" on page 191.
l In the Commits tab, view the commits included in this pipeline run. For more details, see "Use
the Commits tab to track committed changes" on the next page.
l In the Backlog Items tab, view the defects, user stories, and quality stories associated with the
pipeline run's commits. To associate backlog items with a commit you must list the items in
commit messages using the correct syntax.
For each backlog item, you can see information about the item and the associated commit. For
example:
l The item's ID, name, and phase.
l The number of commits associated with the item.

CI Pipelines
l The names of the users who committed the changes.

l The number of files added, modified, or deleted by those commits.
Click a backlog item's ID if you want to open the item and view more details.
If the pipeline is configured to notify committers upon run failure, users receive an email if a
pipeline run that included their commits fails.
You can edit this option in the pipeline's Details tab.
Each user receives an email about their own commits. The email lists the commits, the failed builds,
and the failed tests (limited to a certain number of items). It also includes a link to the relevant
pipeline run's Tests tab.
Track commits associated with backlog items

To track commits associated with backlog items, do one of the following:
l Use the Commits tab in backlog items to find all commits related to specific backlog items. For
details, see "Use the Commits tab to track committed changes" below.
l Use dashboard widgets to track and analyze your SCM changes, and their impact on your
backlog. For details, see "Use the dashboard to analyze your commit activity" on page 204
Use the Commits tab to track committed changes

The Commits tab displays all changes that were associated with ALM Octane backlog items using
SCM commit messages in the correct syntax.
You can find the Commits tab inside a pipeline run or a backlog item, or in the Team Backlog
module.
Open the
Commits
To see ... tab in ... How ?
Commits associated with a pipeline run. A pipeline 1. Open the Pipelines module.
run. 2. Select a pipeline.
3. Click the pipeline's ID to open it.
4. In the Runs tab, click the ID of a
run.
Commits associated with a backlog item A defect, Click a backlog item's ID. For
via commit messages. user story, or example, in Backlog, Team Backlog,
quality story. Defects.

CI Pipelines
Open the
Commits
To see ... tab in ... How ?
Commits associated with backlog items An epic or a Click the ID of an epic or feature.
defined under an epic or feature. feature. For example, in Backlog or Quality
module.
Commits committed by the members of The Team In the Team Backlog, select the
a team, during the time frame of the Backlog. relevant team.
selected release and sprint.
Click a specific team member in the
Team pane on the right to see only
that person's commits.
In the Commits tab:

For each commit, you can see additional information, such as the name of the user who committed
it, the commit message (comment), and more.
1. Optionally, add columns to the grid to see more information. For example, the Risk column
displays a risk indicator if the commit includes a change to a sensitive area of code (a
hotspot).
The Repository column is only relevant if you are working with Git or SVN.
2. You can filter the information in this tab, for example, by the name of the user who
committed the change.
Tip: To filter by user, make sure your SCM users are mapped to ALM Octane users.
For details, see "Map SCM users to ALM Octane users" on the next page.
If you are the user who committed the change, but your SCM user is not yet mapped to your
ALM Octane user, click to create the mapping.
3. Select a specific commit. The list of files included in this commit is displayed on the right. If the
SCM system provides the information, ALM Octane differentiates between edited, added or
deleted files.
Note: If you have file names in Git that contain Unicode characters and you want to
see them in ALM Octane, update your Git configuration as follows:
git config --global core.quotePath false
4. For each changed file listed in a Commits pane, ALM Octane can provide HTTP links to the
file view and diff view in your repository viewer. To enable this, a workspace admin must

CI Pipelines
configure templates for the HTTP links. For details, see "Enable linking to your repository
viewer (Git or SVN only)" on page 413.
Use the dashboard to analyze your commit activity

Create custom widgets based on commits in the Dashboard or the Backlog Overview.
Alternatively, use the predefined widgets that ALM Octane provides in the Dashboard's DevOps &
Analytics category.
For example:
l Use the Impact of changes widgets to discover the impact of source code changes.
Discover which backlog items and application modules were worked on recently, and see the
number of commits related to each. This can also give you an idea of the areas that need to be
tested more thoroughly.
Note:
l The association of commits with features and application modules is made via the
user story or defect mentioned in a commit's message.
l By default, these widgets include commits made in the last 30 days. You can change
the time frame in the Scope tab of the widget editor.
In the Tests tab, find commits related to failures

When analyzing pipeline run failures, ALM Octane displays the commits that may be related to
test run failures. For details, see "Expand your test failure analysis" on page 196.
Map SCM users to ALM Octane users

Identifying the users who commit SCM changes as ALM Octane users lets you analyze the commit
information using ALM Octane widgets, filters, and so on.
If the email address defined for an SCM user is identical to the one defined for an ALM Octane
user, the users are mapped automatically when changes they commit are discovered.
Tip: Make sure that your SCM system is configured to share commit authors with your
CI server. For example, in the Jenkins GIT plugin, set the option Use commit author in
changelog .
Otherwise, your space admin can map the users manually. For details, see "Assign roles and
permissions" on page 529.

CI Pipelines
Alternatively, individual ALM Octane users can map themselves to unmapped SCM users listed in
Commits tabs. For details, see "Use the Commits tab to track committed changes" on page 202.
Troubleshooting
l On-premises: I don't see any commit information on the pipeline
If the ALM Octane server was restarted while the pipeline was running, change information will
be available only after the pipeline runs. Try running the pipeline again.
l I don't see any commits associated with my backlog items, or vice versa
Make sure your commit messages follow the correct syntax.
See also:
Identify problematic tests

Problematic tests are tests that are not consistently running successfully. They may be repeatedly
or randomly failing, continuously being skipped or suddenly failing after having been successful.
ALM Octane highlights problematic tests as such behavior indicates a situation you might want to
investigate:
l An automated test run's Problem field indicates the type of problem this test is having. For
example, Continuously failing, Oscillating, Continuously skipped, and more.
l The Problematic tests widget shows a breakdown of test runs that have not been consistently
successful, according to the type of problem. Click on the column of a specific problem type to
view the relevant test runs.
The widget is available in the dashboard and in a pipeline's overview.
The following table shows the test run result patterns that ALM Octane labels as problematic:
Problem Definition
Continuously failing The last 8 runs of the test failed.
Oscillating In the last 8 runs of the test, its Pass/Fail status changed 4 times or
more.
In other words, there were at least 4 times in which a failed run was
followed by a successful run or vice versa.

CI Pipelines
Regression A test that previously passed at least twice is now failing:

Looking at the last 4 or more runs, the series ends with at least 2
passed runs followed by one failed run.
Continuously skipped The test was skipped in the last 8 runs of the pipeline.
Unstable A test that is failing randomly:

In the last 50 runs of the test, there were at least 5 times where the
test passed, failed once, and then passed again.
Note:
l If the test run results match more than one problematic pattern, the Problem field
contains multiple problem types.
l Throughout the patterns, the test may have been skipped in some of the pipeline runs,
but not in the most recent pipeline run.
Example: P=Passed, F= Failed, S = Skipped.
FSFFFSFFFF: Continuously failing
FFFFFFFFFFS: Not problematic (ends with skipped)
PFPPSPFPP: Oscillating (4 changes)
PFPPFPPSS: Not problematic (ends with skipped)
PPPF: Regression
PPFFFSFFF: Regression
SSSSSSSS: Continuously skipped
SSFSSSSS: Not problematic (not all 8 skipped)
See also:

CI Pipelines
Identify hotspots in your code

ALM Octane uses commit information to help you, the developer, identify hotspots in the code.
Once identified, you can minimize risks associated with updating the code.
In addition, ALM Octane displays a risk indication for commits that include changes to hotspot
files, and for features associated with such risky commits.
In this topic:
l "How does ALM Octane measure hotspots?" below
l "Set up the hotspot dashboard widget" below
l "Assess potential risk using the hotspot widget" on the next page
l "Identify risky commits and features at risk" on page 210
l "Identify application modules at risk" on page 211
What is a hotspot?
Hotspots are files that contain sensitive code, which is risky to change. The code might be too
complex, or the functionality it covers might be insufficiently tested.
To reduce the risk of future changes causing quality issues:
l Simplify and refactor the code.
l Increase testing of this code's functionality.
How does ALM Octane measure hotspots?

ALM Octane uses commit information to identify hotspots.
Hotspot. ALM Octane considers a file a hotspot if it was recently changed when fixing a defect.
Hotspot level. The hotspot level is the level of potential risk when changing code in a hotspot. A
high hotspot level indicates that changing this code has a high risk of introducing regressions or
other quality issues.
ALM Octane determines the hotspot level based on the following criteria:
l The number of defects associated with this file.
l The age of the changes made to this file.
This means the level is time-sensitive. Over time, if no additional defect-related changes are
committed on a hotspot file, its hotspot level diminishes.
Set up the hotspot dashboard widget

The hotspot widget in the Dashboard displays a heatmap of your code base folders, highlighting
areas by hotspot level.

CI Pipelines
1. Prerequisites:
Make sure the workspace admin or DevOps admin has created a pipeline on a CI server that
works with an SCM system. For details, see "Create and configure pipelines" on page 163.
Make sure to associate your commits with the relevant ALM Octane stories using commit
messages. For details, see "Customize commit message patterns" on page 414.
2. In the Dashboard module, locate the Hotspots files in repository (by folder) widget.
If it is not displayed, click + and add the widget to your dashboard.
3. Configure the widget to show the code base you want to assess:
In the Scope tab, select a Repository and a Base folder for risk assessment.
The lists to select from include the repositories and folders available via the CI server SCM
integration.
Assess potential risk using the hotspot widget

After you "Set up the hotspot dashboard widget" on the previous page, the widget displays a
heatmap of your code base folders, highlighting areas by hotspot level. The hotspot level of a
folder is the average hotspot level of the files in that folder.
To assess potential risk using the widget:

1. Check which folders contain a higher percentage of hotspots.
l Each area in the heatmap represents a folder under the base folder, regardless of folder
structure.
l The size of each area indicates the amount of files in the folder.
Note: ALM Octane analyzes only files that were changed in SCM commits
discovered as part of a pipeline run.
Over time, this will cover more and more of your code base.
l The color of each area indicates the hotspot level. This is the level of potential risk in
changing a hotspot file.

CI Pipelines
2. Hover over an area in the heatmap to see a breakdown of the hotspot levels within a specific
folder. You can see the number of files in the folder for each level.

CI Pipelines
3. Click an area in the heatmap to see the hotspot levels of each file in the folder.
Identify risky commits and features at risk

ALM Octane displays a risk indication for commits that include changes to hotspot files and for
features associated with such commits.
l Identifying risky commits can help isolate the problem when analyzing pipeline failures.
l Identifying features at risk can help assess feature release readiness.
Examples for using the risk indication

Looking for the root cause of a failed automated test run?
1. In the Pipelines module, open a failed pipeline run's Analysis > Test Runs tab.
2. Select the failed test run and open the Commits tab on the right.
3. If a related commit is marked as risky , check whether it is the cause of the failure.
Want to make sure your team is delivering good quality code?

1. In the Team Backlog module, open the Commits tab.
2. Add the Risk column to the grid if it's not there.
3. If many commits are marked as risky, this means that hotspot files are being changed. You
may want to discuss additional testing or code refactoring with your team.

CI Pipelines
Trying to decide if your features are ready for release?

A feature may be associated with risky commits via commit messages listing the features backlog
items.
Use one of the following methods to identify features with risky commits. You can then consider
increasing testing on these features or postponing their release.
l In the Backlog module, open the Features tab.
If a feature is associated with risky commits, the risk indication is displayed on the feature in
the Smart List view. You can see how many of the commits for this feature were risky.
In the grid view, use the Risky Commit Count column.
l In the Dashboard, use the Features by risky commits dashboard widget.
Note:
l Unknown. Commits not associated with any backlog item via commit message.
l Backlog. Commits associated with backlog items that do not belong to a specific
feature.
Identify application modules at risk

Include the percentage of risky commits in the criteria used by the Quality by application module
dashboard widget. Application modules in this heatmap are marked red for attention if they are
associated with more risky commits than the threshold you define.

CI Pipelines
See also:
l "Track commits associated with a pipeline run" on page 201
Track security vulnerabilities

This topic describes how to track, analyze, and fix security vulnerabilities discovered in your code.
In this topic:
l "Overview" below
l "Prerequisites" below
l "View security assessment results in ALM Octane" on the next page
l "Manage the discovered vulnerabilities" on the next page
Overview
If you set up security testing integration, a pipeline run triggers a security assessment of your
application's code, and ALM Octane displays the newly found vulnerabilities in the pipeline run.
This enables you to quickly identify and correct security vulnerabilities introduced into the code.
For details, see "Set up security testing integration" on page 427.
Prerequisites
To view vulnerabilities on a pipeline run, the following conditions must be met:
1. The pipeline was created as part of the Fortify on Demand integration. For details, see "Set
up security testing integration" on page 427.

CI Pipelines
2. The pipeline run on Jenkins was successful.

3. The Fortify on Demand security assessment for this pipeline run is finished.
View security assessment results in ALM Octane

In the Pipelines > Pipelines page, you can see the number of new vulnerabilities found by Fortify
on Demand following the latest pipeline run. Click the number to open the Vulnerabilities tab for
that pipeline run.
In each pipeline run, in the Vulnerabilities tab, you can see details about the new vulnerabilities
discovered on that pipeline run.
Note: The Vulnerabilities tab is available only for pipelines with the Security type. You can
see a pipeline's type in the pipeline's Details tab.
Manage the discovered vulnerabilities

If your pipeline run was successful and was followed by a static code analysis looking for security
issues, the Vulnerabilities tab displays the new vulnerabilities found on this run.
Vulnerability entities should remain relevant only for a short period of time. After reviewing a
vulnerability, create a relevant defect to fix in your code, or dismiss and close the issue.
What can I do with a vulnerability?

l As a build or CI owner:
Assign a user to investigate or fix a security issue.
l As a committer to this pipeline run:
Click Vulnerabilities related to me to find any security issues that your committed changes
may have introduced. This filter shows only vulnerabilities found on files that were included in
your commits. You can then assign yourself to investigate these issues.
l As a user investigating a vulnerability:
Click the vulnerability's ID to open it and view more details. If the Fortify on Demand server is
currently available, ALM Octane shows additional information from the security assessment
that can help you fix the issue. For example, the explanation of the issue, and the suggested
recommendations.
l As a user who investigated a vulnerability:
If you found the problem that needs to be addressed, use the Report Defect button to create a
defect from the selected vulnerability. The important details from the vulnerability are
automatically included in the defect.

CI Pipelines
l Anyone handling a vulnerability:

Update the vulnerability's Status to reflect what you did.
See also:
l "Set up security testing integration" on page 427
Track code coverage in pipeline runs

This topic explains how to see combined data from your Jenkins JaCoCo or LCOV code coverage
reports in ALM Octane.
In this topic:
l "Code coverage overview" below
l "Connect ALM Octane to code coverage data" below
l "View code coverage data in ALM Octane" on the next page
l "The 'Code coverage by package' widget" on page 216
Code coverage overview

To enable frequent releases with minimal disruption and maximum quality, it is best to regularly
run automated tests that cover as much of your code as possible. Code coverage on pipeline runs
measures the percentage of lines in your code that was called during a particular run of the
pipeline.
ALM Octane combines the information from all of the code coverage reports in your pipeline run
and shows you a unified picture. Pipelines display widgets that show code coverage per package
and per file, as well as code coverage trends over time. Using this information, you can track how
much of your code is covered by automated tests.
Tracking code coverage in ALM Octane is made up of the following:
Step Tool
Configure code coverage reports on Jenkins Standard industry tools
Send code coverage reports to ALM Octane Jenkins Application Automation Tools plugin
View code coverage information ALM Octane
Connect ALM Octane to code coverage data

Connecting ALM Octane to code coverage data from Jenkins requires the following:

CI Pipelines
1. Use standard industry tools such as Maven and JaCoCo to generate code coverage JaCoCo
or LCOV reports on your Jenkins server.
2. Set up ALM Octane integration with your Jenkins server using the Application Automation
Tools plugin. For details, see "Set up CI servers" on page 403.
This feature requires version 5.3.1 or later of the plugin . This version is currently available as
a beta version: https://mvnrepository.com/artifact/org.jenkins-ci.plugins/hp-application-
automation-tools-plugin. If you are using an earlier version of the plugin, you can upgrade
your plugin to this version.
3. In Jenkins, for pipeline steps whose code coverage you want to track on ALM Octane, create
a post-build step that sends the code coverage reports to ALM Octane.
Select the HPE ALM Octane code coverage publisher post-build step, and provide the paths
to your code coverage reports.
4. Run the pipeline.
View code coverage data in ALM Octane

ALM Octane receives all of the code coverage reports that belong to one pipeline run and
aggregates them. You can then see an overall picture of the code coverage in your pipeline runs
and determine whether the coverage is improving over time.
1. In the Pipelines > Pipelines page, add the code coverage widgets to the pipeline dashboard.
The widgets show code coverage per package and per file, as well as code coverage trends
over time.
The Code coverage by pipeline run widget shows the overall percentage of code lines
covered by automated tests in each pipeline run. Invest in developing automated tests for as
much of your code as possible, aiming to develop and then maintain a high code coverage as
your code base grows.

CI Pipelines
The Code coverage by package widget shows the code coverage per package in your code
base, as well as the percentage of code lines covered by automated tests in each file. For more
details, see "The 'Code coverage by package' widget" below.
2. Click the pipeline's ID to open it.
In the Runs tab, you can see a code coverage bar on each pipeline run. Red represents the
code lines that were not reached by any test runs. Green represents the code lines that were
called at least once during the tests that ran as part of this pipeline run. Hover over the bar to
see the exact numbers of files.
The 'Code coverage by package' widget

Use the Code coverage by package widget to quickly identify the largest areas in your code and
the ones with the lowest code coverage. If important code packages are large and have low
coverage, invest in creating more or better automated tests for those areas.

CI Pipelines
This widget is interactive and shows more information about the areas you hover over or click.
l Each area in this sunburst chart represents a code package.
l The size of each area indicates the amount of code lines in the package.
l The color of the area represents the code coverage of this package. Red represents packages
where no code lines were reached by any test runs. Green represents 100% code coverage. The
colors and shades in between represent the range of code coverage percentage.
l The circles represent the code package hierarchy, with the high-level packages closer to the
center of the chart.
Hover over an area to see the package name and the code coverage percentage.

CI Pipelines
l The outer rim of the chart represents code packages at the bottom of the hierarchy, which
contain files. Click on areas in the outer rim to open a heatmap that shows coverage details per
file.
Connecting ALM Octane to code coverage data from Jenkins requires the following:
1. Use standard industry tools such as Maven and JaCoCo to generate code coverage JaCoCo
or LCOV reports on your Jenkins server.
2. Set up ALM Octane integration with your Jenkins server using the Application Automation
Tools plugin. For details, see "Set up CI servers" on page 403.
This feature requires version 5.3.1 or later of the plugin . This version is currently available as
a beta version: https://mvnrepository.com/artifact/org.jenkins-ci.plugins/hp-application-
automation-tools-plugin. If you are using an earlier version of the plugin, you can upgrade
your plugin to this version.
3. In Jenkins, for pipeline steps whose code coverage you want to track on ALM Octane, create
a post-build step that sends the code coverage reports to ALM Octane.
Select the HPE ALM Octane code coverage publisher post-build step, and provide the paths
to your code coverage reports.
4. Run the pipeline.
View code coverage data in ALM Octane

ALM Octane receives all of the code coverage reports that belong to one pipeline run and
aggregates them. You can then see an overall picture of the code coverage in your pipeline runs

CI Pipelines
and determine whether the coverage is improving over time.

1. In the Pipelines > Pipelines page, select a pipeline and click its ID to open it.
2. In the Runs tab, you can see a code coverage bar on each pipeline run. Red represents the
code lines that were not reached by any test runs. Green represents the code lines that were
called at least once during the tests that ran as part of this pipeline run. Hover over the bar to
see the exact numbers of files.
3. In the Details tab, widgets show code coverage per package and per file, as well as code
coverage trends over time.
The Code coverage by pipeline run widget shows the overall percentage of code lines
covered by automated tests in each pipeline run. Invest in developing automated tests for as
much of your code as possible, aiming to develop and then maintain a high code coverage as
your code base grows.

CI Pipelines
The Code coverage by package widget shows the code coverage per package in your code
base, as well as the percentage of code lines covered by automated tests in each file. For more
details, see "The 'Code coverage by package' widget" on page 216.
The 'Code coverage by package' widget

Use the Code coverage by package widget to quickly identify the largest areas in your code and
the ones with the lowest code coverage. If important code packages are large and have low
coverage, invest in creating more or better automated tests for those areas.
This widget is interactive and shows more information about the areas you hover over or click.
l Each area in this sunburst chart represents a code package.
l The size of each area indicates the amount of code lines in the package.
l The color of the area represents the code coverage of this package. Red represents packages
where no code lines were reached by any test runs. Green represents 100% code coverage. The
colors and shades in between represent the range of code coverage percentage.
l The circles represent the code package hierarchy, with the high-level packages closer to the
center of the chart.
Hover over an area to see the package name and the code coverage percentage.

CI Pipelines
l The outer rim of the chart represents code packages at the bottom of the hierarchy, which
contain files. Click on areas in the outer rim to open a heatmap that shows coverage details per
file.

Testing
l Each area in the heatmap represents a file in the selected package.

l The size of an area indicates the amount of code lines in the file.
l The color of the area represents the level of code coverage.
l Hover over an area to see the exact number of lines and code coverage percentage.
See also:
Testing
As you develop your application, testing is a critical part of the process. Testing ensures that the a
product meets your organization's quality standards. To assist, ALM Octane helps you with many
types of testing frameworks and test types.
ALM Octane supports manual, Gherkin, and automated tests.
Manual Use Manual tests and Gherkin tests for acceptance testing, unit testing, or
tests and integration testing. In these tests, the tester uses the application to make
Gherkin test everything works as expected.
Manual tests list each step and you perform the test, step by step. Gherkin tests
contain scenarios that describe what to test but give the freedom how to test.
Automated Automated tests are helpful for repetitive tasks and performing difficult tasks.
tests Use automated tests for unit testing, regression testing, and continuous
integration.
You maintain automated tests in external testing tools.
ALM Octane incorporates test run results in dashboard and quality analysis.
There a different test entity types to use to organize testing. For details, see the section on
Testing entities in the glossary of ALM Octane entities.
Next steps:
l "Create manual tests" on page 231
l "Create Gherkin tests" on page 237
l "Automate Gherkin tests" on page 263
l "Create test suites" on page 249
l "Add automated tests" on page 267

Testing
Manual testing flow

In addition to helping manage the development process, ALM Octane helps you manage your
testing and quality efforts with a complete manual testing framework.
In this topic:
l "The testing process" on the next page
l "What kind of testing can I do?" on the next page
l "Testing Design" on page 225
l " Test Development" on page 225
l "Test Execution" on page 226
l "Test Analysis" on page 226

Testing
The testing process

Traditionally, test management follows a standard process:
You design and develop the tests then run and analyze the results.
This process repeats again and again. This lets you test the quality of your development and
product on an ongoing basis.
What kind of testing can I do?

ALM Octane has the following types of testing entities:
Manual Manual tests are the most basic and efficient way to start tracking quality. These
tests tests contain a list of actions (steps) that a user might perform when using the
application. Running the test means you perform each action as written in the
test step.

Testing
Gherkin Gherkin tests are also a type of manual test. Gherkin tests are built with scenarios.
tests These tests use Behavior Driven Development (BDD) with use-case scenarios
based on how a user may use the application.
Gherkin tests use natural language syntax. You can also later automate a Gherkin
test, line-by-line.
When you run the test, you follow the scenario and its parameters.
Automated Automated tests are created and edited in external testing tools and added to a
tests build in your CI server. ALM Octane discovers the test results in the build results
and creates the automated test entity inside ALM Octane.
Use these results in ALM Octane as part of your product and release quality.
Test suites Test suites contain multiple manual tests, Gherkin tests, and automated tests.
You assign test runs to people and run each test individually. After finishing all
the test runs, ALM Octane aggregates the results of each test run into a single
suite run.
When you run the test suite, the automated test runs run on the CI server. All
manual and Gherkin tests, run in the ALM Octane Manual Runner.
Testing Design
During test design, you specify what parts of the application to test and creating the tests.
Do your test design when constructing the Backlog and Quality modules:
l When creating the Backlog, create the tests to verify Backlog items.
l As you add application modules, associate new or existing tests with application modules.
l When you open defects, create a test to verify the defect fix.
l Associate tests with Backlog items using a test's Backlog coverage field.
For details on working with the Backlog module, see "Build the product backlog" on page 110. For
details on working with application modules, see "Work with application modules" on page 148.
Test Development
To develop tests, add steps to target the specific actions to test. In manual tests, the test steps
explain action-by-action what to do in the application. For Gherkin tests, the test script is a use-
case scenarios instead of an action-by-action list.
For details on creating manual tests, see "Create manual tests" on page 231. For details on
creating Gherkin tests, see "Create Gherkin tests" on page 237.

Testing
Test Execution
Test execution happens when you run the tests. In ALM Octane, you run manual tests with the
ALM Octane's Manual Runner.
When you open a test in the Manual Runner, perform each step as written in the test or scenario.
Make notes in each step or scenario and assign a status to validation steps.
If necessary, report defects for problems found during tests. Add attachments to the test run to
help others understand the test results and application state during the test.
After you finish, click to end the run. After the test run, ALM Octane compiles the results in a
single report.
For details on running tests, see:
l "Plan and run test suites" on page 257
Test Analysis
After you run manual tests, analyze the results. ALM Octane compiles the test or test suite run
results into a single report. View this report, step-by-step, to see the run details.
ALM Octane also provides many useful graphs for release and product quality analysis. Use the
standard out-of-the-box widgets or design your own by configuring custom widgets.
To analyze cross-release quality, use the Dashboard module. To analyze release-, sprint-, feature-
or application module-specific quality, use the Overview tabs in the Backlog or Quality module.
For details on test results, see "Stop the run and see results" on page 255 or "View the suite run
results" on page 260. For details on analyzing quality, see "Use the ALM Octane Dashboard" on
page 290.
Automated testing flow (pipelines)

This flow describes how to bring automated test run results into ALM Octane using CI server
pipelines and include them in the overall analysis of your product.
In this topic:
l "Overview" on the next page

l "Prepare your testing tool environment" on the next page
l "Set up a Jenkins server to trigger test runs" on the next page

Testing
l "Set up a Jenkins job to run tests using the testing tool" on the next page
l "Create a pipeline in ALM Octane containing the Jenkins jobs" on page 229
l "Run the pipeline " on page 230
l "Use test assignment rules to connect results to your ALM Octane entities" on page 230
l "Analyze test results" on page 231
Overview
Automated tests, as well as load and performance tests are managed in external testing tools. You
can set up a CI server to run those automated tests, and then set up ALM Octane to collect those
results. This enables you to see a comprehensive picture of your application's quality and
coverage.
This topic describes working with a Jenkins CI server, but you can create a similar set up with other
CI servers as well.
l Set up your automated tool to run tests.
l Configure your CI server to trigger the runs, publishing the results (JUNit, NUnit, etc.) to the
CI server.
l Integrate ALM Octane with your CI server using an ALM Octane plugin.
l Set up and run pipelines that run the tests.
l The ALM Octane plugin collects the results and sends them to ALM Octane.
Note: If you are working with UFT tests, you can set up a straightforward integration with
UFT without using pipelines. For details, see "Set up UFT integration" on page 421.
Prepare your testing tool environment

Prepare a machine with your testing tool installed, which can access and run the automated tests.
Set up a Jenkins server to trigger test runs

Although the tests are run via the CI server, you do not need to configure a full CI system. To run
Micro Focus automated tests on Jenkins and send the run results to ALM Octane, only the steps
below are required.
For other automated testing tools, set up whatever those tools require on Jenkins. Make sure that
the job running your tests publishes the test run results to Jenkins.
Jenkins setup for Micro Focus automated tests:

1. Install the Jenkins server.
2. Install the Application Automation Tools plugin.

Testing
This plugin lets you:

l Run Jenkins jobs specifically designed to run UFT, StormRunner Functional, or
Performance Center tests.

l Prepare the test run results as required by ALM Octane.
l Send the results to ALM Octane, enabling you to view the results as part of your overall
quality analysis.
For details on downloading, installing, and configuring this plugin, see the Application
Automation Tools wiki page.
Note: To support Performance Center tests, use version 5.2 or later or the plugin.
3. For UFT tests running in your pipeline:

l Configure Jenkins to locate your tests. If the tests are stored in ALM, provide the ALM
location. If they are in an SCM repository, check them out to the Jenkins workspace on
your UFT machine.
l Define the UFT machine as an execution node on Jenkins. For details, see the section on
execution nodes in the Application Automation Tools wiki page.
Set up a Jenkins job to run tests using the testing tool

Create a Jenkins project to run the automated tests and publish the results.
For StormRunner Load tests, set up Jenkins to run your tests as described in the StormRunner
Load Help Center. Add a post-build action to Publish JUnit test result report.
For UFT, StormRunner Functional, or Performance Center tests, follow the instructions in
Application Automation Tools wiki page to do the following:
1. Build a free-style software project and add build steps that execute the tests.
2. Add the relevant post-build action to publish the test results. This ensures that the results
are sent to ALM Octane in the format it recognizes.
For the Report archive mode select to always archive the test reports.
Additional setup requirements

l For UFT tests, make sure to limit the project to run on the machine that you defined as the
execution node.

Testing
See
https://wiki.jenkins.io/display/JENKINS/HPE+Application+Automation+Tools#HPEApplicatio
nAutomationTools-RunningFunctionalTestsfromtheFileSystem.
l For Performance Center tests, configure the connection to the Performance Center machine.
See
https://wiki.jenkins.io/display/JENKINS/HPE+Application+Automation+Tools#HPEApplicatio
nAutomationTools-RunningPerformanceTestsusingHPPerformanceCenter.
Create a pipeline in ALM Octane containing the Jenkins jobs

To send automated test run results to ALM Octane, the Jenkins jobs that runs the tests must be
included in a pipeline run.
Create a pipeline from ALM Octane or from the Jenkins project.
From ALM Octane

See "Create and configure pipelines" on page 163.

Testing
From Jenkins
See
https://wiki.jenkins.io/display/JENKINS/HPE+Application+Automation+Tools#HPEApplicationA
utomationTools-CreateandconfigureALMOctanepipelinesonJenkins.
Run the pipeline

When a pipeline runs, the results are sent to ALM Octane.
To run a pipeline, do one of the following:
l In the ALM Octane Pipelines module, select the pipeline and click the Run Pipeline button.
l In Jenkins, manually launch the build project you created.
l In Jenkins, schedule the build project to run at a pre-determined time.
After the pipeline and test runs are finished, the plugin sends the test results to ALM Octane.
ALM Octane creates automated test and test run entities based on the test results it receives. If a
relevant automated test already exists, the results are associated with that test. For details, see
"Creating automated test entities" on page 268.
Use test assignment rules to connect results to your ALM Octane

entities
Assigning automated tests to application modules and backlog items in ALM Octane lets you view
the test results in context. You can then use these results to analyze the progress and quality of
your release and product.
Assigning owners to automated tests helps accelerate problem resolution. You can configure a
pipeline to notify test owners when their test runs fail.

Testing
For details, see "Assign tests to application modules and backlog items" on page 270.
Analyze test results

The test run results are available in pipeline runs and in automated test runs.
Open a specific test run for detailed results. To open the detailed report provided by the testing
tool, click Testing tool report in the upper right corner of the test run .
Note: Performance Center provides detailed reports only for tests that pass successfully.
View the pipeline run results in the Pipelines module. For details, see "Run pipelines" on page 175.
If you assigned your tests to backlog items and application modules, the results are included in
your release and product tracking dashboard widgets.
See also:
Create manual tests

Create manual tests in ALM Octane.
In this topic:
l "Create tests and add test steps" below

l "Use parameters in tests" on page 233
Create tests and add test steps

Tests can be created from the Quality and Team Backlog modules, either from the Tests page or
from a Test Suite.
You can compose a test script using either the Text Editor or the Visual Editor. Typically, tests are
created using the Text Editor, however, you can also use the Visual Editor. The Visual Editor
includes all of the functionality provided by the Text Editor, except for text formatting.

Testing
To create manual tests:

1. Create the test.
l From Team Backlog or Quality modules, click Tests, click the down arrow next to the +
icon, and click Manual Test .
lFrom a Test Suite, click Tests, click the down arrow next to the Add Existing Test
button, and then click Manual Test.
2. In the Add Manual Test dialog box, assign test attributes:
Name The name of the test.
Test type The type of test, such as acceptance, end-to-end, regression,

sanity, security, and performance.
Estimated duration The time it takes to run the test.

(minutes)
Backlog coverage The backlog items the test will cover. This helps you track the
release quality.
Application The product's application modules. This helps you track product
modules quality, regardless of release.
Description The test description.

3. Click Add & Edit.
4. Click Steps, and then click Text Editor .
Note: To use the Visual Editor, to add or edit steps, click the Visual Editor button.
5. Use the buttons in the toolbar to add steps.

If you are entering the entire test manually, make sure to use the correct syntax. For details,
see "Manual test syntax" on page 235.
Add Step Add a setup step (an action in the application).
Enter the step text. For example: Create a new Epic.
Add Check something in the application.

Validation Enter the step text. For example: Verify that the current phase is New.
Step
During the test run, you specify a pass or fail status for each validation step.

Testing
Add Call Add steps from an existing test to your script.

Step In the Add Tests dialog box, select the test or test that you want to call, and
then click Add.
The step is added as a hyperlink to the original test. Click the View test steps
button to display the steps of the test that you called.
6. To apply text formatting, see "Create manual tests" on page 231.

7. To add attachments, click Attach to add files and navigate to the required file or paste an
image directly into the test.
ALM Octane adds the attachment as a separate step in the test.
You can view the file in the Attachments tab of the test, the Manual Runner when starting a
test run, or the test run report.
8. Save your test.
Tip: While you work, save and label versions of your manual test. As you work with
the test over time, compare versions to view modifications. For details, see "Use
versions of test scripts" on page 260.
Use parameters in tests

You can create tables with parameters and parameter values for re-use in manual tests. When you
run a test, it runs in multiple iterations using a different set of parameter values each time.
Here's a simple example showing a list of users and passwords. Each iteration will use a different
set of values:
To work with parameters:

1. When creating a test that will use parameters, click the Parameters Table button.
2. In the pane that opens on the right, either create a new table, or choose a saved table from

Testing
the dropdown options.

3. Enter a name for the table, and click on each column header to rename the column. Each
column represents a parameter.
Parameter names cannot contain empty spaces or angle brackets (< >).
4. In each row, enter a set of parameter values.
5. To add or remove rows or columns, click the dropdown arrow next to the row or column
name. The arrow is visible when you hover over a cell or column header.
6. Click Save when your table is ready.
7. You can use the menu options next to the Save button to manage your parameter tables. If
you select Remove from test, you disconnect the table from the current test but it is still saved
in ALM Octane. If you select Delete table, it is removed from all tests that are using this
parameter table. ALM Octane shows you which tests use the table before you delete it.
8. In the relevant test step, enter parameter names using the following syntax: <parameter
name>.
Tip: You can also quickly access the list of parameters by pressing CTRL-SPACE. Use
the keyboard arrows to navigate the list, and Enter to select a parameter.
9. When you run the test, it runs in multiple iterations. Each iteration uses a different set of
parameter values from the table.
Using the above example, here are the results of a run:

Testing
Next steps:
l "Import manual tests and test suites" on page 243
l "Link manual and Gherkin tests to automated tests" on page 248
Manual test syntax

Use markdown for adding steps and for formatting text.
In this topic:
l "Test syntax" below

l "Format text in the test script" on the next page
Test syntax
When working in the Text Editor, use the following syntax to add steps:
Setup or regular Each step starts with a hyphen and a space.

steps
Example: - Navigate to the Web site.
Validation steps Each step begins with a hyphen, space, and question mark:
Example: - ? Validate that the page loaded correctly.
Call to step Each step begins with a hyphen, space, and the @ character with the
ID number of the test to call:
Example: - @1102 Search by user
Parameter Syntax: <parameter name>

Example: Use port number <port>
For details, see "Use parameters in tests" on page 233.
A step can span more than one line. You do not need put a hyphen and space on other lines if a
step continues.
Tip: When working in the text editor, a red X displays next to any lines with syntax or logic
errors. For example, a call step cannot call the its own test.
Example:
Basic example

Testing
Example that calls another test
Format text in the test script

Use markdown in your test script to emphasize text and display it in bold, italics, underline, or
colors (red, green, blue).
Aside from the text editor, all other displays of the test script will include the formatted text (for
example, the Visual Editor, Manual Runner, and Run report).
To format text:
In the Text Editor, use the following syntax to format your test script:
Bold **text**
Italics *text*
Underline __text__
Red {text}red
Green {text}green
Blue {text}blue
For example:

Testing
- Display the following in bold: **bold**
- Display the following in italics: *italics*
- Display the following underlined: __underline__
- Display the following in red: {red}red
- Display the following in green: {green}green
- Display the following in blue: {blue}blue
The Visual Editor will display the formatted test script:
Note: You can combine formatting. For example: *You can **combine** formatting*
Create Gherkin tests

Create Gherkin tests in ALM Octane to test from a user perspective or to help transition manual
testing to automated testing.
In this topic:
l "Why use Gherkin tests?" below
l "Create Gherkin tests" on the next page
l "Add test scenarios" on page 239
l "Prepare your Gherkin tests for automation" on page 240
Language support: Gherkin tests in ALM Octane support only English syntax.
Why use Gherkin tests?

Gherkin is a well-known syntax for writing tests using behavior-driven development (BDD). This
syntax lets you test from the user perspective by using use-case scenarios.

Testing
Gherkin syntax uses plain-text English with a specific structure. Gherkin syntax is easy to learn but
structured enough to allow specific examples.
Using Gherkin tests has advantages:
Choosing Gherkin tests helps By creating Gherkin tests, you can move them to
transition from manual testing to automated tests:
automated testing
1. Write the tests in ALM Octane using standard
Gherkin syntax.
2. Choose a few tests to automate.
3. Download the test script, and in your IDE, write
code for automation.
4. Include the automated tests in your CI process.
ALM Octane links the results back to the
original Gherkin tests.
For details on running Gherkin tests as part of a
CI progress, see "Automate Gherkin tests" on
page 263.
5. View the results in ALM Octane.
Using Gherkin scenarios, add Because Gherkin tests use scenarios,change the
parameter-like functionality values used in the test run.
Create Gherkin tests

Before adding scenarios and steps to a Gherkin test, create the tests in ALM Octane.
To create Gherkin tests:

1. In the Backlog or Quality modules, or the Tests tab of a test suite, click + and select Gherkin
Test.

Testing
2. Assign test attributes. Make sure to enter values for the following attributes:
Test type The type of test, such as Acceptance, End to End, Regression, Sanity,
Security, or Performance.
Backlog Select the backlog items the test covers. This helps you track release
coverage quality.
Application The product's application modules. This helps you track product quality,
modules regardless of release.

4. In the Script tab, add the required feature and test scenarios. For details, see "Add test
scenarios" below.
5. Save the test.
Add test scenarios

Add features and scenarios to provide the content of the test. For details about the syntax, see
"Gherkin test syntax" on page 241.
To add Gherkin test scenarios:

1. In the test, click the Script tab. ALM Octane generates the script with the Test ID (TID) and
revision number (REV). If you automate the test, these lines help ALM Octane identify the
Gherkin test for the test results.
1 #Auto generated NGA revision tag

2 @TID1001REV0.1.0
3 Feature:
Note: ALM Octane uses the Test ID tag to map the automation results. DO
NOT DELETE the Test ID tag!
2. In the Feature line, add a description of the feature.

3. In the toolbar, click Add Scenario or Add Scenario Outline. Enter the details in the scenario or
scenario outline template.
4. Add scenarios or scenario outlines as needed.
5. Save the script.
ALM Octane saves the script as a text file. Edit the file in ALM Octane or download it to your
IDE.

Testing
Tip: While you work, save and label versions of your manual test. As you work with the
test over time, compare versions to view modifications. For details, see "Use versions of
test scripts" on page 260.
Prepare your Gherkin tests for automation

By default, when you create a Gherkin test, the test's automation status is Not automated.
To prepare Gherkin tests for automation:

1. In the test Details tab, set the Automation status to Ready for automation.
2. Download the Gherkin script and automate it in your preferred Java development
environment. For details, see "Automate Gherkin tests" on page 263.
When you complete the automation process in your IDE and CI server environment, and the
script in ALM Octane matches that in the IDE, the Automation Status changes to Automated.
3. If the script version in your IDE does not match or is not synchronized with the script version
in ALM Octane, adjust depending on the status:
Requires The script was modified in ALM Octane and is not up-to-date in the
update automation code.
a. Download the new version of the script from ALM Octane.
b. Merge the script with the previous version in the IDE.
c. Update the automation code.
The CI server uses the latest version of the script from the automation code. If
the script version in the automation code is not up-to-date, the test runs with
an older script version than the one in ALM Octane.
Requires The script was modified in the IDE and is not up-to-date in ALM Octane.
approval a. Click the Script changed externally link to compare script versions.
b. Decide which script version you want to approve.
c. Click Accept to update the script in ALM Octane according to the external
version from the automation code. Click Decline to reject the externally
modified script and to keep the ALM Octane script version.
The script is now the same in the automation code and in ALM Octane.
ALM Octane displays the test's Automation status as Automated.

Testing
Next steps:
l "Use versions of test scripts" on page 260
l "Automate Gherkin tests" on page 263
l "Gherkin test syntax" below
Gherkin test syntax

When creating a Gherkin test, use a specific structure and syntax to follow established Gherkin
rules.
Note: When editing, ALM Octane displays a red X next to any lines with syntax or logical
errors.
In this topic:
l "Feature section" below

l "Background section" on the next page
l "Scenario section" on the next page
l "Scenario Outline" on page 243
Feature section
The feature defines the purpose and goal of the Gherkin test.
l The feature line starts with the keyword: Feature:
l A feature contains any number of scenarios.
l Until the first scenario, enter any text. The text describes the related persona, the feature
description, and its importance to that persona.

For example:
Feature: Refund an item.
The sales assistant should be able to refund customer purchases.
This is required by law, and is also essential to keep customers

happy.
Feature: Buying items in shopping cart, single user.

Testing
Background section
You run backgrounds before each scenario. The background defines one set of settings or one
context to all scenarios in a feature.
l The Background section starts with the keyword: Background:
l Backgrounds can contain steps (Given , When , and Then ).
For example:
Background:
Given: payment security system is up
Scenario section
Scenarios describe what the user does and how the application should respond.
l The Scenario line starts with the keyword: Scenario:
l A feature can contain many scenarios.
l Every scenario contains steps, also known as annotations in Gherkin syntax. The steps let you
know what to do for the test run. Each scenario can contain many steps of each type.
l Steps start with Given, When, and Then. Each scenario can contain more than one step.
Given statements Given steps are preconditions.
When statements When steps describe the action that the user is performing.
Then statements Then steps describe the expected result of the performed action.
For example:
Scenario: Julio buys items in his cart
Given a customer named "Julio Brown"
Given I am logged in as Julio
Given I have at least one item in cart
When I try to buy items in my cart
When I should be asked for my payment method

Testing
Scenario Outline
The Scenario Outline runs once for each row in the Examples section. You can use the Scenario
Outline to parameterize a Gherkin test.
l Like a Scenario, the Scenario Outline usually contains Given, When, and Then steps.
l The Given , When , and Then steps contain placeholders (variables) with names listed between
the < and > signs.

l The Examples: section contains values for the placeholders to use when the scenario outline
runs.
For example:
Scenario Outline: Many users buy items in their carts.
Given a customer named "<customer>"
Given I am logged in as "<customer>"
Given I have at least one item in cart
When I try to buy items in my cart
Then I confirm my payment method "<payment>" and proceed to checkout
Examples:
| customer | payment |
| Jane Doe | Paypal |
| Jorge Rodriguez | VISA |
| Sally Dunn | VISA |
| Pierre Bisset | American Express |
| Masayoshi Horita | Cash |
Import manual tests and test suites

You can import manual tests and test suites into ALM Octane, from an MS Excel file.
In this topic:
l "Step 1: Prepare the import file" on the next page

l "Step 2: Add test steps to your import file" on page 247

Testing
l "Step 4: Import tests and test suites" on page 248

l "Step 4: Import tests and test suites" on page 248
Step 1: Prepare the import file

In an Excel (.xls or .xlsx) file, list the manual tests, test steps, and test suites. You must list Manual
tests and test suites in separate tabs.
ALM Octane supports importing Excel sheets from Microsoft Excel versions 2010 and higher.
Import file example. A template file is available to help you construct your import file. In
the ALM Octane menu, click Import Tests. In the Import dialog box, click View import file
example to download the example Excel file.
To prepare the import file:

1. In the Excel file, create a separate named tab for each item type: manual tests and test suites.
You only need to create tabs for the item types you want to import.
2. In Row 1 of the sheet, add a header row for the fields whose values you want to import. See
the tables below for a list of possible fields. The mandatory fields required for a successful
import are noted.
Note:
l The values described in the tables below are the default system values. Your ALM
Octane workspace may use different values depending on the workspace
configuration.
l Localization: You must use the English field names, even if your UI is in a different
language.
3. On separate rows, enter field values for each test and test suite you want to import.
Each entity in ALM Octane has required fields, as determined by the form settings. If you do
not enter values for all the required fields, ALM Octane adds that entity in Draft status. After
the import, open these items and fill in values for all required fields.
Tip: Use the Is Draft column to find items in Draft status.
Localization: If your user language is set to another language, use localized values in the
Excel sheet.
By default, you can import up to 1000 backlog items in a single import. If you have more,
prepare other Excel files to import all the items.

Testing
To import more than 300 tests, have your site admin set the IMPORT_TESTS_FUSE
configuration parameter to the necessary number. For details, see "IMPORT_TESTS_FUSE "
on page 490.
Manual test fields

In the manual tests tab, enter some or all of the following fields. Field names are not case-
sensitive.
Mandatory fields
unique_id An integer for of the ID for the imported test.
type A list value. Possible values: test_manual or step.

Optional fields
test_type A list value. Values can be Acceptance, End to End, Regression, Sanity,
Security, or Performance.

The name of or path to (for second-level modules) the application module.
If you are associating the story with multiple modules, separate the names
with a comma.
covered_content The ALM Octane ID number representing the backlog items this test
covers.
designer The ALM Octane user name of the person who created the test and test
steps.
estimated_ An integer representing the number minutes expected to perform the test
duration run.
owner The ALM Octane login name for the item's owner.
phase A list value. Possible values include: New, In Design, Awaiting Review,

Ready, or Obsolete.

Testing
user_tags Free text specifying the tags to attach to the item.

imported story.
<User defined The label name (as set in the ALM Octane workspace settings for a user
fields> story) of any user-defined fields in the user story form.
<Other system- Add any REST API-editable fields to the Excel sheet.

defined editable
fields>
fields.
Test suite fields

In the test suites tab, enter some or all of the following fields. Field names are not case-sensitive.
Mandatory fields
type Add test_suite to instruct ALM Octane that you are importing a test suite.
Optional fields
test_id The row number of the manual test (from the manual test sheet) to include
in the test suite.
You must include the referenced manual test in the same import file as the
test suite.

The name of or path to (for second-level modules) the application module.
If you are associating the story with multiple modules, separate the names
with a comma.
covered_content The ALM Octane ID number representing the backlog items this test
covers.
designer The ALM Octane user name of the person who created the test and test
steps.

Testing
owner The ALM Octane login name of the test suite's owner.
user_tags Free text specifying the tags to attach to the item.

imported story.
<User defined The label name (as set in the ALM Octane workspace settings for a user
fields> story) of any user-defined fields in the user story form.
<Other system- Add any REST API-editable fields to the Excel sheet.

defined editable
fields>
fields.
Step 2: Add test steps to your import file

You embed test steps for each test in the same sheet. Add these steps in the rows beneath the
row containing the values for the manual test.
Enter each step on a separate row. Ensure that the header row contains these columns in the
header row. Values for other columns in the header row should remain empty in these rows.
type A list value. Possible values: test_manual or step.
step_type A list value. Possible values include Setup, Validation, or Call to.
If you add a Call to step, ensure that you include the test in the manual test
import sheet.
step_ Free text, for the step description.

description
If this is a Call to step, the value must be the name of the test being called in
brackets: <unique id>
Step 3: Add test suite tests to your import file

Embed tests for each test suite in the same sheet as the test suite. In the rows beneath the row
containing the values for the test suite, enter the test details

Testing
Enter each test on a separate row. For each test, ensure that the header row contains these
columns in the header row. Values for other columns in the header row should remain empty in
these rows.
type Add test for the tests include in the suite.

You must include the test in the current test import.
test_id The unique ID value from the test to include in the test suite.
You must import this test at the same time as the test suite.
Step 4: Import tests and test suites

1. In the ALM Octane menu, click Import Tests.
2. In the dialog box, click Browse and navigate to the folder with the Excel file.
When you click Import, ALM Octane performs a validation to check correct formatting of the
Excel file and that you have not imported the same file before.
ALM Octane does not support updating tests and test suites items via import. You can
import each Excel file only once.
When ALM Octane finishes the validation:
If there are ALM Octane displays a report of the validation with the sheet and line
errors of the error.
At the bottom of the error report, click the Export to Excel link to save
the error report.
Fix the errors and try the import again.
If there are no The import begins.

errors
3. After the import is complete, the items are displayed in the ALM Octane Backlog module or
Quality module.
Next steps:
Link manual and Gherkin tests to automated tests

For some manual and Gherkin tests, running the test takes considerable effort. To help mitigate
this effort, you can:

Testing
l Automate the test with another testing tool

l Link the test to an already created automated test to sync their status and details
Linking tests ensures you have a linkage from the test steps to the automation code. It also
ensures that ALM Octane includes the results of both tests in quality analysis.
To link manual and Gherkin tests to automated tests:

1. In a test with an automation status of Not Automated, open the Details tab.
2. In the Relations tab, click the Add Relation button and select Covering Automated Test.
Tip: In an automated test, select Covered manual test, Gherkin test in the Relations
tab to link between them.
3. In the Select dialog, select the appropriate automated test from the list and click Add.
In the relations grid, ALM Octane connects the tests in the map. ALM Octane also assigns the
automated test to the backlog items and application modules of the parallel manual or
Gherkin test.
In addition, in a linked manual test ALM Octane updates the test's automation status as
Automated.
4. Run the tests as needed in the ALM Octane Manual Runner or the pipeline with the
automated test.
View run results of the automated test run and manual or Gherkin test run in the test's Runs
tab.
Next steps:
l "Import manual tests and test suites" on page 243
l "Use versions of test scripts" on page 260
Create test suites

A test suite is a collection of tests. Use test suites to test an area of your application, for regression
testing events, and so forth.
A test suite can contain manual tests, Gherkin tests, and executable automated tests.
In this topic:
l "What are test suites?" on the next page

l "Create test suites" on the next page

Testing
l "Add tests to a test suite" below

l "Parameterize UFT tests" on the next page
What are test suites?

A test suite is a collection of tests. Test suites do not contain any content of their own.
Use test suites in a variety of ways:
l Group tests of a particular page, module, or section of your application together. This lets you
test that section of the application.
l Keep tests of a particular version of the application grouped together. This lets you perform
regression testing on newer versions.
l Different people run the tests. The owner of the test suite receives the compiled results for the
test suite's test. This method is particularly helpful for regression testing.
l Group tests of the same environment to compare problems between environments.
Create test suites

To use test suites, you must create the container of the test suite.
To create test suites:

1. From the Tests tab of the Quality module, or the Tests tab of a feature or story in the
Backlog module, do one of the following:
l Click + and select Test Suite
l Select the tests, right-click and select Create test suite
2. Set the test suite attributes. In particular, we recommend you provide a value for the Backlog
coverage and Application modules attributes.
4. Click Add button + down arrow and select Manual Test or Gherkin Test. Provide the test
attributes and click Add.
ALM Octane adds the created test to the test suite. Click the link for the test to add the steps.
For details, see "Create manual tests" on page 231 or "Create Gherkin tests" on page 237.
Note: You cannot add tests in draft status to a test suite.
Add tests to a test suite

Because a test suite is a container with no steps of its own, you must add tests to the test suite to
make it useful.

Testing
To add tests to the test suite:

l In the Tests tab of the test suite, click the Add Existing Tests button .
l In the Grid View or Smart List View, right-click a test and select Add to Suite.
2. In the Select tests dialog box, select all the tests you want to include.
3. Click Select.
The tests are then added to the test suite's test grid.
Parameterize UFT tests

If you add executable UFT tests to a test suite and your UFT Git repository contains data tables,
parameterize your test runs using data tables.
Tip: For ALM Octane to locate the data tables in Git, store them in an entirely separate
folder from your tests.
1. In the test suite, open the Tests tab and select the grid view.
2. Add the Data table column to the grid.
3. In the UFT test's row, select a data table to use for the test run. The list of data tables
includes all of the data tables that ALM Octane discovered with your tests.
When the suite runs this test, it will run with the data table you selected.
To run a test with different data tables, add the test to different test suites. In each suite, you can
specify a different data table for this test.
Next steps:
l "Run manual and Gherkin tests" below
Run manual and Gherkin tests

Run tests within ALM Octane using the Manual Runner.
In this topic:
l "How ALM Octane runs tests" on the next page

l "Run tests" on the next page

Testing
l "Assign statuses to test steps" on the next page

l "Report defects during a run" on page 254
l "Add attachments to a run or step" on page 254
l "Stop the run and see results" on page 255
How ALM Octane runs tests

Depending on the type of test, the Manual Runner runs tests differently:
l When running a manual test, view the test steps and add details on the steps. For each
validation step, assign a run status. After the test run, ALM Octane creates a compiled status .
l When running a Gherkin test, view scenarios. For each scenario, assign a run status and assign
one for the test.
Note: The run statuses you assign when running manual tests (including Gherkin tests and
test suites) are called native statuses. When analyzing test run results in the Dashboard or
Overview tabs, ALM Octane categorizes the native statuses into the summary statuses
Passed, Failed, Requires attention, and Planned for clarity of analysis.
Run tests
Run manual tests or Gherkin tests from ALM Octane.
Tip: You can also run manual tests using Sprinter, as described in "Run and edit manual
tests in Sprinter" on page 256.
To run tests:
1. In the Backlog or in the Quality module, select the tests to run.
2. In the toolbar, click Run .
The Run tests dialog box opens, indicating how many tests you are about to run. Specify the
test run details:
Run name A name for the manual run entity created when running a test.
By default, the run name is the test name. Provide a different name if
necessary.

Testing
Release and The product release version to which to associate the test run results and
environment the application environment on which you run the test.
By default, ALM Octane uses the last selected environments.
Script Select Use a version from another release to run a test using a script
version version from a different release. If there is more than one version from the
selected release, ALM Octane uses the latest version.
Any tests linked to a manual test from a Add Call Step use the same
specified version.
Draft run Select Draft run if you are still designing the test but want to run existing
status steps. After the run is complete, ALM Octane ignores the results.
3. Click Let's Run! to run the tests.

The Manual Runner opens.
Tip: During the test run, click the Run Details button to add run details.
4. Perform the steps as described in the step or scenario.
Assign statuses to test steps

Ensure that you record the status of the test as you perform test steps or scenarios. This enables
ALM Octane to use the results in quality analysis.
To assign statuses to test steps:

1. If necessary, click the check mark next to the step or scenario.
2. In each step or scenario, record your results in the What actually happened? field:

Testing
Report defects during a run

If you encounter problems when running a test, open defects or link existing defects.
To open defects during a test run:
1. In the Manual Runner toolbar, click the Test Defects button .

If you want to associate the defect with a specific step, next to the step, click the Add Defect
button .
2. In the Add run step defect dialog box, fill in the relevant details for the defect and click Add.
The new defect form is automatically populated with the application module of the test
where the run originated, as well as the release that was chosen to run the test. Other
relevant fields are filled as well.
3. To link the run to an existing defect, click Link to defect, select the relevant defect(s), and
click Select.
4. Click to view a list of the defects for this run.

5. To copy test run steps to the defect's Description field, click Copy steps to description. This
helps you reproduce the problem when handling the defect.
l In a manual test, if the defect is connected to a run, all the run's steps are copied. If the
defect is connected to a run step, the steps preceding the failed step are copied. If there
are parameters in the test, only the relevant iteration is copied.
l In a Gherkin test, the relevant scenario is copied.
Add attachments to a run or step

It is sometimes useful to attach documentation to the run.
To attach items to a run or a step in a run:

1. Do one of the following, based on where you need to attach information:
l To attach to a test run: In the toolbar, click the Run Attachments button .
l To attach to single step: In the step, next to the What actually happened field, hover and
click the Add attachments button:

Testing
In the dialog, attach the necessary files. For details on working with attachments, see "Attach
files to items" on page 75.
Tip: Drag and drop from a folder or paste an image into the Manual Runner.
ALM Octane updates the Manual Runner to show the number of attached files:
Stop the run and see results

View the results after a complete test run to see the status and details.
To view the results:
After performing all steps, at the bottom of the ALM Octane Manual Runner window, click .
Note: If you have not marked all steps or validation steps, the run status is still listed as In
Progress. Finish entering and updating step details to change the status.
In the Runs tab of the test, click the link for your specific manual run and view the results in the
Report tab.
The report displays step-by-step results, including the result of all validation steps, and any
attachments included in the run. You can also see which phase the test was in when the run was
created.
Tip: To view test phase information for multiple runs, add the Test Phase column to the
Runs tab.

Testing
See also:
l "Plan and run test suites" on the next page
l "Link manual and Gherkin tests to automated tests" on page 248
l "Report and track product defects" on page 154
Run and edit manual tests in Sprinter

If you work with Sprinter, you can set up ALM Octane to edit and run your manual tests in
Sprinter, rather than in the Manual Runner.
Prerequisites:
l Both Sprinter and ALM Octane must be on the same client machine.
l Sprinter version 14.03 is supported.
To run and edit manual tests in Sprinter:

1. In ALM Octane click Settings , and toggle on Use Sprinter to run manual tests.
Tip: This capability is defined by the ENABLE_SPRINTER_USAGE site parameter. If you

do not see this option, contact your site admin to enable it.
2. When you are ready to run a manual test, click Run in ALM Octane.
Sprinter opens automatically, and you can run the test there.
3. The following ALM Octane actions will run a test in Sprinter: Run, Continue Run, and My

Testing
Work > Run.
4. To edit tests using Sprinter, in the Steps tab, click Edit in Sprinter .
Sprinter opens automatically, and you can edit the test there.
Note: ALM Octane is not able to verify that Sprinter 14.03 is installed on the same machine
as your ALM Octane client. If you set up the integration and are not able to edit or run
manual tests using Sprinter, check if Sprinter is installed properly on the same machine as
ALM Octane.
Next steps:
Plan and run test suites

After you create a test suite, you can plan the test suite run, assign the test runs to different users,
and view the results after the tests are completed.
In this topic:
l "Plan a test suite run" below

l "Run a test suite" on the next page
l "View the suite run results" on page 260
Plan a test suite run

Prepare the test suite to be run. Assign owners and environments to each of the tests.
To plan a test suite:

1. In the Quality module, select the Tests tab.
2. In the grid, select a test suite, and then in the toolbar, click Plan Run .
3. In the Plan Suite Run dialog box, define the suite run attributes. ALM Octane assigns the
values to all test runs for the tests in the suite.
4. Click Plan. ALM Octane creates the suite run and the test runs for the suite's tests. ALM
Octane displays the test runs in the Default owner's item list in the My Work module.
Tip: To add a test to a planned suite run, first add the test to the test suite, then right-click
the test in the Tests tabs and select Add to Suite Run.

Testing
After you plan a test suite run, ALM Octane adds a Planned tag to the available Run Status tags in
the Tags tab.
Run a test suite

When you run a test suite, the test suite runs as a collection of test runs. Assign test runs to
different owners and environments.
The test suite run process follows these steps:
To run a test suite:

1. Plan the test suite run. In the Tests tab of the Quality module or the Tests tab of a feature or
story in the Backlog module, select the test suite to run.
2. In the toolbar, click the Plan Run button.
Tip: If you want to run all the tests as a one-time run, click the Run button and enter
the run attributes. The tests are run in order.
If the suite contains executable automated tests, ALM Octane triggers the run on the
CI server in parallel to the manual run.
3. Assign suite run attributes. In the Plan Suite Run dialog, provide the suite run attributes.
When you have entered these details, click the Plan and Edit button to continue.
4. In the test suite, select the Suite Runs tab. ALM Octane displays a list of all suite runs.
5. In the list of suite runs, click on the link for your planned run. ALM Octane displays the suite
run details.
6. In the suite run, click the Runs tab. ALM Octane displays a list of all tests included in the suite.
7. Assign owners and attributes. In the list of test runs, in the Run by and Environment fields,
assign the test to the relevant user and specify the environment on which to run the test.
Environment is an information label. ALM Octane does not select or detect the environment
on which the test runs.
Tip: Update multiple test runs with the Bulk Update context menu option.

Testing
After you assign all the tests, the Runs tab displays the updated list:
The owner of the test run receives a notification of the assignment in the My Work area of
ALM Octane.
Tip: If you want to run a test twice as part of a suite run, in the Runs tab, select the
test and click the Duplicate Run button . ALM Octane adds the same test to the
list of tests.
8. Run the tests. Each assigned owner runs the tests as normal. For details, see "Run manual
and Gherkin tests" on page 251.
Owners run the tests from one of the following:
My Work module ALM Octane labels each assigned run with the name of the suite run
and a link to the individual test:
Select the test, and in the right pane of the My Work module, click Run
to start the test run.
Tip: If all tests in the suite are assigned to the same user, they
appear in My Work as a suite run. Select the suite and, in the
right pane, click Run.
From the In the Details tab or Runs tab of the suite run, click the Plan Entire
Backlog or Suite Run button .
Quality modules
If some tests are not assigned, select whether to run your assigned
tests with the unassigned tests or all tests in the test suite.
If someone must pause a test run, clicking the Continue Run button in the toolbar of the
Details tab or Runs tab of the Suite Runs tab in the test suite to resume the test run.

Testing
View the suite run results

When the suite's tests run, ALM Octane compiles the run results into a single report.
To view the suite run results:

1. In the Test Suite, click the Suite Runs tab.
2. In the list of suite runs, click on the link for the suite run you want to view.
3. In the suite run instance, click on the Runs tab. ALM Octane displays the list of all runs.
4. In the Runs tab, click the Report tab. The suite run report is then displayed:
Scroll or click the links to view each test in the suite, as well as the specific steps in each test.
The report also shows which phase each test was in when the run was created.
See also:
l "Create test suites" on page 249
Use versions of test scripts

Using native version control, ALM Octane tracks every saved version of your test.
In this topic:
l "Save test versions" on the next page
l "View versions" on the next page
l "Revert to a previous version" on the next page

Testing
l "Compare versions" on the next page

l "Manage releases assigned to versions" on the next page
Save test versions

ALM Octane uses different types of versions for tests:
l Unlabeled versions. Versions not named by you. If you do not enter a name, ALM Octane
creates a new test version each time you save the test. For automated Gherkin tests, view when
the script version is injected from an external source.
l Labeled versions. Versions named by you.
To create labeled versions:

1. After making changes in the Steps tab (manual tests) or the Script tab (Gherkin test), click
Save Version.
2. Enter a label and click Save.
View versions
It can be useful to view versions for comparison or other reasons.
To view versions of your test:

1. In the Steps tab (manual tests) or the Script tab (Gherkin test) for your test, click Versions.
ALM Octane displays the Versions View window.
2. By default, ALM Octane displays only named versions. To see all versions, clear Show major
versions only.
3. Look at each version.
For example, for automated Gherkin tests, identify if a script is injected from an external
source. In the Revision column, the 3rd digit on the right displays the relevant number, and
the Is external column displays Yes.
Revert to a previous version

At times, you may need to revert to an older version of a script.
To revert to previous versions of a script:

1. In the Steps tab (manual tests) or the Script tab (Gherkin test) for your test, click Versions.
ALM Octane displays the Versions View window.
2. Select the version and click Set as latest version.

Testing
This creates a new version with the same content as the version you selected. This new
version becomes the current and latest version. ALM Octane discards your current test script.
The Versions window closes and you return to your test.
Next time you open the Versions window, see Reverted to and the date and time of the
revert, listed as a new version.
Compare versions
Comparing versions of tests lets you see what has changed between versions.
To compare test versions:

1. In the Steps tab (manual tests) or the Script tab (Gherkin test), click Versions. ALM Octane
displays the Versions View window.
2. Select one of the versions you want to compare.
3. Click Compare. ALM Octane displays the Compare window. The selected versions display
side-by-side.
ALM Octane highlights the differences between the versions in yellow.
Manage releases assigned to versions

When you run a test, ALM Octane selects the version of the script associated with the release
assigned in the run details. Edit this association in case of a mistake or if you need to associate a
version without running it.
This is useful when planning or running tests from previous releases. Use the script version
associated with the previous release without the later changes.
To assign a version to a specific release:

1. In the Steps tab (manual tests) or the Script tab (Gherkin test), click Versions. The Versions
dialog box is displayed.
2. In the Releases column, click in the required row, and select a release from the drop-down list.
In the autocomplete search box, you can type numerical values to search for releases.
See also:
l "Create Gherkin tests" on page 237

Testing
Automate Gherkin tests

With your ALM Octane Gherkin tests, add them to an automation project and run them in your
CI server builds.
In this topic:
l "Gherkin automation process" below

l "Create and download the Gherkin test" on the next page
l "Add the OctaneCucumber runner class to your automation project" on page 265
l "Create a build job in Jenkins" on page 266
l "Add the build job to a pipeline" on page 266
l "Run the pipeline" on page 266
Gherkin automation process

When automating Gherkin tests, you use several components:
Component Purpose
ALM Octane Create and save the test, test scripts, and analyze the results
Your IDE Add automation for the test, through a .feature file included in a JUnit Runner
automation project.
Jenkins CI Runs the test as a part of a build/pipeline run

system

Testing
The entire process follows this flow:
Prerequisites
l Ensure the Application Automation Tools Jenkins plugin is installed and configured on the
CI server. For details, see "Install and configure the ALM Octane CI plugin on your CI server" on
page 406.
l Ensure that your automation project is set up as a Cucumber project.
Create and download the Gherkin test

To work with a Gherkin test in your IDE, you must create the test.
To create and download the test:

1. In ALM Octane, if necessary create and add scenarios to your Gherkin test. For details, see
"Create Gherkin tests" on page 237.
2. In the Scripts tab of the test, click the Download script button .
The script is downloaded as a .feature file.
3. Add the .feature file to your automation project.

Testing
Add the OctaneCucumber runner class to your automation project

To generate a Cucumber-based test results file that the CI server sends to ALM Octane, add the
octane-cucumber-jvm library to your automation project and use the OctaneCucumber class as the
test runner for your test classes.
The octane-cucumber-jvm library is supported for use on Java environments only.
To add the Cucumber classes:

1. In your project, add this dependency in your POM file:
<dependencies>
<dependency>
<groupId>com.hpe.alm.octane</groupId>
<artifactId>octane-cucumber-jvm</artifactId>
<version>12.53.22</version>
</dependency>
</dependencies>
Enter a <version> tag based on the version of ALM Octane you are using:
ALM Octane version <version> tag
ALM Octane versions 12.53.8 until 12.53.15 12.53.8
ALM Octane versions 12.53.16 until 12.53.18 12.53.16
ALM Octane version 12.53.19 until 12.53.21 12.53.19
ALM Octane versions 12.53.22 and higher 12.53.22

2. In your JUnit Runner .java file, import the Octane Cucumber runner class:
import com.hpe.alm.octane.OctaneCucumber;
3. In the JUnit Runner .java file, change the cucumber.class to OctaneCucumber.class:
Package feature.manualRunner;
import com.hpe.alm.octane.OctaneCucumber;
import cucumber.api.CucumberOptions;
import org.junit.runner.RunWith;
@RunWith(OctaneCucumber.class)
@CucumberOptions(plugin={"junit:junitResult.xml"},
features="src/test/resources/feature/manualRunner")

Testing
public class ManualRunnerTest{
Create a build job in Jenkins

In your Jenkins build job configuration, add a build step that runs the test.
In the post-build actions section, add an HPE Octane Cucumber test reporter step.
Note: If you add an HPE Octane Cucumber test reporter step, the CI server sends only the
Gherkin test results to Octane. Test results from other automated tests are not sent as
part of the build.
The post-build action instructs Jenkins to copy the test results XML files from the path specified
in the post-build actions to the Jenkins job build folder. From this build folder, the results are
copied to ALM Octane.
During the test run in the CI server, the OctaneCucumber runner generates a run results report
called <test name>_OctaneGherkinResults.xml in a dedicated folder called gherkin_results.
Note: If you are using the octane-cucumber-jvm library version 12.53.19 and earlier, the
file name of the results is called OctaneGherkinResults.xml.
If the post-build Cucumber test report step fails, the CI server fails the entire build.
Add the build job to a pipeline

Ensure that your build project or build job that runs the test is included in an ALM Octane
pipeline. When you run the pipeline, Jenkins generates the test results. The Application
Automation Tools plugin reads the results file and sends the details to ALM Octane.
For details on creating and working with pipelines, see "Create and configure pipelines" on
page 163.
Run the pipeline

To send the results to ALM Octane, you must run the corresponding pipeline.

Testing
To run the pipeline:

1. In ALM Octane or in the CI server, run the pipeline.
ALM Octane links the test results to the original Gherkin tests. ALM Octane uses the Test ID
tags found at the top of the .feature file and the test script in ALM Octane ALM Octane
assigns the test using these criteria:
l If the test already exists in ALM Octane and the Test ID tag is included in the .feature file,
ALM Octane does the mapping by the Test ID tag.

lIf the Test ID tag is not included in the .feature file, ALM Octane does the mapping by the
.feature script path.
l If the test does not exist in ALM Octane, the system creates a new test in ALM Octane and
maps the results to it.

2. Analyze the results in ALM Octane.
Next steps:
l "DevOps CI server integration flow" on page 162
Add automated tests

In ALM Octane, automated test entities represent a test from an external tool. Add these tests
and view the tests with other manual tests.
In this topic:
l "Overview" below
l "Creating automated test entities" on the next page
l "Add UFT tests from an SCM repository" on page 269
l "Add automated tests from runs in a pipeline " on page 269
l "Add automated tests from external test runs" on page 270
l "Assign tests to application modules and backlog items" on page 270
Overview
Automated tests are usually run by CI or automation servers, such as Jenkins or TeamCity, or by
ALM.
If you use UFT for automated tests, ALM Octane can create executable automated test entities
based directly on UFT tests. For details, see "Add UFT tests from an SCM repository" on
page 269.

Testing
The other way to add automated tests to ALM Octane is based on test run results. For details, see
"Creating automated test entities" below.
For ALM Octane to receive the test results, do one of the following, as described in the sections
below:
l Work with pipelines (see also "CI Pipelines" on page 159).
l Use the Test Result Collection Tools (see also "Send automated test run results to ALM
Octane" on page 271).
l Use the ALM Octane REST API (see the information about adding automated test results to
ALM Octane in the Developer Help.
Creating automated test entities

ALM Octane receives automated test run results from pipelines, test result collection tools, or the
API. ALM Octane creates automated test entities associated with the test run results, and adds
the results to the tests as test run entities.
If the relevant automated test already exists, ALM Octane adds the results as a test run to that
test.
For each test, ALM Octane stores the results of one run per test environment. If you run the test
again with the same environment configuration, the new results overwrite the old.
If the test ran with different settings this time, ALM Octane stores the results in a new test run
entity for the test.
ALM Octane maintains and displays basic information about the previous runs in a test run's
Previous Runs tab, in dashboard trend widgets, and in a pipeline run's Tests tab.
How does ALM Octane uniquely identify automated tests?

ALM Octane identifies each test by a unique combination of the following fields: Component,
Package, Class, Name.
When ALM Octane receives a test run, it checks these attributes to associate the run with a
specific test. If no existing test matches the run, ALM Octane creates a new automated test entity.
How does ALM Octane uniquely identify test runs?

Each test can have more than one run, each uniquely identified by Test, Environment, Pipeline,
and Pipeline Step. These are the test's Last Runs.
ALM Octane stores the details of a single Last Run for each unique combination of these
attributes. Each last run accumulates its own history of Previous Runs.
For example, if a test was run on Chrome and Firefox in two different releases, the test would
have four last runs.

Testing
How does ALM Octane uniquely identify automated Gherkin tests?

ALM Octane identifies aach Gherkin test in ALM Octane by its script feature's tag, if one exists.
The tag exists if the Gherkin test was downloaded from ALM Octane at some point. The script has
a tag that contains the test ID and revision in a format like this: @TID4002REV0.2.0.
When ALM Octane receives a Gherkin test run, it checks these attributes to associate the run with
a specific Gherkin test. If no existing Gherkin test matches the run, ALM Octane creates a new
automated Gherkin test entity.
How does ALM Octane uniquely identify Gherkin test runs?

Each Gherkin test can have more than one run, each uniquely identified by Test (which was
uniquely identified by its tag or path), Release, and Environment. These are the Gherkin test's Last
Runs.
ALM Octane stores the details of a single Last Run for each unique combination of these
attributes. Each last run accumulates its own history of Previous Runs.
For example, if a Gherkin test was run on Chrome and Firefox in two different releases, the
Gherkin test would have four last runs.
Tip: When working with pipelines, you configure a test's environment by configuring the
pipeline step that runs it. For details, see "Label steps according to job type" on page 169.
Add UFT tests from an SCM repository

If you use UFT for automated tests, the DevOps admin can store your tests in Git or SVN and set
up UFT integration. This lets you see your UFT tests reflected in ALM Octane as soon as you save
them, regardless of test runs. For details, see "Set up UFT integration" on page 421.
ALM Octane creates executable automated test entities based on the UFT tests in the SCM
repository. You can then run these UFT tests from ALM Octane as part of a test suite. For details,
see "Run UFT tests as part of a test suite" on page 276.
Add automated tests from runs in a pipeline

To add automated tests from test runs in an ALM Octane pipeline, perform the following steps:
1. "Set up CI servers" on page 403
2. "Create and configure pipelines" on page 163
3. Run the pipeline that contains the tests.
The test run results are sent to ALM Octane. ALM Octane creates or updates the automated test
entities associated with these results.

Testing
To enable the ALM Octane CI plugin to send the results to ALM Octane, make sure that the jobs
running the tests publish them to the CI server. For example:
l For StormRunner Load tests run by Jenkins, create a Publish JUnit test result report post build
step.
l For tests run by GoCD, declare the result xml-report-files as artifacts of your build.
Add automated tests from external test runs

If you run automated tests on ALM, or on a CI server not integrated with ALM Octane, you can
use the following to send your automated test run results to ALM Octane:
l ALM Octane API
l Test Result Collection Tools
ALM Octane creates or updates the automated test entities associated with these results.
For details, see "Push results to ALM Octane" on page 273.
Assign tests to application modules and backlog items

Assigning automated tests to application modules and backlog items in ALM Octane lets you view
the test results in context. You can then use these results to analyze the progress and quality of
your release and product.
Assigning owners to automated tests helps accelerate problem resolution. You can configure a
pipeline to notify test owners when their test runs fail.
For details on defining application modules or creating your product backlog, see "Work with
application modules" on page 148 and "Build the product backlog" on page 110.
To manually assign tests:

1. In ALM Octane, in the Tests tab (Quality or items of a Backlog module), click a test's link to
open it.
2. In the Backlog coverage field, select the relevant backlog items.
3. In the Application modules field, select the relevant application modules.
4. In Owner, select the relevant user.
To manually assign multiple tests:

1. In ALM Octane, in the Tests tab, select the relevant tests.
l Click Assign to Application Module and select the relevant application modules.
l Right-click and select Bulk Update. Click Select field, select Application modules or Owner,
and apply the relevant values.

Testing
To set up rules that automatically assign automated tests:

1. In the DevOps > Test Assignment Rules setting page, set up rules to assign automated tests
that match a filter you specify to specific application modules.
2. When you save a rule, ALM Octane assigns all current and future automated tests that match
the filter to the selected application modules and test owner. This includes tests currently in
the system, as well as new automated tests discovered in the future.
For details, see "Create and manage test assignment rules" on page 416.
Tip: Use the same rules to assign owners to automated tests, which can help accelerate
problem resolution.
You can also create test assignment rules from the Backlog or Quality modules. For details, see
"Create and manage rules to assign automated tests" on page 151.
Next steps:
Send automated test run results to ALM Octane

Incorporate automated test results into ALM Octane even if you do not use a CI server.
When ALM Octane receives test results, it creates automated test and test run entities from the
results. For details, see "Creating automated test entities" on page 268.
In this topic:
l "Set up API access" on the next page

l "Prepare your test results" on the next page
l "Decide how to send test results to ALM Octane" on the next page
l "Download a Test Result Collection tool" on page 273
l "Push results to ALM Octane" on page 273
l "Send automated test run results to ALM Octane" above

Testing
Set up API access

In order for the ALM Test Results collection tool to send results to ALM Octane or for you to send
results via the ALM Octane UI, you must have permissions to access the server. ALM Octane
grants this permission with an API access key.
For details on setting up API access, see "Set up API access" on page 305.
Prepare your test results

Store your automated test results in a valid XML file. Use one of the following formats:
A JUnit test Use the XML schema used by JUnit tests.

results XML
To view the full XML schema, see https://github.com/windyroad/JUnit-
file
Schema. For a description of the schema elements,
see https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_
9.5.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_
junit.html.
To relate the test results to ALM Octane entities, add additional information
about the tests (test type, environment details, release, and so on) in a separate
configuration file or by using the command line options of the test result
collection tools. For details, see the tool's readme.
An XML file If you have more complex cases, prepare the XML file according to the ALM
using API Octane test result API. For details, see Add automated test results to .
requirements
For an example, see "Test results XML sample" on page 274.
Decide how to send test results to ALM Octane

Use one of the following methods:
Test Results This tool sends automated test results stored in an XML file to ALM Octane.
Collection Tool These test results can be stored anywhere.
The tool requires an ALM Octane user name and password for
authentication.
ALM Test Retrieves the test results directly from ALM and sends them to ALM Octane.
Result Define filters that specify the test runs whose results you want to retrieve.
Collection Tool
The tool requires connection information for an ALM domain and project, as
well as a user name and password and ALM Octane API access.
Supports 12.* versions of ALM. Send test results from ALM test types
including MANUAL, UFT, LeanFT , and BPT tests.

Testing
Use the ALM Use REST API calls to send test results to ALM Octane without the test
Octane API results collection tools.
For details, see the information about adding automated test results to ALM
Octane in the Developer Help.
Download a Test Result Collection tool

2. Click the DevOps tab. Then, in the left side of the pane, select CI Servers.
3. Click the link to download the Test Result Collection tool or the ALM Test Result Collection
tool.
Save the download to a directory of your choice.
4. Unzip the downloaded file and move it to the necessary directory.
Push results to ALM Octane

To push test results stored outside an ALM server or on an ALM server, use the command line to
run the test result collection tool. The command line options for this tool enable you to provide
the necessary results, metadata, and configuration options as part of the command line or in a
separate configuration file.
For details, see the readme files:
l Test Results Collection tool: https://github.com/MicroFocus/octane-collection-
tool/blob/master/test-result-collection-tool/src/main/assemblies/content/readme.txt
l ALM Test Results Collection tool: https://github.com/MicroFocus/octane-collection-
tool/blob/master/alm-test-result-collection-tool/src/main/assemblies/content/readme.txt
Track your test results in ALM Octane

Within ALM Octane, there are a number of fields available to find your test results. Add these
fields in the module grids or Dashboard graphs:
To track test results:
1. In the Backlog or Quality modules, add the Testing tool type column. By default, this column
reports tests from the Manual Runner, Selenium, UFT, LeanFT , StormRunner Load, SoapUI,
Protractor, LoadRunner, and Performance Center.
Filter or sort the grid accordingly to see results from these testing tools.
2. In Dashboard grids, filter by the Testing tool type attribute. ALM Octane sorts the graph to
display tests with each testing tool type.
3. For tests pushed from ALM, use the Component, Package, and Class Name columns in the
Backlog and Quality modules. These columns are marked accordingly to identify the test

Testing
results origin from ALM.

In addition, test names in ALM Octane add an identifier to test name to show it originated in
ALM.
4. Once the test results are in ALM Octane, set up test assignment rules to assign retrieved test
results to the relevant application modules and ALM Octane users. For details, see "Create
and manage test assignment rules" on page 416.
See also:
l "Add automated tests" on page 267
l "Test results XML sample" below
l "Run automated tests from ALM Octane" on the next page
Test results XML sample

This sample XML shows the required format to use to send automated test results to ALM Octane
with the Test Result Collection tool.
For details on setting up this tool, see "Send automated test run results to ALM Octane" on
page 271.
For details on the structure to use for this XML, use the ALM Octane API to retrieve the XSD
schema of the payload using a GET operation: GET .../api/shared_spaces/<shared_space_
id>/workspaces/<workspace_id>/test-results/xsd
For details, see test-results in the Developer Help.
Sample XML:
<?xml version="1.0" encoding="UTF-8"?>

<test_result>
<build build_id="31" job_id="Test-REST" server_id="12345678"/>
<test_runs>
<test_run started="STARTED_TS" status="Skipped" duration="14"
name="bandTestA" class="BandTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
<test_run started="STARTED_TS" status="Passed" duration="0"
name="bandTestB" class="BandTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
name="bandTestC" class="BandTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
name="bandTestD" class="BandTest" package="com.mycomp.devops.demoapp"

Testing
module="webapp"/>
name="bandTestE" class="BandTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
name="always_true_A" class="CalcsTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
name="always_true_B" class="CalcsTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
name="always_true_C" class="CalcsTest" package="com.mycomp.devops.demoapp"
module="webapp"/>
</test_runs>
</test_result>
Run automated tests from ALM Octane

In ALM Octane, most automated tests run as part of a CI/CD pipeline. UFT tests that were
discovered using UFT integration run as part of a test suite.
The tests are run by automation tools and the results are sent to ALM Octane.
l When working with pipelines, CI servers such as Jenkins and TeamCity, run the automated
tests.
l When working with UFT integration, Jenkins manages the UFT machines, similar to Lab
Management in ALM.
In this topic:
l "Run automated tests as part of a pipeline" below

l "Run UFT tests as part of a test suite" on the next page
l "Run automated tests from ALM Octane" above
l "Troubleshooting a UFT test run" on page 277
Run automated tests as part of a pipeline

If you set up CI server integration, ALM Octane receives the results of automated tests that run in
a pipeline on your CI server. ALM Octane then creates or updates the relevant automated tests
and test runs based on those results. For details, see "Set up CI servers" on page 403 and
"Creating automated test entities" on page 268.
You can trigger pipeline runs from ALM Octane, but not individual test runs.

Testing
Note: If you do not run your automated tests on a supported CI server, you can still send
automated test run results to ALM Octane. For details, see "Send automated test run
results to ALM Octane" on page 271.
To run automated tests as part of a pipeline:

1. Prerequisite: Set up a pipeline and run it, so ALM Octane discovers your automated tests.
This includes setting up integration with your CI server, creating a pipeline in ALM Octane,
and running it for the first time. For details, see "Add automated tests from runs in a pipeline "
on page 269.
2. Running automated tests again: To run your automated tests again, and have the updated
results sent to ALM Octane, you must run the whole pipeline. For details, see "Run pipelines"
on page 175.
This runs all automated tests included in steps of the pipeline.
3. View run results. Open individual automated tests in the Backlog or Quality module to view
their results, or open the Pipelines module to view details about all the tests in the pipeline.
Run UFT tests as part of a test suite

If you set up UFT integration, ALM Octane continuously reflects any UFT tests and data tables
that it discovers in your repository. This lets you plan and trigger UFT test runs from ALM Octane
by including the tests in test suites. For details, see "Set up UFT integration" on page 421.
To run automated tests as part of a test suite:
1. Prerequisite: Set up UFT integration so ALM Octane continuously discovers your UFT tests
and data tables.
ALM Octane creates executable automated tests to represent the GUI and API UFT tests.
You can run these tests from ALM Octane by including them in a test suite. Only UFT tests
discovered this way are executable. For details, see "Add UFT tests from an SCM repository"
on page 269.
2. Add executable UFT tests to a test suite. In ALM Octane, open the Quality module or a
Backlog module. In the Tests tab, add one or more executable automated tests to a test suite.
For each test, you can specify a data table to use for parameterizing the test run. For details,
see "Create test suites" on page 249.
You can also create a mixed suite that contains manual and automated tests.
3. Plan and run the test suite. For details, see "Plan and run test suites" on page 257.
4. View run results.
The run results are explained in detail in the report provided by UFT. For example, you can
find the name of the test, the UFT machine that ran it, the duration of the run, the data table
and parameters that it used, details about the success or failure of each step.

Testing
To view the run status and run results report:

a. In ALM, in a test suite, open the Suite runs tab.
b. Click the ID of a suite run to open it.
c. In the suite run, open the Runs tab to view all of the test runs.
While the test is running, the run status is In progress. After the run finishes, the results
are available in the UFT report and the status shows Passed or Failed.
If the test runs finished and the status still shows In progress, try refreshing the list of
runs.
d. Click the ID of a test run to open it for more detailed results.
Click the Testing tool report button in the upper right corner of the test run to open
the UFT report. The image below shows an example of a UFT report:
e.
Troubleshooting a UFT test run

If ALM Octane failed to run an executable automated test that is included in a suite run:
1. Check the UFT report for details about why the test failed.
2. Make sure you set up UFT integration correctly. For details, see "Set up UFT integration" on
page 421.
3. Make sure that the UFT machine is not logged off or locked.

Testing
Tip: If you install UFT version 14.01, you can run UFT tests when the computer is
locked, as long as you configured the disconnected remote connection option.
4. For more details on automated test run failures, see "Examine failures from test runs" on the
next page.
See also:
l "Analyze automated test run results" below
Analyze automated test run results

After automated tests run, analyze the results at the test level or pipeline level or the test run
level.
In this topic:
l "What are you analyzing?" below

l "Examine failures from test runs" on the next page
l "Examine test failures from a pipeline" on page 281
l "Examine test results in an external tool" on page 281
l "Examine overall automation test results" on page 281
What are you analyzing?

When you examine a test result (success or failure), there are many places to examine:
l Details about the root cause of the failure.
l Details about the pipeline run/build in which a specific run failed.
l Previous run history. This also includes seeing when, how frequently, and why the test is failing,
and to check whether it is always due to the same problem or different causes.
l Error messages and types

Testing
Examine failures from test runs

1. In the Backlog, Team Backlog, or Quality module, select the Tests tab.
Tip: Select the Latest pipeline run tag to exclude automated tests skipped or
removed from the pipeline's latest run. The display includes manual tests, executable
automated tests, and automated tests that ran as part of a pipeline's latest run.
If a new pipeline run is in progress, some tests that ran on the previous pipeline run
are still included.
2. Click the ID of a specific automated test.

3. Select the Runs tab. This tab includes one test run entity for each set of environment settings
on which the test ran. Each entity contains detailed information about the last time the test
ran with these environment settings and basic information about the previous runs.
Tip: In the test run grid, add the Problem column to see whether the test has a history
of unsuccessful runs. For details, see "Identify problematic tests" on page 205.
4. Click the ID of a specific failed test run.

5. In the Details tab:
a. Hover over the Build status icon to view build failure and details about the build in
which this specific run failed, including when the build failure occurred, and the number
of tests that passed, failed, or need attention. If at least 1 test fails, ALM Octane
considers the entire Build as failed.
b. Check Who's on it? to find out who is investigating this failed test.
If you assign someone to investigate the test, this assignment remains on subsequent
failed runs of the test. The assignment is cleared when the test passes successfully.
Tip: To have an email notification sent to the person you assign, assign Who's on
it? in the Tests tab of a pipeline run. For details, see "Expand your test failure
analysis" on page 196.
c. Click the Testing tool report button to navigate to the report created by the testing
tool that ran the test, when applicable.
d. Click the Custom build report button to open a build report stored on your CI server
or elsewhere.

Testing
This link is provided if a DevOps admin configured a template for such links on the
pipeline step. For details, see "Label and configure pipeline steps" on page 169.
e. Click the Pipeline links to navigate to the pipeline and to a particular run of the pipeline
(marked by #).
Tip: To add the Pipeline links column to the grid, use the Choose columns
button.
6. In the Error Info section, view the Error message, Error type, and Error details. The Error Info
fields are only populated for failed test runs. If the error details are truncated in the fields,
click Show all details to display the error details in full view in a new tab.
When a test fails, the failure cause (stack trace) is sent to the server. ALM Octane users can
immediately see the reason.
7. On the top-right of the Details tab, click Show in <source> to view the test results in the
CI server.
8. In the Previous Runs tab:
a. View a list of previous test runs and related build failure and error information, including
message, exception, and stack trace.
b. Filter the run history per specified failure or error criteria. For example, you can filter by
run status to view only failed runs so you can immediately identify and resolve them. You
can also filter by time duration, build status, and substrings in error messages, exceptions,
and stack traces.
c. In the tooltip of the previous run, click the Testing tool report link to navigate to the
report in the external system that produced this run, when applicable.

Testing
d. Click the Pipeline links to navigate to the pipeline run (marked by #) and to the pipeline.
9. You can create a defect based on this run by clicking Report defect.
Examine test failures from a pipeline

For a pipeline-level analysis, use a pipeline run's Tests tab. For details, see "Test run details" on
page 192.
Examine test results in an external tool

For StormRunner Load or StormRunner Functional tests, in the Tests tab, click the Testing tool
report button to open the detailed StormRunner Load or StormRunner Functional report.
Examine overall automation test results

In addition to examining a single test's run results, it is possible to view overall status for all the
automation test results.
To analyze test results for multiple automation test runs:

1. Ensure that ALM Octane has discovered and created the automation run results and tests.
For details, see "Add automated tests" on page 267.
2. Access your run results, from:
Dashboard or Use any Dashboard widget used to assess quality through test run
Overview tabs of results.
the Backlog and In the Scope tab of these graphs, ensure that you add a filter using the
Quality modules Subtype attribute with a value of Automated Run.
In addition, add filters for to view automated tests from a specific
Pipeline, or a specific Package, Component, or Class.

Analysis and reporting
Pipelines module The main page of the Pipelines module displays per-pipeline
information about all the automated tests included in that pipeline.
This includes information about the application modules with failed
tests, problematic tests in recent runs, and so forth.
Use this information to isolate the automated test run per pipeline and
view these run as part of the product build.
See also:

ALM Octane contains the information to analyze development quality. Track quality in the
Backlog, Quality, Pipelines modules, or the Dashboard.
Tip: Also, with OData support, you can generate sophisticated reports that directly access
ALM Octane entities to help with your analysis. For details, see "OData support for
extended reporting (technical preview)" on page 452.
In this topic:
l "Analyze release quality" below

l "Transition from release to product quality" on the next page
l "Analyze product quality" on page 285
l "Analyze build quality using pipeline data" on page 286
l "Use-case scenario: Performing quality analysis" on page 287
Analyze release quality

To analyze release quality, ensure you associate tests and defects with features, user stories,
requirements, and defects, using:
l The Backlog Coverage field in a test
l The Covered requirement field in a test
l The Feature field in a defect
Associating tests and defects enables ALM Octane to provide better quality analysis.

To analyze release quality, use any of the following:

Backlog module Use different grid columns including:
l Defect count
l Risky commit count
l Test Coverage
The Test Coverage widget summarizes the last unique native run
statuses for each test. If you run a test with the same configuration as
a previous test run, ALM Octane updates the new result.
Hover over the widget to open the detailed run results or click View
runs link to view a filtered list of the last runs.
Backlog module, View test run results by adding different widgets, including:
Overview tab and
l Feature quality status
Dashboard module
l Open defects by feature
l Defect daily injection
To see a specific epic or feature, select the node in the backlog tree. In
the Dashboard, add a filter to display items relevant to your release.
Backlog module, ALM Octane displays a risk icon for features associated with risky
Features tab commits. You may want to increase testing on these features or
postpone their release.
For more details, see "Identify risky commits and features at risk" on
page 210.
Note: Charts and graphs based on test runs display only the following summarized run
statuses: Passed, Failed, Planned, and Blocked. Each individual, native test run status falls
into one of these categories. This is for clarity of analysis.
Transition from release to product quality

When you first create tests, you usually create tests of a specific feature assigned to a release.
For example, you have a feature to improve the shopping cart area of the application . In the
Backlog release tree, there is a feature node for the shopping cart. The feature contains user
stories. Each user story has acceptance tests.

Example:
Feature: Shopping Cart
User Story: Adding to cart
Test: Adding one item to cart
Test: Adding multiple items to cart
Test: Adding from wish list to cart
To track product quality, use the same tests. Group them in the context of an application module,
such as product navigation:
Example:
Application module: Navigation
Sub-application module: Adding to cart
You can also use the tests for other functional areas:
Example:
Application module: Navigation
Sub-application module: Adding to cart

Application module: Multiple selections
Test: Deleting multiple items from cart
In doing this, you change from testing release quality to testing product quality.
Analyze product quality

To analyze product quality, ensure that you associate features, user stories, defects, and tests
with application modules.
ALM Octane uses the test results and defect analysis to paint a picture of application health
across releases. Using these measures, you gain a global picture of your application's quality at a
specified point.
To analyze product quality, use any of the following:

Quality module Use different grid columns including:
tabs
l Defect count
l Risky commit count
l Last runs
The Last runs widget summarizes the last unique native run statuses
for each test. If you run a test with the same configuration as a
previous test run, ALM Octane updates the new result.
Hover over the widget to open the detailed run results or click View
runs link to view a filtered list of the last runs.
Quality module, View test run results by adding different widgets, including:
Overview tab and
l Open defects by application module
Dashboard module
l Run status by application module
l Quality by application module
To see application module, select the node in the application module

tree. In the Dashboard, add a filter to display items relevant to your

Analyze build quality using pipeline data

ALM Octane collects information about pipeline runs, build failures, automated test runs, and
SCM commits.
Link this information with your backlog and application modules to provide a comprehensive
picture of the connection between your build quality, and your release and product progress and
quality.
Track and analyze pipelines in Dashboard widgets and in the Pipelines module.
DevOps and Analytics dashboard widgets

In the Dashboard, select widgets from the DevOps and Analytics section or create custom graphs
based on pipeline information.
Create a custom widget, and in Scope > Item type, select Pipeline runs, Test runs, Test run history
(automated), or Commits.
If you add tags to your pipeline runs, you can use a graph to view pipeline runs, divided according
to your tags.
Example:
1. Add tags to your pipeline runs that describe different reasons for pipeline run failure.
For example,
l Database problem
l Broken builds
l Out of memory
l Merge issues
2. Use the Pipeline runs by failure type widget to see how many of your pipeline runs are
failing for each reason you listed.
Automated test run history widgets
A custom graph based on the item type Test runs displays only the tests' last runs.
To create a graph that includes automated test runs from the past, select the Item type: Test run
history (automated).
l The graph displays the number of automated test runs per category. The Y Axis is set to Count
and you configure in the category in the X Axis. For example, you can see the number of runs
per pipeline, environment, or release.
l To view the list of test runs, click a column or category in the graph.

Filter the graph by Pipeline run to see the automated test runs from specific pipeline runs.
Caution: If you filter based on Latest pipeline run, you can filter by Pipeline as well, but do
not filter by Pipeline Run.
Analyzing builds in the Pipelines module

In the Pipelines module, you can find several layers of information.
l The Live Summary tab provides a high level live view of each pipeline's history, its current
status, and its progress.
In the Pipelines tab, you can see all the pipelines that are being tracked, and filter to see the
ones that interest you.
You can see summary information about each pipeline's last completed run, and more detailed
information about the selected pipeline.
l You can open an individual pipeline or pipeline run to learn more about its status, its run
history, related code changes, affected application modules, and more.
You can also find analytic information about failed tests and tools to help you analyze failures.
For details, see "Run pipelines" on page 175.
Use-case scenario: Performing quality analysis

Mark, a product manger, handles the development of a basic mobile chat application. Throughout
the release, he needs to check the quality of the development work.

In the Dashboard module, he adds widgets to assess quality:
Feature Quality
Status
This enables him to

see quality by
comparing the total
number of test runs
and the status of
each.
Open defects by
severity
This enables him to

see the problems
based on open
defects.

Features by risky
commits
This enables Mark to
recommend further
regression testing
before finishing the
release.
Quality by
application module
This graph enables

him to see the quality
of each area of the
application.
Mark can configure
the Criteria to use to
determine the level
of quality. For
example, he can use
the number of
defects, percentage
of failed tests, or
percentage of risky
commits.
See also:
l "Use the ALM Octane Dashboard" on the next page

Use the ALM Octane Dashboard

The ALM Octane dashboard is the control center for analysis. It gives a visual, customizable
display of development progress and quality.
l "What is the dashboard?" below

l "Set up the dashboard" below
l "Configure widget data settings" on the next page
l "Use dashboard widgets for analysis" on page 293
What is the dashboard?

The dashboard is a collection of widgets displaying data about development progress and quality,
including widgets for:
l Tracking progress
l Quality
l Content Planning
l Test Coverage
l DevOps and Analytics
If the out-of-the-box widgets are not enough, create a custom widget to display your data.
Tip: Perform similar analysis in the Quality and Backlog modules, in the Overview tab and
in the Pipelines module's main page.
Also, with OData support, you can generate sophisticated reports that directly access ALM
Octane entities. For details, see "OData support for extended reporting (technical
preview)" on page 452.
Customize the graphs, including the type of data reported, the scope and time frame, and the
widget groups and displays the data.
You can also configure how you want to view widgets and save different widgets as favorites.
Set up the dashboard

In the ALM Octane banner, click the menu button and select Dashboard or select the
Overview tab in the Backlog/Quality modules.

1. In the toolbar, click the Add Widget + button.

2. In the Widget Gallery, select a category and a widget within the category or click Add custom
graph. Use the tabs in the Widget Editor to set up and configure your widget.
Tip: Don't know exactly which widget to use? Read the description of the widget to
see which questions this widget helps you answer.
3. Click Add to Dashboard. ALM Octane adds the widget at the bottom of the dashboard.
4. Repeat as necessary to suit your needs.
5. In the toolbar, click the Configure layout button and select the necessary layout. Drag
and drop widgets as needed.
ALM Octane maintains the specific widgets and layout between sessions.
Configure widget data settings

1. In the right corner of the widget, click the widget menu button and select Configure.
Tip: If you want to duplicate a current widget configuration as a starting point, in

widget menu, select Duplicate. ALM Octane adds an widget named Copy of <Widget
Name>.
2. In the General tab, select the graph type and update the name and description as needed.
3. In the Scope tab, define the scope of the data to display, including:
l Workspace
The workspaces from which ALM Octane should compile the graph's data. To use this
field, the workspace must be associated with a shared space.
Enterprise edition: Using this field, you can define dashboard widgets that display cross-
workspace information.
Choose All my workspaces to compile data from all workspaces in which I am a member.
The Workspace field is not supported for agile graphs, including the Burn Up, Burn Down,
and Cumulative Flow graphs.
l Item type
l Release
4. For trend-based graphs (Status over time), specify a time frame:

Without a If you select:

release l the All <items> up to now option, the graph contains every item of the
specified selected type from the beginning of your project until now.
l A specific period, the scope (last 24 hours, last 7 days, and so on) means
last <time period>" up to now. For example, the "Last week" means the
previous week until now.
With a If you select:

release l All <items> up to now, the graph includes the selected item type from the
specified beginning of the specified release until now.
l Release period, the graph includes the selected item type from the start
date to the end date of the release.
l All {items} up to end of release the graph includes items created or
updated from the beginning of the project until the end of the release.
l All {items} from start of release up to now, the graph includes items
created or updated from the start date of the release until now.
Note: When using trend based graphs (for example, Burn Up or Burn Down charts), if
one of the sprints includes a day with a clock change, the graph tooltips exclude the
day, week, or month with the time change. The excluded period depends on the scope
you set in the graph configuration.
For example, if a sprint includes the day the clock switches for Daylight Savings time,
the tooltips exclude this day, week, or month.
5. In the Scope tab, define conditions for filtering dashboard widgets. For details, see Filter
items.
If you select more than one workspace in the Workspaces field, filters display the fields
common to all selected workspaces. Certain reference fields (such as Application Modules or
Features) are not available for use in cross-workspace graph filters.
If you update the workspaces that are selected or open the same graph in a different
workspace, ALM Octane clears the existing filters.
6. In the Display tab, set the display options, including what to display on the x-axis and y-axis
of the graph, and how to group the displayed data. Use the following options:
Double Display a widget in an extra-long vertical format. By default, grids are displayed
height as double-height.

Grid Summary graphs can be displayed in a grid format. (Trend-based graphs

format cannot be displayed as a grid.) Each graph source such as defects or tests has
default columns defined, which you can change as needed.
l The grid limit is the maximum number of rows displayed, from 0 (no limit) to
100. The default is 25 rows.

l When setting up a grid, you can select up to two fields for sorting. These
fields correspond with the x-axis and group-by fields of graphs. If you select
a field that cannot be used for sorting, an informational message appears in
a tooltip next to the field name.
l On some grids (depending on source type), you can drill down into the grid
rows to view full entity details.

l If you click Export Report on a grid, the report is exported with full report
data as if it were a graph, independent of the grid filtering settings such as

number of rows.
Tip: Grid widgets can display cross-workspace information. For

example, you can show the highest-severity defects from all workspaces
in a shared space (Enterprise edition).
Include In some graphs, to include data from features or application modules with no
empty associated or assigned items, select the Include empty columns in graph
columns option.
Show Counts all status changes in a given time-frame, and not only the final state of
trend of each entity. For example, suppose you want to see how many defects were
changes opened and closed in each day, giving you a picture of overall trend. You can
use the Defect daily injection graph to see how many defects were opened and
closed by your team, over a two-week period.
7. Click Save. ALM Octane updates the graph according to your selections.
Use dashboard widgets for analysis

After you add and configure widgets, use them to perform in-depth analysis:

View more For the different sections in a graph, hover over the section to see a tooltip with
details details:
Open Click on a section of a graph to display and drill down on the items referenced in
referenced the sections of the graph:
items
If you click on a section of a graph compiled from more than one workspace:
l If the item is from the current workspace, it opens in the same tab.
l If the item is from a different workspace, it opens in a separate tab.
Display and drill down on reference items (such as features or application

modules) is not available for trend-based graphs.

Hide/Show Click an item in the widget's legend to show or hide data in the widget.
data
Example: In the widget on the left, we clicked New and Ready for R&D to hide
features that are not yet ready to be documented. On the right, the items are
hidden, and you can see that the widget items are not selected.
Read For trend-based graphs, drag the mouse along the trend line to see a period-by-
values period detail:
along the
timeline

Export For certain graphs, click the menu button and select Export report. ALM Octane
items to uses the items highlighted in the graph and downloads them in an Excel file.
an Excel
file
Export To export a widget as an image, click the menu button and select Export image.
image ALM Octane downloads the graph as an image file.
Note that Internet Explorer is not supported.
See also:

Integrations
ALM Octane can seamlessly integrate with other lifecycle management tools, to provide a
comprehensive picture of your project management, product quality, build progress, and more.
Set up direct integrations using ALM Octane's built-in offerings, or use ALM Octane's REST
API to integrate with applications of your choice.
In this topic:
• ALM Octane DevOps integrations 298
• Overview 298
• IDE integrations 299
• Source Code Management (SCM) integrations 299
• Build automation: CI server integrations 299
• Testing tool integrations 300
• Security testing integrations 301
• Integrations with Commercial Off the Shelf software (COTs) 301
• Monitoring tool integrations 302
• Additional integrations using the REST API 302
• Functionality supported by CI integrations 302
• Functionality supported by IDE integrations 304
• Access and credentials 305
• Set up API access 305
• Set up credentials 309
• Synchronization 310
• Set up the Integration Bridge Agent 311
• Synchronize ALM Octane with ALM or JIRA 343
• DevOps integrations 403
• Set up CI servers 403
• Set up your SCM system 413
• Create and manage test assignment rules 416
• Manage all build failure classification rules 419
• Testing integrations 420
• Set up UFT integration 421
• Set up security testing integration 427
• ChatOps integrations 429
• Set up Slack 430
• IDE integrations 432
• Work in IntelliJ IDEA 433
• Work in Eclipse Oxygen IDEs 440
• Work in the Microsoft Visual Studio IDE 448
• Reporting integrations 452
• OData support for extended reporting (technical preview) 452

ALM Octane DevOps integrations

Extend ALM Octane's capabilities by connecting to other systems you use in your release lifecycle.
ALM Octane connects the dots from the various tools, providing comprehensive end-to-end
control of the lifecycle.
This topic describes the integration options that ALM Octane provides.
In this topic:
l "Overview" below
l "IDE integrations" on the next page
l "Source Code Management (SCM) integrations" on the next page
l "Build automation: CI server integrations" on the next page
l "Testing tool integrations" on page 300
l "Security testing integrations" on page 301
l "Integrations with Commercial Off the Shelf software (COTs)" on page 301
l "Monitoring tool integrations" on page 302
Overview
This diagram displays the tools that ALM Octane integrates with at each stage of your
application's lifecycle.
To configure some of these integrations and use these tools, DevOps permissions are required.

IDE integrations
Work with ALM Octane from within your development IDE.
Integration How?
IntelliJ See "Work in IntelliJ IDEA" on page 433.
Eclipse See "Work in Eclipse Oxygen IDEs" on page 440.
Microsoft Visual Studio See "Work in the Microsoft Visual Studio IDE " on page 448.
For a feature support matrix, see "Functionality supported by IDE integrations" on page 304.
Source Code Management (SCM) integrations

Via integration with your CI server, track changes committed to your Source Control Management
system. For details, see "Track changes committed to your Source Control Management system"
on page 199.
ALM Octane imports SCM information via the integrated CI server.
Depending on the CI server you use, ALM Octane supports the following SCM systems:
CI server Supported SCM systems

Jenkins Any SCM system supported by Jenkins
Bamboo Git, SVN
TeamCity Git, SVN
TFS Git
GoCD Git
The following functionality is available only if you use Git or SVN:
l Repository information for commits.
l Links to diff and file repository viewers for changed files.
Build automation: CI server integrations

ALM Octane incorporates data from your CI pipelines into your application delivery process,
helping you analyze quality, progress, change impact, code coverage, and more. For details, see
"CI Pipelines" on page 159.

Plugins for Jenkins, TeamCity, Bamboo, TFS, and GoCD are available online. For Jenkins, this
functionality is part of the Application Automation Tools plugin.
For a list of functionalities supported by each CI server integration, see "Functionality supported
by CI integrations" on page 302.
For other CI servers, build your own plugin in Java using the CI Plugin SDK for ALM Octane
available on GitHub.
Testing tool integrations

ALM Octane incorporates tests and results from various sources into the overall product and
release data.
Integration How?
Micro Focus testing tools: LeanFT, UFT, Use the Pipelines module in ALM Octane and
LoadRunner, StormRunner Load, integrate with your CI server.
StormRunner Functional, Performance
ALM Octane receives testing tool test run
Center
results from the pipeline runs.
See "Automated testing flow (pipelines)" on
page 226.
Note: StormRunner Functional

integration requires Application
Automation Tools plugin version 5.3
and later.
Unified Functional Testing (UFT) Set up UFT integration without pipelines.

ALM Octane discovers UFT tests and data
tables stored in Git or SVN, enabling you to run
the tests in ALM Octane test suites.
See "Set up UFT integration" on page 421 and
"Run UFT tests as part of a test suite" on
page 276.
ALM test result tracking Via the ALM Test Result Collection Tool
See "Send automated test run results to ALM
Octane" on page 271.

Integration How?
Sprinter Run ALM Octane manual tests in Sprinter.
See "Run and edit manual tests in Sprinter" on
page 256.
Third-party testing tools and frameworks, Via pipelines, using an ALM Octane CI plugin.
such as Selenium, NUnit, JUnit, and TestNG.
See "Set up CI servers" on page 403.
Security testing integrations

Track your security issues as defects in ALM Octane:
Integration How?
Fortify on Set up integration with Fortify on Demand, enabling each ALM Octane pipeline
Demand run to display the new security vulnerabilities found on that run. For details, see
"Set up security testing integration" on page 427.
Fortify The Fortify BugTracker Utility enables you to open security defects on ALM
Octane directly from Fortify. For details, see the Micro Focus Fortify Marketplace
page.
Integrations with Commercial Off the Shelf software

(COTs)
ALM Octane integrates with the following COTs:
Integration How?
ALM defect, Via ALM Octane Synchronizer
requirement, and
See "Synchronize ALM Octane with ALM or JIRA" on page 343.
release
synchronization
JIRA defect and Via ALM Octane Synchronizer

backlog
See "Synchronize ALM Octane with ALM or JIRA" on page 343.
synchronization
Project and Portfolio See Integrations with ALM Octane.

Management (PPM)

Integration How?
Slack Add your ALM Octane workspace to a Slack workspace and open
Slack channels from within backlog items or pipeline run failures. See
"Set up Slack" on page 430.
Third-party See the Micro Focus AppDelivery Marketplace page.

applications
Monitoring tool integrations

Track issues found on your production systems as ALM Octane defects:
Integration How?
AppPulse Configure ALM Octane as a defect management tool in AppPulse Mobile, and
Mobile log defects on ALM Octane directly from AppPulse Mobile. For details, see the
AppPulse Mobile documentation.
Additional integrations using the REST API

Expand your integrations to applications of your choice by using ALM Octane's REST API.
Integration How?
Other third-party applications or CI REST API, OData, and SDKs. For details, see the
servers Developer Help.
See also:
l "DevOps integrations" on page 403
l "IDE integrations" on page 432
Functionality supported by CI integrations

Integrating ALM Octane with a CI server enables varied functionality.
The table below specifies the functionality provided by each CI server integration, when using the
latest version of the plugin.
Functionality Jenkins Bamboo TeamCity GoCD TFS

Collect pipeline step results

Functionality Jenkins Bamboo TeamCity GoCD TFS

Collect test run results
Collect SCM commit messages
List the files in a commit
Understand the type of file change in a

commit (add/edit/delete)
Run pipeline from ALM Octane
Hierarchy in Topology
Ignore test run results for specific

pipeline steps
Multi-branch pipeline N/A N/A N/A N/A
Automatically set a test run's testing

tool / test type
Configure instance ID in CI plugin
Collect code coverage reports
Collect failed build logs, configure

automatic build failure classification
See also:
l "ALM Octane DevOps integrations" on page 298

Functionality supported by IDE integrations

IDE integrations let you work with ALM Octane from within your development IDE. These
integrations synchronize ALM Octane My Work items with the IDE, so you see up-to-date
information.
The table below specifies the functionality available for each IDE, when working with the latest
version of the plugin.
Visual
Functionality IntelliJ Eclipse
Studio
Requirement synchronization
Backlog item synchronization
Task synchronization
Manual test synchronization
Gherkin test synchronization
Run synchronization
Search items by ID, name, and/or description
See an item's details, including comments
Modify an item's details
Add comments
Change the phase of an item
Set items as "active"
Open item in browser
Add items and dismiss them
Download Gherkin test scripts

Access and credentials
Visual
Functionality IntelliJ Eclipse
Studio
Auto-generate a commit message prefix with the
item ID
The prefix is Copy and Copy and
added paste the paste the
automatically prefix in prefix in
to the the commit the commit
commit message message
message
Extract workspace / space from the URL in

settings
Test connection in settings
See also:
l "IDE integrations" on page 432

This section provides integration instructions for granting ALM Octane access to external
applications, and granting other applications access to ALM Octane.
Topic Description
"Set up API access" Grant access to ALM Octane by other applications by creating
below registered access keys for these applications.
"Set up credentials" Let ALM Octane access other applications with credentials.

on page 309
Set up API access

For applications to access ALM Octane, you must grant them registered access keys. These
applications use the access keys for authentication when communicating as clients with ALM
Octane.
In this topic:
l "Integration types" on the next page
l "SaaS: Internal integration types" on page 307

l "Create API access keys" on page 308

l "Modify API access keys" on page 308
l "Revoke API access" on page 309
l "Regenerate API access" on page 309
Overview
Applications that need authentication include:
l The ALM Octane CI and Application Automation Tools plugins. For details, see "Obtain
API Access. Ask your space admin for an API access Client ID and Client secret. The plugin uses
these for authentication when communicating with ALM Octane. " on page 407.
l The interactive API client.
l Other 3rd party applications and APIs that need to integrate with ALM Octane, such as those
that are located behind a firewall.

When granting access, two keys are generated.
l Client ID.
l Client secret. The secret key is like a user password, and you must record it securely.
Tip: ALM Octane generates each secret key once only, and the secret key cannot be
retrieved later. If a new secret key is needed, revoke the Access key, and then
regenerate access. For details, see "Revoke API access" on page 309 and "Regenerate
API access" on page 309.
Integration types
When providing API access to applications, integration types are automatically assigned to each
application. The default integration type is 3rd-party integration. Other integration types may be
assigned, based on the roles you assign to the application.
When viewing the list of applications that have been granted API access in the grid, you can see
each application's integration type, but you cannot modify the type.

Integration
type Description Role
CI/CD This type enables CI/CD servers such as Jenkins and TeamCity to CI/CD
Integration integrate with ALM Octane. Integration
This integration connects with ALM Octane on the shared space
level. It can access any workspace on which the CI/CD Integration
role is assigned.
3rd-party This type enables 3rd-party applications to freely integrate with Any role
Integration ALM Octane. You can use this integration type as a default, and can be
define roles, to get exactly the access the application needs. assigned
This integration operates on any workspace or space.
Integration The Integration Bridge for ALM Octane is a component installed Integration
Bridge on the customer system to mediate between ALM Octane and Bridge
applications located behind firewalls, enabling two-way
communication between the two.
This type enables the communication between the Integration
Bridge and ALM Octane.
This integration operates on the space level.
For details on how to install and configure the bridge, see "Set up
the Integration Bridge Agent" on page 311.
SaaS: For details on having ALM Octane Support install and
configure an Integration Bridge for you, see "Synchronization
overview" on page 344.
SaaS: Internal integration types

Some applications are internal to ALM Octane and are assigned integration types accordingly.
You cannot create or edit these API keys, but you may see them in the API Access grid and you
can manage them there.
The space admin can regenerate the keys if necessary, but cannot revoke them.
Integration type Description Role

Bridge Service This type operates on the space level. Integration Bridge Service
Synchronizer Service This type is assigned to all workspaces. Synchronizer Service
Octane2BridgeService This type operates on the space level. Octane2BridgeService

Create API access keys

1. In Settings , select Spaces and select the space.
2. In the API Access tab, click +.
3. Provide an appropriate name for the access. You can also add a description.
Caution: The name of the API access key can include only English characters.
4. Select the roles for the applications to use when accessing ALM Octane. For a description of
each role, see "Predefined roles" on page 533.
Note: For API access keys used for CI server integration, you must assign the CI/CD
Integration role. These keys are used by the plugins that support CI integration, and
when using the REST API to manage pipelines.
For API access keys used by the Integration Bridge, you must assign the Integration
Bridge role. This role does not require selecting a workspace.
For each role, select all of the relevant workspaces. If additional relevant workspaces are
created later, you will need to manually assign them.
You can select more than one role by clicking Add role to assign.
5. Click Add.
l A dialog displays with a Client ID and a Client secret.
Click Copy to copy these keys to the clipboard so you can use them when configuring the
applications that need to access ALM Octane.
Click OK.
l The access ID is added to the grid. Note that its status is active .
Modify API access keys

1. In Settings , click Spaces and then select the space.
2. In the API Access tab, select the access that you want to modify.
3. You can modify the name or description of the access.
Caution: The name of the API access key can include only English characters.
You can also modify the list of roles and workspaces that this set of keys can access.

Revoke API access
2. In the API Access tab, select the row with the access you want to revoke.
SaaS: You cannot revoke or delete access for service access keys, such as Bridge service or
Synchronizer Service. You can, however, regenerate service access keys.
3. Click Revoke access. The access is revoked immediately and is displayed in the Active
column.
You can regenerate access if necessary. See "Regenerate API access" below.
Regenerate API access
2. In the API Access tab, select the row of the access that was revoked or needs to be
regenerated.
3. Click Regenerate access.
l A dialog displays with a newly-registered Client secret for the selected Client ID.
Click Copy to copy these keys to the clipboard so you can use them when configuring the
applications that need to access ALM Octane.
Click OK.
l The access ID is added to the grid. Note that its status is active .
See also:
Set up credentials
Some applications require credentials. ALM Octane can supply these credentials when calling
these applications from a Trigger Webhook rule. You define the credentials in Settings.
In this topic:
l "Add credentials" on the next page
l "Delete credentials" on the next page

Synchronization
Overview
Admins can define credentials so that ALM Octane can send requests to applications that require
basic authentication. These credentials can be used as part of a Trigger webhook rule.
Add credentials
1. In Settings , select Spaces and select the space or the workspace.
2. In the Credentials tab, click +.
3. Provide an appropriate name for the credentials.
4. Enter the username and the password for accessing the application.
5. Click Add.
When credentials are used, such as by Trigger webhook rules, IN USE is updated.
Delete credentials
1. In Settings , click Spaces and then select the space or workspace.
2. In the Credentials tab, select the row with the credentials you want to delete.
3. Verify that the credentials are not in use by reviewing the IN USE column. If you delete
credentials that are in use, rules using these credentials will be invalid and won't run.
4. Click and Delete.
See also:
l "Trigger Webhook" on page 571
l "Trigger webhooks for other applications" on page 581
Synchronization
This section provides instructions for synchronizing ALM Octane with external applications.
Topic Description
"Set up the Install the Integration Bridge Agent on your system to enable ALM
Integration Bridge Octane to integrate with external applications. This is required for
Agent" on the next synchronization, and can also be used for Trigger Webhook rules.
page

Synchronization
Topic Description
"Synchronize ALM Synchronize your ALM Octane workspaces with your ALM or JIRA
Octane with ALM or projects to view and update your releases, backlog, and defects in both
JIRA" on page 343 endpoints.
Set up the Integration Bridge Agent

This section describes how to install and set up the Integration Bridge Agent to enable ALM
Octane to integrate with external applications. This is required for synchronization, and can also
be used by Trigger Webhook rules.
Tip: For ease of reading, we are using the term Integration Bridge to refer to the
Integration Bridge Agent. For instructions on installing the Integration Bridge Server,
refer to the Synchronizer Installation Guide , which can be accessed from the "Installation
guides" on page 465 page.
In this topic:
l "Synchronization" below
l "Trigger Webhook rules" on the next page
l "Integration Bridge Agent system requirements" on the next page
Synchronization
You can synchronize ALM Octane workspaces with ALM or JIRA projects to view and update
your releases, requirements, and defects in both endpoints. For details, see "Synchronize ALM
Octane with ALM or JIRA" on page 343.
l Synchronizing with ALM on SaaS: Contact your SaaS operator and request setup of the
Integration Bridge between ALM Octane and your ALM instance.
l Synchronizing with JIRA/On-Premises ALM: To enable synchronization, you need to first
install the Synchronizer as described in the Synchronizer Installation Guide . This is included in
the Synchronizer installation package, from Micro Focus download sites. After you configure
the Synchronizer, install and configure the Integration Bridge Agent as described in the
following sections.
You also need to contact your space admin and get API access keys (Settings > Spaces > API
Access).
Note: To verify if the required Synchronizer services are enabled for a specific tenant,
look at the tenant’s details within Settings > Site. If the services are enabled, you will see
a version number in the Bridge service and Synchronizer service columns.

Synchronization
Trigger Webhook rules

In advanced workflow scenarios, you can use Trigger Webhook rules to
HTTP/S POST information to an endpoint URL to be used by a third-party application. For
details, see "Trigger webhooks for other applications" on page 581. This may require you to install
an Integration Bridge to serve as an intermediary between ALM Octane and the endpoint URL. In
this case, ALM Octane sends the URL call to the integration bridge, and the bridge executes the
call.
If the URL can be accessed from your network and/or is publicly visible, you do not need to install
the integration bridge to run a Trigger Webhook rule.
Integration Bridge Agent system requirements

Verify that your system has the following minimum system requirements for each Integration
Bridge Agent that you install:
Operating system One of the following:

l Windows Server 2008 R2 SP1 64-bit
l Windows Server 2012 R2 SP1 64-bit
l Red Hat Enterprise Linux 6.2, 6.3, 6.4, 6.5, 6.7, or 7.2 (64 Bit)
l SUSE Linux Enterprise 11 Service Pack 3
CPU Quad Core CPU
Memory (RAM) 8 GB
Free disk space 80 GB
Heap size Maximum 4 GB
Note:
l The Integration Bridge Agent must be installed to a path named only with ASCII
characters.
l We recommend not installing the Integration Bridge Agent on the same Linux server as
ALM or JIRA, or ALM Octane (if installed on-premises). Installing the Integration Bridge
Agent on the same server as one of these would cause severe competition for the same
resources, impacting stability and performance.
l On Windows, the installation includes both the Integration Bridge Agent application,
and the corresponding service.

Synchronization
On Linux, if you install the Integration Bridge Agent as a root user, the installation
includes the service as well.
If you install the bridge using a non-root user, you will need to manually install the
service as a root user.
Download and install the Integration Bridge Agent

Download the Integration Bridge Agent from ALM Octane, and install it on a computer that can
access both ALM Octane and the target endpoint (either ALM or JIRA for synchronization, or an
endpoint for a Trigger webhook rule).
If you are installing on a Windows operating system, install the bridge as a Windows administrator
user. You can run the bridge as a non-administrator user with the relevant permissions.
On a Linux computer, any user can install the bridge.
In this topic:
l "Download the bridge from ALM Octane" below
l "Install the Integration Bridge" on the next page
l "Installing multiple bridges" on page 317
Prerequisites
l The user installing the Integration Bridge needs to have the following ALM Octane roles:
l Shared spaced admin
l Synchronizer admin. Assign this role on the Site > Users or Workspace > Users configuration
page.
l Linux: The user installing the Integration Bridge needs to have R/W permissions to the /tmp
system folder.
l Obtain a client ID and secret to enter during the Integration Bridge installation. The bridge uses
these credentials to access ALM Octane.
On the Settings Spaces > API Access page, add API Access keys for an Integration Bridge
client. For details, see "Create API access keys" on page 308.
ALM Octane generates a client ID and secret for the bridge.
Download the bridge from ALM Octane

Download the bridge from one of these locations:
l Synchronization. From the ALM Octane settings area, select Synchronizer.
l Trigger webhook rules. While creating or editing a rule, select the Trigger webhook action.

Synchronization
Check the Advanced settings checkbox, and click one of the download links on the right of the
pane (either Windows or Linux).
On the link configuration page that opens, do one of the following:
Installation Instruction
If this is the first time you are In the checklist, click the link in the second step to
installing the bridge download the bridge, according to your operating system.
If you are installing an Select More Actions > Download Integration Bridge, and
additional bridge or select the relevant download according to your operating
performing an upgrade system.
Install the Integration Bridge

1. On the computer where you want to install the bridge, extract the downloaded zip file (hpe-
integration-bridge-windows.zip or hpe-integration-bridge-linux.zip). You must extract this
zip file to a path named only with English characters.
The zip file contains the following:
l The installation executable file.
l A configuration file (server-connection.conf) containing the URL and shared space ID that
the bridge will use to connect to ALM Octane. Note that this URL must end with /opb,
which is the entry point for the Integration Bridge.
l Linux: An integrity verifier (.bin.sig file), used for signature verification when packaging
the installation files.

2. Linux: In the folder containing the extracted files, run chmod +x hpe-integration-bridge.bin
to obtain execution permissions on the installation file.
3. Run the following file to begin the installation:
Windows: hpe-integration-bridge.exe (Runs a GUI Wizard)
Linux: hpe-integration-bridge.bin (CLI only)
4. Follow the instructions in the installation process to complete the installation.
When provided, accept the default values, which are configured to connect to your
workspace.
Note:
l The Integration Bridge must be installed to a path named only with ASCII
characters, and must not contain consecutive spaces.
l If you select the Modify an Existing Instance option, the bridge you select is
uninstalled. After uninstalling, run the installation again to install a new instance.

Synchronization
Tip: Linux:
l You can cancel the installation at any step by typing quit.

l You can return to a previous step in the installation process by typing back.
l In the step for configuring the connection to ALM Octane:

Settings Description
Bridge name Define a name for the bridge.
URL The URL of your ALM Octane site.

Format: http(s)://<hostname or IP address>:<port
number>/opb
By default, this URL is provided for you, from the downloaded
server-connection.conf file.
Caution: If you modify this URL, make sure not to end it

with a slash ('/').
Shared Space ID This is automatically populated in the installer based on the server
(Read only) from where the bridge agent is downloaded.
Client ID and The client ID and secret with the Integration Bridge role, that
Client Secret ALM Octane generated on the Integration > API page.
fields
Proxy server If you will be using a proxy server to access ALM Octane, select
Use proxy server.
Enter details for the proxy server and the user who will be logging
into the proxy server:
o Host. A valid address for the proxy server.
o Port. A valid port number (integer, between 1-65535)
Tip: On Windows:
You can click Test Connection to verify that the bridge can connect to ALM
Octane.
After you enter this information, the connection to ALM Octane is tested. If the test fails,
you can reenter the connection settings or continue the bridge installation and modify the
credentials later.

Synchronization
l In the step for configuring the Integration Bridge service, accept the default service name
and port number, or modify as needed.
Tip: If you install multiple bridges, use a name that will help you associate the
service with the corresponding bridge.
Linux: The service name must contain only ASCII characters, and must not contain square
brackets ([ ]).
5. When the installation is finished, the Installation complete message is displayed.
Note: If you are installing the Integration Bridge for Trigger

webhook rule functionality, clear the Run credentials manager and define
credentials for synchronizer links option. You can run Credentials Manager to set
ALM credentials later if needed.
Press ENTER to quit the installer.

6. If you performed the installation on Linux as a non-root user, you must manually install the
Integration Bridge service as a root user:
<Bridge_installation_directory>/product/bin/HPEIntegrationBridge.sh install
7. If you selected the Run credentials manager and define credentials for synchronizer links
option at the end of the installation, the Endpoint Credentials Manager opens.
l Synchronization . Define credentials for connecting to ALM or JIRA, as described in
"Manage connection setup" on page 320.
Note: You must configure ALM or JIRA credentials before you configure your
links.
If the credentials manager does not open automatically, you can open it manually
or configure the credentials using the CLI. For details, see "Manage connection
setup" on page 320.
In ALM Octane, the new bridge is identified within a few moments. If you do not see your
new bridge, refresh the page. From there, click Create synchronization links to start
creating your links.
l Trigger webhook. To enable the Trigger webhook rule, do not enter more credentials.
Close the Endpoint Credentials Manager application, and define the Trigger webhook rule
action as described in "Set up rules" on page 568.

Synchronization
Installing multiple bridges

Installing multiple bridges is necessary only in certain cases. For example:
l If you need to synchronize ALM Octane with ALM or JIRA projects that reside on different
networks.
l If you define a large number of synchronization links and you want to distribute the load
between multiple bridges.
l If you install bridges for multiple ALM Octane sites. Each bridge communicates with one site.
In this case, you must download each bridge separately, from the site with which it will
communicate. The downloaded files contain the configuration necessary for the bridge to
connect to the relevant site.
Recommendations if you install multiple bridges:
l Use a separate set of ALM Octane credentials (client ID and secret) for each bridge.
l Instead of using the default installation folder, provide a name that helps identify the bridge.
For example, if you install multiple bridges to communicate with multiple ALM Octane sites,
include the site name in the installation folder name.
Integration Bridge security

The Integration Bridge does not expose any internal information. Additionally, Micro Focus
application JAR files are signed by Micro Focus, helping to validate the code's origin.
In this topic:
l "Communication with ALM Octane using OAuth authentication" below
l "Communication via SSL" on the next page
l "Connections using a certificate that is not signed by a well-known Certificate Authority" on the
next page
l "Password encryption" on the next page
l "Security recommendations" on page 319
l "Integration Bridge automatic upgrades" on page 320
Communication with ALM Octane using OAuth authentication

The Integration Bridge uses OAuth authentication when connecting to ALM Octane, instead of
using the credentials of an ALM Octane user.

Synchronization
Communication via SSL

Communication between the Integration Bridge and ALM Octane is secured by SSL.
The bridge logs in to ALM Octane using the ALM Octane user credentials or client ID and secret
provided during installation, or later as described in "Set ALM Octane credentials" on page 331.
Connections using a certificate that is not signed by a well-known Certificate

Authority
If you connect to a secured ALM Octane or ALM or JIRA server using a certificate that is not
signed by a well-known Certificate Authority, you must establish trust for the certificate.
To establish this trust, import the issuer's certificate to the JRE's truststore in the following
directory:
<Integration Bridge installation directory>\product\util\3rd-party\jre1.7.0_
51\jre\lib\security\ (On Linux, reverse the slashes in this path and the ones below)
Do the following:
1. With ALM Octane, ALM, or JIRA open in your browser window, export the certificate from
the browser, and save it to a file named server.cer.
2. On the Integration Bridge machine, place the server.cer file in the <Integration Bridge
installation\product\util\3rd-party\jre1.7.0_51\jre\bin directory.
3. Use the keytool command from the <Integration Bridge installation>\product\util\3rd-
party\jre1.7.0_51\jre\bin directory to import the server.cer file to the <Integration Bridge
installation>\product\util\3rd-party\jre1.7.0_51\jre\lib\security\cacerts directory.
For example:
(Windows) keytool.exe -import -v -trustcacerts -alias <alias>

-file server.cer -storepass <password> -keystore <Integration Bridge
installation>\product\util\3rd-party\jre1.7.0_51\jre\lib\security\cacerts
Note: You may need to repeat this command for the rest of the certificate chain, using
a different alias each time.
4. Restart the Integration Bridge.
Password encryption
Passwords for connecting to endpoints are encrypted and saved on the customer's machine,
preventing credentials from being transferred to another machine.

Synchronization
The encryption method uses keys that are randomly generated during installation. The bridge
uses AES 128 as the main encryption method.
Security recommendations
Download sources Do not download the Integration Bridge installation file or updates
from unknown sources.
Integration Bridge Install the Integration Bridge on a dedicated, hardened machine.

machine
Integration Bridge Deploy the Integration Bridge in an isolated network, with a firewall
network between the bridge and the target on-premises application.
l Port 443 must be open for communication with ALM Octane.
l Additional ports may be required to be opened for internal
communications with other on-premises applications.
Integration Bridge By default, the Integration Bridge service runs using the Windows
permissions Local System service user.
Windows only To increase system security, assign a simple Windows user to run
the Integration Bridge.
l Install the Integration Bridge in a folder other than the Program
Files folder. This will enable you to grant the simple user
permissions on the Integration Bridge installation folder.
l Grant the user full permissions (Read/Write/Execute) on the
installation folder.
l Grant the user permissions to manage the Integration Bridge
Windows service.
l Open the Windows Service Manager, modify the HPE Integration
Bridge service to run using the simple user's account and then
restart the service.
Tip: You can protect the Integration Bridge installation

folder by granting permissions to that folder only to
administrators, the Local System service user, and the
dedicated user you created.

Synchronization
Integration Bridge The Integration Bridge runs using the permissions of the Linux user
permissions that installed it, and this user will have full read, write, and execute
permissions on all of the folders and files installed with the bridge.
Linux only
Therefore, you may want to consider installing the Integration
Bridge as a non-root user. If you do:
1. We recommend creating a dedicated user for managing the
Integration Bridge. Use this user to install the bridge, and to
manage the bridge activation manually when necessary.
2. Protect the following files by changing their owner to root:
l <Integration Bridge
installation>/product/bin/HPEIntegrationBridge.sh
l <Integration Bridge
installation>/product/conf/wrapper.properties
Installing multiple If you install multiple bridges, we recommend that you use a
Integration Bridges separate set of ALM Octane credentials (client ID and secret) for
each bridge.
Integration Bridge The ALM Octane user with the Integration Bridge role should not
user have any other additional roles.
On-premise When defining permissions for users of on-premise applications that

application users communicate with ALM Octane such as ALM or JIRA users, limit
permissions to specifically required operations only.
Integration Bridge automatic upgrades

When a new version of the Integration Bridge is available, it is automatically downloaded from
ALM Octane. The Micro Focus signature on the downloaded file is verified before the new version
is installed.
Manage connection setup

Credentials are used to provide secure, two-way communication between the Integration Bridge
Agent and ALM Octane, ALM, or JIRA.
l "Endpoint Credentials Manager" on the next page
l "Set ALM or JIRA credentials (Endpoint Credentials Manager)" on the next page
l "Connecting to ALM using SiteMinder single sign-on (SSO)" on page 322

Synchronization
l "Define ALM or JIRA credentials and proxy" on the next page

l "Modify ALM Octane credentials and proxy" on the next page
Endpoint Credentials Manager

On Windows, or on a Linux computer that supports GUI, the Endpoint Credentials Manager
application opens automatically after installing the Integration Bridge. This application is used to
manage ALM or JIRA credentials.
Note:
You must set credentials before synchronizing entities between ALM Octane and ALM or
JIRA, and modify them later on if these credentials change.
If the Endpoint Credentials Manager application does not open automatically, or if you need to
modify credentials again later:
On Windows: The Endpoint Credentials Manager application is installed together with the
Integration Bridge. Locate the application in Windows and run it manually.
On Linux: Navigate to the <Bridge_installation_directory>/product/util/opb directory.
l If your system supports GUI, run the following script to open the application manually:
credentials_mng_ui.sh
l Otherwise, run the following script to modify the credentials using the console: credentials_
mng_console.sh
Set ALM or JIRA credentials (Endpoint Credentials Manager)

On Perform this procedure as a user with permissions to run the Integration Bridge.
Windows:
On Linux: Perform this procedure as a root user, or as the user who installed the
Integration Bridge.
If you are working on a Linux machine that does not support GUI, set the ALM or JIRA credentials
using the Command Line Interface (CLI).
1. On the Integration Bridge machine, open the Endpoint Credentials Manager application as
described above.
2. Click New to create a set of credentials.
3. Enter the credentials on the right, and then click Save .

Synchronization
Field Description
Display The name used to identify this particular credentials record when
name configuring a link in ALM Octane.
User The name of the user connecting to ALM or JIRA.
Password The password used to connect to ALM or JIRA.
Confirm Enter the password a second time to confirm it.

password
Credentials are encrypted and stored on your system in the credentialsStore.xml and
bridgeCredentialStore.xml files, located in the <Bridge_installation_directory>\product\conf
folder. (On a Linux system, reverse the slashes in the path.)
l To update a credential record, select it and make your changes on the right. Then click Save.
l To delete a credential record, select it, and click Delete.
Connecting to ALM using SiteMinder single sign-on (SSO)

If the Integration Bridge needs to connect to ALM using SiteMinder single sign-on (SSO):
l Configure SiteMinder to support basic authentication.
l You may need to change the CSSChecking parameter in the SiteMinder settings to allow the
characters >, <, and ' in URLs. Otherwise, SiteMinder may reject communication messages sent
by ALM Octane Synchronizer and synchronizations may fail.
Define ALM or JIRA credentials and proxy

You can also set or modify ALM or JIRA credentials using the CLI.
By default, the connection between the Integration Bridge and ALM or JIRA is not authenticated
by proxy. To configure a proxy, see "Configure a proxy for domain connections" on page 329.
Modify ALM Octane credentials and proxy

The ALM Octane credentials are set by default.
Modify these credentials if they change from the values defined when you first downloaded the
Integration Bridge. For details, see:
l "Set ALM Octane credentials" on page 331
l "Configure a proxy for ALM Octane connections" on page
332
See also: "Integration Bridge security" on page 317.

Synchronization
Set ALM or JIRA credentials (CLI)

Use the credentials_mng_console command line tool to set the credentials used to connect to
ALM or JIRA.
You must set credentials before synchronizing entities between ALM Octane and ALM or JIRA,
and later on if these credentials change.
Note: Alternatively, set credentials using the Endpoint Credentials Manager. For details,
see "Manage connection setup" on page 320.
To open the credentials_mng_console command line tool:
On Windows On Linux
As an administrator, or as a user with As a root user, or as the user who installed
permissions to run the Integration Bridge: the Integration Bridge:
1. Open the <Bridge_installation_ 1. Navigate to the <Bridge_installation_
directory>\product\util\opb directory. directory>/product/util/opb directory.
2. Run the credentials_mng_console.bat file. 2. Run the credentials_mng_console.sh file.
The credentials_mng_console tool supports the following commands:
"list" "listEndpointTypes" "listCredentialIds"

"listEndpointTypeParams" "create" "update"
"delete" "help"
list
Lists available credential records for connecting to ALM or JIRA from the Integration Bridge.
Usage
credentials_mng_console list –endpoint <ENDPOINT TYPE>
Parameters
-endpoint <ENDPOINT Endpoint type name, such as an ALM or JIRA version (optional).
TYPE>
This type name must be a value available in the
"listEndpointTypes" command.

Synchronization
Sample Results
======================
Endpoint type : sample-endpoint-type-alm
ID : 9460b7
Name : sample credentials record
User : sample username
Password : ******
Parameters :
Key | Value
-----------
sample.secret.property | ******
sample.url.property | 123
listEndpointTypes
Lists available ALM or JIRA endpoint types accessible to the Integration Bridge, such as ALM or
JIRA versions. You can filter the endpoints by type name.
Usage
credentials_mng_console listEndpointTypes –endpoint <ENDPOINT TYPE>
Parameters
-endpoint <ENDPOINT TYPE> Endpoint type name (optional)
Sample Results
Endpoint types :
1. alm
listCredentialIds
Lists all ALM or JIRA credential record IDs and the ALM or JIRA endpoint type related to each
credential ID.
Usage
credentials_mng_console listCredentialIds –endpoint <ENDPOINT TYPE>

Synchronization
Parameters
-endpoint <ENDPOINT Endpoint type name, such as the ALM or JIRA version (optional).
TYPE>
Sample Results
Endpoint type : alm
Name | ID :
1. sample credentials record name | 11e7
====================
Name | ID :
2. sample credentials record #2 name | 7e0
Endpoint type : alm
Name | ID :
====================
Name | ID :
2. sample credentials record #2 name | 7e0
listEndpointTypeParams
Lists the specific parameters required for saving credentials for each ALM or JIRA endpoint type.
Usage
credentials_mng_console listEndpointTypeParams –endpoint <ENDPOINT TYPE>
Parameters
-endpoint <ENDPOINT Endpoint type name, such as an ALM or JIRA version (optional).
TYPE>

Synchronization
Sample Results
======================
Output format:
Parameter:
Label:
Description:
Mandatory:
--------------------------------------------
Endpoint type specific parameters:
Parameter: sample.url.property
Label: Server URL
Description: URL address for sample server
Mandatory: true
Parameter: sample.secret.property
Label: Secret key
Description: Secret key for sample server
Mandatory: false
create
Creates a credentials record for accessing ALM or JIRA from the Integration Bridge.
Usage
credentials_mng_console create –file <path to data file> –user <USER> –pass

<PASSWORD> -endpoint <ENDPOINT TYPE> -name <CREDENTIALS RECORD NAME> -param
<KEY> <VALUE> –param <KEY> <VALUE>
Usage example - generic
credentials_mng_console create -user <USER> -pass <PASSWORD> -endpoint sample-

endpoint-type-alm -name <CREDENTIALS NAME> -param sample.url.property
<PARAMETER_VALUE> -param sample.url.property <PARAMETER_VALUE>

Synchronization
Usage example - ALM specific
credentials_mng_console create -user <USER> -pass <PASSWORD> -endpoint alm -name

<CREDENTIALS NAME>
Parameters
-file <FILE> Read parameters from the property file (optional).

Parameters will be overwritten if they are specified in the console.
-user <USER> User name
Tip: On Linux:
Use an escape character (' or \) before any non-

ASCII characters in the name.
-pass <PASSWORD> Password
-endpoint <ENDPOINT Endpoint type name, such as an ALM or JIRA version.

TYPE>
-name <CREDENTIALS Credentials record name

NAME>
-param <KEY> <VALUE> Custom parameters (optional)
-replace Replace all existing parameters with input parameters (optional)

The property file is a text file that describes the credential's properties. The file format is:
endpoint=<ENDPOINT TYPE>
name=<NAME>
user=<USER>
pass=<PASSWORD>
customParam1=value1
customParam2=value2
Sample Results
endpoint=<ENDPOINT TYPE>

Synchronization
name=<NAME>
customParam1=value1
customParam2=value2
update
Updates an existing credentials record for accessing ALM or JIRA from the Integration Bridge.
Usage
credentials_mng_console update -user <USER> -pass <PASSWORD> -credentialsId

<CREDENTIALS ID> -endpoint <ENDPOINT TYPE> -param <KEY> <VALUE> –param <KEY>
<VALUE> -replace
Usage example
credentials_mng_console update -user <USER> -pass <PASSWORD> -credentialsId

<CREDENTIALS ID> -endpoint alm -replace
Parameters
-file <FILE> Reads parameters from the property file (optional).

Parameters will be overwritten if they are specified in the console.
-user <USER> New user name
Tip: On Linux:
Use an escape character (' or \) before any non-

ASCII characters in the name.
-pass <PASSWORD> New password
-credentialsId The credentials record ID you want to update

<CREDENTIALS ID>
-endpoint <ENDPOINT New endpoint name, such as an ALM or JIRA version.

TYPE>
-param <KEY> <VALUE> Custom parameters (optional)
-replace Replace all existing parameters with input parameters (optional)

Synchronization
delete
Deletes an ALM or JIRA credential record.
Note: You cannot delete a single parameter from a credential record. You can only delete
an entire credential record.
Usage
credentials_mng_console delete –endpoint <ENDPOINT TYPE> -credentialsId

<CREDENTIALS ID>
Parameters
-endpoint <ENDPOINT Endpoint type name, such as the ALM or JIRA version.
TYPE>
-credentialId The credentials record ID

<CREDENTIALS ID>
help
Provides help for the current command when configuring ALM or JIRA credentials for the
Integration Bridge.
Usage
credentials_mng_console help
Configure a proxy for domain connections

You can configure a proxy for all domains (ALM or JIRA, rule extensions) used in the Integration
Bridge. By default, the connection between the Integration Bridge and the third-party domain
systems is not authenticated by proxy. To configure a proxy, do the following:
Note:
On Perform this procedure as a user with permissions to run the Integration

Windows: Bridge.
Integration Bridge.

Synchronization
1. In the <Integration Bridge installation directory>\product\domain\<alm, jira, or business-

rules-extension>\conf folder, open the proxy.properties file. (In Linux, reverse the slashes in
the path.)
2. To use a proxy, change the setProxy value to true.
If this value is false, proxy settings are ignored and no proxy is used.
3. Set the proxy host and port values:
a. Change the proxyHost value to the proxy IP address or server name.
b. Change the proxyPort value to the relevant port for the proxy.
When proxyHost has a value, proxyPort is mandatory.
Example
setProxy=true
proxyHost=123.45.6.7
proxyPort=1234
proxyUser=
proxyPass=
4. If the proxy requires authentication:

a. Change the proxyUser value to the proxy user name.
b. Change the proxyPass value to the proxy password.
When proxyUser has a value, proxyPass is mandatory.
Example
setProxy=true
proxyHost=123.45.6.7
proxyPort=1234
proxyUser=MyUserName
proxyPass=MyPassword
5. Save the proxy.properties file.

6. Restart the Integration Bridge. For details, see "Start and stop the Integration Bridge" on
page 334.
Tip: If authentication fails, verify that the contents of the proxy.properties file are
syntactically correct and contain valid values.

Synchronization
Set ALM Octane credentials

Use the bridgeAuthentication command line tool to set the credentials used to connect to ALM
Octane.
The credentials consist of a client ID and secret generated by ALM Octane. To obtain a client ID
and secret, add an entry for the Integration Bridge on the Settings Spaces > API Access page.
Assign this entry the Integration Bridge role. For details, see Set up API access for integration in
the ALM Octane User Guide .
Note: If you are not a space admin on your ALM Octane system, have your admin add the
Integration Bridge client and provide you with the generated client ID and secret .
Use this tool in the following cases:

l You want to use credentials other than the ones you entered when you first installed the
Integration Bridge.
l You need to update your bridge so that it connects to ALM Octane using OAuth
authentication. The Integration Bridge bridge now uses a client ID and secret to connect to
ALM Octane instead of ALM Octane user credentials.
Run the bridgeAuthentication command line tool

On Windows On Linux
2. Run the bridgeAuthentication.bat file. 2. Run the bridgeAuthentication.sh file.
The bridgeAuthentication tool supports the following commands:
"setAuth" below "help" on the next page
setAuth
Sets credentials for connecting to ALM Octane from the Integration Bridge.
Usage
bridgeAuthentication setAuth -clientId <CLIENT_ID> -secret <SECRET>

Synchronization
Parameters
-clientId <CLIENT_ID> The client ID to use when connecting to ALM Octane.
-secret <SECRET> The secret for the client that is connecting to ALM Octane.
help
Provides help for the current command when configuring ALM Octane credentials for the
Integration Bridge.
Usage
bridgeAuthentication help
Configure a proxy for ALM Octane connections

Use the proxyConfiguration command line tool to set credentials for accessing ALM Octane
through a proxy server.
On Windows On Linux

2. Run the proxyConfiguration.bat file. 2. Run the proxyConfiguration.sh file.
Note:
l Set proxy server credentials only if the credentials change from when you first installed
the Integration Bridge.
l After making any changes, restart the Integration Bridge. For details, see "Start and
stop the Integration Bridge" on page 334.
The proxyConfiguration tool supports the following commands:
"setAddress" "removeProxyConfiguration "

"setAuth" "removeAuth"
"help" on page 334
setAddress
Sets a host and port for accessing ALM Octane through a proxy server.

Synchronization
Usage
proxyConfiguration setAddress -host <PROXY HOST> -port <PROXY PORT>
Parameters
-host <PROXY HOST> The address of the proxy server host.
-port <PROXY PORT> The port number of the proxy server.
removeProxyConfiguration
Configures the Integration Bridge to access ALM Octane without a proxy server.
Usage
proxyConfiguration removeProxyConfiguration
setAuth
Saves credentials for connecting to a proxy server, when accessing ALM Octane through a proxy
server.
Usage
proxyConfiguration setAuth -user <USER> -pass <PASSWORD>
Parameters
-user <USER NAME> The name of the user connecting to the proxy server.
-pass <PASSWORD> The password of the user connecting the proxy server.
removeAuth
Deletes a set of credentials previously used to connect to ALM Octane through a proxy server.
Usage
proxyConfiguration removeAuth

Synchronization
help
Provides help for the current command when configuring access to ALM Octane through a proxy
server.
Usage
proxyConfiguration help
ALM Octane Synchronizer proxy support

ALM Octane Synchronizer supports the following types of proxy authentication:
Between the Integration Bridge and... ALM Octane ALM

No authentication √ √
Forward Basic authentication √ √
No authentication √ √
Reverse Basic authentication x x
Note: NTLM authentication is not supported for any types of proxy.
Start and stop the Integration Bridge

If the Integration Bridge service is installed, the Integration Bridge is automatically started when
your system starts.
This topic describes how to manage the bridge activation manually.
On Perform this procedure as a user with permissions to run the Integration Bridge.
Windows:
Integration Bridge.
Note:
l The Integration Bridge service is installed as part of the Integration Bridge installation,
unless you performed the installation on Linux as a non-root user. In this case you must
manually install the Integration Bridge service as a root user:

Synchronization
<Bridge_installation_directory>/product/bin/HPEIntegrationBridge.sh
install
l The bridge must be running for ALM Octane to communicate with on-premises
applications such as ALM or JIRA.
l If you have upgraded your ALM projects, you’ll need to restart the bridge manually
after upgrade to continue synchronizing data between ALM or JIRA and ALM Octane.
Commands relevant only on Windows

Start the bridge Search or browse for, and select the StartHPEIntegration
Bridge application.
Stop the bridge Search or browse for, and select the StopHPEIntegration
Bridge application.
Manage the bridge using 1. Run the services.msc command.

Windows Services 2. Select the HPEIntegration Bridge service.
3. Stop or start the service as required. This starts and
stops the bridge application as well.
Manage the bridge from the command line

Use the HPEIntegrationBridge command line tool:
On Windows On Linux

directory>\product\bin directory. directory>/product/bin directory.
2. Run the HPEIntegrationBridge.bat file. 2. Run the HPEIntegrationBridge.sh file.
Use the following commands:
Task Command
Start the bridge HPEIntegrationBridge start
Stop the bridge HPEIntegrationBridge stop
Restart the bridge HPEIntegrationBridge restart
Install the Integration Bridge service HPEIntegrationBridge install
Remove the Integration Bridge service HPEIntegrationBridge remove

Synchronization
Uninstall/Remove the Integration Bridge

Uninstall a bridge if you no longer need it, or before upgrading.
Remove a bridge from the Link Configuration navigation tree if you no longer need it, or are no
longer using it.
To uninstall a bridge permanently

1. In the ALM Octane Synchronizer > Link Configuration page, expand the navigation tree
on the left.
Verify that no synchronizations are currently running on the bridge's links.
Right-click on any links that are in automatic mode and select Stop Automatic Mode. Wait for
the completion of any current synchronization runs before uninstalling the bridge.
2. Close all tools, folders, and files related to the Integration Bridge, such as the Endpoint
Credentials Manager.
3. Do the following:
Task Description
Uninstall the bridge On Windows: As a Windows administrator user, uninstall the
Integration Bridge using the Start menu option or the Windows
Control Panel.
On Linux: As a root user, navigate to the <Integration Bridge
installation directory>/install directory and run the hpe-
integration-bridge-uninstall script.
Note: Uninstalling as a root user ensures a clean removal

of both the Integration Bridge application and the
Integration Bridge service.
During the uninstall process, select Remove credentials if you

also want to remove any associated credentials. By default,
credentials are kept, and you can use them in a subsequent
installation.

Synchronization
Task Description
Remove the bridge In ALM Octane:
from the ALM a. Verify that the bridge has no links configured. If there are
Octane user any existing links, remove them:
interface (optional)
Select the link in the tree and then select More Actions >
Remove.
Caution: You cannot recover a link removed from the

ALM Octane Synchronizer. Only remove a link if you
no longer need to synchronize its data between the
endpoints.
b. Select the bridge name and either select Remove Bridge from
the context menu, or select More Actions > Remove.
Caution: Only remove the bridge from the user

interface if you have no intention of recovering it.
You cannot recover a bridge removed from the

ALM Octane Synchronizer, even if you have not yet
uninstalled it.
When you uninstall the Integration Bridge, properties customized in the server-connection.conf
file are deleted. The information in the server-connection.conf file is backed up in the server-
connection.bak file.
To uninstall a bridge to upgrade or move it

1. In the ALM Octane Synchronizer > Link Configuration page, expand the navigation tree
on the left.
Verify that no synchronizations are currently running on the bridge's links.
Right-click on any links that are in automatic mode and select Stop Automatic Mode. Wait for
the completion of any current synchronization runs before uninstalling the bridge.
2. Close all tools, folders, and files related to the Integration Bridge, such as the Endpoint
Credentials Manager.
3. On Windows: As a Windows administrator user, uninstall the Integration Bridge using the
Start menu option or the Windows Control Panel.
On Linux: As a root user, navigate to the <Integration Bridge installation directory>/install
directory and run the hpe-integration-bridge-uninstall script.

Synchronization
Note: Uninstalling as a root user ensures a clean removal of both the Integration
Bridge application and the Integration Bridge service.
During the uninstall process, do not select Remove credentials. When you install the
upgraded version, you can use the existing credentials.
Properties customized in the server-connection.conf file are deleted. The information in the
server-connection.conf file is backed up in the server-connection.bak file. Use this file when you
install the upgraded version.
For more details, see "Upgrade the Integration Bridge" below.
Upgrade the Integration Bridge

When a new ALM Octane version includes a new version of the Integration Bridge, follow the
process described below.
In this topic:
l "Upgrade process" below
l "Manual upgrade on the same server" on the next page
l "Manual upgrade and installation in a new location" on the next page
Upgrade process
1. Download and install the new version of the Integration Bridge. For details, see "Download
and install the Integration Bridge Agent" on page 313.
2. Open <New Integration Bridge installation directory>\product\domain, and copy the alm
and jira folders.
3. Paste them in <Old Integration Bridge installation directory>\product\domain, replacing the
old alm and jira folders there.
The new bridge is installed in place of the existing one and then enabled. Any previous
configuration settings and security certificates are retained.
Email notifications are sent at the beginning and end of the upgrade. Upgrade notifications are
sent to the Synchronizer Admin users that you specify on the bridge's Notification tab
(Synchronizer configuration page). For details, see the ALM Octane Synchronization Guide .
Both upgrade methods retain the configured endpoint credentials.
When performing a manual upgrade, if your Integration Bridge communicates with ALM Octane,
ALM or JIRA using a certificate that is not signed by a well-known Certificate Authority, you need
to reinstall the certificate after upgrading the bridge. For details, see "Connections using a
certificate that is not signed by a well-known Certificate Authority" on page 318.

Synchronization
Manual upgrade on the same server

If you need to manually upgrade for some reason, the following procedure registers the upgraded
bridge as an existing bridge.
1. Uninstall the Integration Bridge, as described in "Uninstall/Remove the Integration Bridge" on
page 336. During the uninstall process, do not select Remove credentials.
2. Download the new version of the Integration Bridge from the Synchronizer > Link
Configuration page.
Select More Actions > Download Integration Bridge, and select the relevant download
according to your operating system.
3. Extract the downloaded zip file (hpe-integration-bridge-windows.zip or hpe-integration-
bridge-linux.zip) to a new folder.
4. Copy values from the previous installation to the new installation. Do the following:
a. In the installation directory of the previous version, access the \product\conf\server-
connection.bak file. (On a Linux system, reverse the slashes in the path.)
Tip: By default, the installation directory is C:\Program Files\HPE\HPE

Integration Bridge (Windows) or /root/HPE/HPE Integration Bridge (Linux).
b. In a parallel window, browse to the server-connection.conf file downloaded with the new
version of the Integration Bridge, and open it for editing.
c. Copy the agent.guid property and its value from the previous installation file, and
append it to the new file. Save the new file.
5. Run the newly downloaded hpe-integration-bridge.exe (Windows) or hpe-integration-
bridge.bin (Linux) to begin the installation.
During the installation, select the installation folder that was used for the previous version.
For more details, see "Download and install the Integration Bridge Agent" on page 313.
Manual upgrade and installation in a new location

The following procedure installs the upgraded Integration Bridge in a new directory on the same
server as the previous version, or on an entirely new machine.
1. Uninstall the Integration Bridge, as described in "Uninstall/Remove the Integration Bridge" on
page 336. During the uninstall process, do not select Remove credentials.
2. Download the new version of the Integration Bridge from the Synchronizer > Link
Configuration page.
Select More Actions > Download Integration Bridge, and select the relevant download
according to your operating system.

Synchronization
3. Extract the downloaded zip file (hpe-integration-bridge-windows.zip or hpe-integration-

bridge-linux.zip) to a new folder.
4. Copy files and values from the previous installation to the new installation. Do the following:
a. In the directory where you want to install the new version, create the following folder
structure:product\conf
b. Copy the following files from the installation directory of the previous version to the conf
directory you created in the previous step.
o credentialsStore.xml
o key.bin
c. In the installation directory of the previous version, access the \product\conf\server-
connection.bak file. (On a Linux system, reverse the slashes in the path.)
Tip: By default, the installation directory is C:\Program Files\HPE\HPE

Integration Bridge (Windows) or /root/HPE/HPE Integration Bridge (Linux).
d. In a parallel window, browse to the server-connection.conf file downloaded with the new
version of the Integration Bridge, and open it for editing.
e. Copy the agent.guid property and its value from the previous installation file, and
append it to the new file. Save the new file.
5. Run the hpe-integration-bridge.exe (Windows) or hpe-integration-bridge.bin (Linux) to
begin the installation.
During the installation, select the directory where you want to install the new version.
For more details, see "Download and install the Integration Bridge Agent" on page 313.
Integration Bridge troubleshooting

This topic covers the following scenarios:
l "Bridge is not identified after installation" on the next page
l "Bridge name is displayed in red in ALM Octane" on the next page
l "Integration Bridge remains Offline even after stopping and starting the bridge" on the next
page
l "Bridge connection status displayed as Unknown in ALM Octane" on the next page
l "Bridge cannot log in to ALM Octane, ALM, or JIRA" on page 342
l "A '403' or 'Authorization Exception' error occurs" on page 342
l "(Linux) Integration Bridge installation process implies an old one exists" on page 342
l "Errors during synchronization: "Missing required field"" on page 342
l "How do I modify the URL that the Integration Bridge uses to connect to ALM Octane?" on

Synchronization
page 343
l "On-premises: Download of the Integration Bridge Agent fails after 20 minutes" on page 343
Bridge is not identified after installation
If the bridge does not appear on the Synchronizer or Link Configuration page in ALM Octane
after installation is complete, click Refresh, or refresh the browser page.
l If the bridge still does not appear, make sure the bridge is running. For details, see "Start and
stop the Integration Bridge" on page 334.
The Integration Bridge service attempts to start the bridge several times. If it is not successful,
the application shuts down and the service stops.
l If the bridge does not start, make sure the value of the Drmi.server.port in the <installation
folder>\product\log\controller\wrapper.log file is set to an available port.
l If the defined port is in use by another application when the Integration Bridge service
attempts to start the bridge, the following errors are printed to log files:
In the wrapper log file java.rmi.server.ExportException: Port already in use:
<port>
In the controller log file java.rmi.NotBoundException: ControllerAPI
Bridge name is displayed in red in ALM Octane

The Integration Bridge is down. In ALM Octane, click the bridge name to view the last time the
bridge accessed the server.
Integration Bridge remains Offline even after stopping and starting the bridge
If the connection status of your bridge is displayed as Offline in ALM Octane, try restarting the
bridge. For details, see "Start and stop the Integration Bridge" on page 334.
Bridge connection status displayed as Unknown in ALM Octane

Check the following log files in the Integration Bridge log folder (<Bridge_installation_
directory>\product\log\controller):
l controller.log
l wrapper.log
Additionally, check the <Endpoint type name>.log file located in the <Bridge_installation_
directory>\product\log\<Endpoint type name> directory.

Synchronization
Bridge cannot log in to ALM Octane, ALM, or JIRA

Check the connection setup defined for the endpoint:
l Check the credentials defined for the endpoint.
l Check proxy configuration if relevant.
l If ALM or JIRA is configured to require HTTPS for logging in, configure the bridge to connect
to ALM or JIRA using HTTPS.

For details, see "Manage connection setup" on page 320 and "Integration Bridge security" on
page 317.
A '403' or 'Authorization Exception' error occurs

The user accessing ALM Octane from the Integration Bridge is not defined with the Integration
Bridge role.
Modify this user's role in the ALM Octane configuration area (Site > Users).
Note: For security purposes, the Integration Bridge user should not have any additional
roles.
(Linux) Integration Bridge installation process implies an old one exists

Issue: You uninstalled the Integration Bridge, but the next time you install a bridge, the suggested
default name implies that a bridge already exists.
Cause: You might have performed the uninstall using a non-root user.
Solution:
l You can ignore the listed existing bridge, and install a new one.
l Locate and remove the init scripts that were left over from the Integration Bridge service
installation.
Errors during synchronization: "Missing required field"

Issue: During a synchronization run, some entities fail to synchronize. The errors indicate that a
required field is missing. However, in the Link Configuration page, I do not see any mandatory
fields that are not mapped.
Cause:
A field that is currently mandatory in ALM or JIRA is not mapped, or it is mapped to an ALM
Octane field that does not contain a value.
l The field in question may have been marked as mandatory in ALM or JIRA after the link or
entity itself was created.

Synchronization
l The field might be mandatory in ALM or JIRA only when other fields contain certain values.
Solution:
Map the field to an ALM Octane field that contains a value, or manually enter a value in ALM
Octane for the relevant field.
How do I modify the URL that the Integration Bridge uses to connect to ALM Octane?
The URL that the Integration Bridge uses to connect to ALM Octane is downloaded from ALM
Octane with the Integration Bridge. In most cases, you should not need to modify this URL.
If the URL for your ALM Octane changed, or if your system administrator designated a different
ALM Octane node to handle synchronization, do the following:
1. Navigate to the <Integration Bridge installation folder>\product\conf folder (on Linux,
reverse the slashes).
2. Open the server-connection.conf file for editing.
3. Update the server.base.url property with the new URL.
Format: http(s)://<server hostname or IP address>:<port number>/opb
Tip: If you can login to the ALM Octane that you want the Integration Bridge to use,
login and then use the URL from your address bar. Take the URL from the beginning
up to /opb. Ignore the rest.
4. Restart the bridge.
On-premises: Download of the Integration Bridge Agent fails after 20 minutes

If the download of the Integration Bridge agent stops after 20 minutes and the zip archive is
corrupted, your connection is too slow to download the full package, and the download is
cancelled.
In this case you need to increase the agent default download time from 20 minutes to a more
relevant time. To do so, edit the web.xml file located in <sync_install_dir>/webapps/sync/WEB-
INF/ and change downloadMaxRequestMs. Note that the time is in milliseconds.
After you change the value, restart the Synchronizer service.
Synchronize ALM Octane with ALM or JIRA

Synchronize your ALM Octane workspaces with your ALM or JIRA projects to view and update
your releases, backlog, and defects in both endpoints.
In this topic:
l "Synchronization overview" on the next page
l "Synchronization links and endpoints" on page 345

Synchronization
l "Supported ALM and JIRA versions" on the next page
Synchronization overview
ALM Octane Synchronizer enables administrators to configure synchronization between ALM
Octane and ALM or JIRA from the ALM Octane settings area.
To configure synchronization, Synchronizer admin permissions are required.

When you synchronize with ALM, your ALM Octane user stories, features, and epics are all
synchronized as requirements in ALM. When you synchronize with JIRA, your ALM Octane user
stories and features are synchronized as user stories and epics in JIRA. Epics in ALM Octane are
not synchronized in JIRA.
ALM Octane Synchronizer checks ALM Octane and ALM or JIRA for recent updates in the
synchronized items, and updates the other endpoint accordingly. You can configure the direction
in which changes are synchronized between the endpoints: from ALM or JIRA to ALM Octane,
from ALM Octane to ALM or JIRA, or in both directions.
Before setting up synchronization you should be aware of the following:
l Rules. When synchronizing, ALM Octane rules are activated during synchronization. For
example, if setting a value in one field makes another required, synchronization will fail if the
endpoint does not provide a value for the newly required field.
l Workflow. When synchronizing with ALM, workflow procedures defined on either endpoint are
ignored while creating and updating synchronized data. For example, the workflow normally
prohibits updating a defect phase from New to Fixed. However, if Synchronizer needs to assign
a Fixed value to a New defect, it will succeed.
When you add or delete a phase in the ALM Octane workflow settings, it takes up to 5 minutes
to see the change in Synchronizer phase value mapping.
l When synchronizing with JIRA, the Synchronizer creates "dummy" entities to learn the JIRA
workflow for the status field, for the relevant issue types. As a result, Synchronizer supports
status changes that should contain several status transitions to reach a desired state, because
Synchronizer moves the entity to the correct phase or status according to the allowed path in
the workflow.
l Quality stories in ALM Octane are not synchronized.

Synchronization
Synchronization links and endpoints

Synchronization is defined by links, which you create and manage in the ALM Octane
Synchronizer settings page. This settings page can be accessed only by Synchronizer Admin
users.
Links are created between a pair of endpoints, namely an ALM or JIRA project and an ALM
Octane workspace. You can set automatic synchronizations, or run manual synchronizations to
synchronize records between the endpoints.
Each synchronization link defines the following:
l The directions in which the endpoints are updated (ALM or JIRA > ALM Octane, ALM Octane
> ALM or JIRA, or both).
l The favorites used to find records with new data in each endpoint.
Creating multiple links

Each link synchronizes a specific entity type between a single ALM or JIRA project and a single
ALM Octane workspace. Create separate links to synchronize defects, requirements, and releases
between the same two endpoints.
You can create multiple links between a single ALM Octane workspace and multiple ALM or JIRA
projects, even if the projects are stored in different versions of ALM or JIRA. In such a case, use
ALM Octane favorites to separate the synchronized data inside the workspace.
To prevent data leaks between workspaces, ALM Octane Synchronizer does not support multiple
links between a single ALM or JIRA project and multiple ALM Octane workspaces in the same site.
Supported ALM and JIRA versions

For details on the ALM and JIRA versions supported by ALM Octane synchronization, see
"Installation, setup, and synchronization" on page 61.
Unless otherwise specified, references to ALM in this Help Center apply to all currently supported
versions of ALM and Quality Center. Note that some features and options may not be supported
in the specific edition of ALM or Quality Center that you are using.
Synchronization steps
This section lists the steps involved in setting up synchronization.
Caution: Before setting up synchronization on a production system, we recommend

synchronizing an experimental ALM Octane workspace and ALM or JIRA project.

Synchronization
Prerequisites
Before you begin, perform the following prerequisite steps. These steps need to be performed
once for every ALM or JIRA instance.
To integrate: Perform the following:

ALM <-> ALM Octane on Contact your SaaS operator and request setup of the Integration
SaaS Bridge between ALM Octane and your ALM instance.
l ALM <-> ALM Octane 1. Install the Synchronizer as described in the Synchronizer
on premises Installation Guide. This is included in the Synchronizer
l JIRA <-> ALM Octane installation package, from Micro Focus download sites.
on SaaS 2. After you configure the Synchronizer, you need to install and
l JIRA <-> ALM Octane configure the Integration Bridge, as described here: "Set up
on premises the Integration Bridge Agent" on page 311.
Synchronization workflow
Working with ALM Octane Synchronizer involves the following steps:
Step Description
"Prepare for Make recommended modifications to your ALM or JIRA project and
ALM synchronization" ALM Octane workspace to ensure smooth synchronization.
on page 348
"Prepare for JIRA
synchronization" on
page 355
"Step 1: Define a Space admin: Define a Synchronizer Admin user to manage the

Synchronizer Admin synchronization links.
user" on page 361
The Synchronizer admin role is required for all of the remaining
steps.

Synchronization
Step Description
"Step 2: Define the Create favorites for ALM Octane Synchronizer to use when looking
synchronization scope" for new records in ALM, JIRA, or ALM Octane.
on page 361
If no favorite is configured, all records are considered for
synchronization.
You can perform this step before setting up ALM Octane
Synchronizer, or come back and do it later.
Tip: We recommend creating integration favorites before

your first synchronization. Run a simulation using your
favorite to verify that synchronization works as you expect.
"Step 3: Create a Use the wizard to help you define your connection data to ALM or
synchronization link" on JIRA, the favorites used to filter data, and the directions in which
page 363 the endpoints are updated.
"Step 4: View and edit Check the mappings and settings that were created automatically
link configuration" on for your link, and make any adjustments necessary.
page 370
"Step 5: Configure Configure Synchronizer to send notifications about issues

synchronizer occurring during synchronizations.
notifications" on
Link notifications are configured for all links in a workspace. Bridge
page 390
notifications are configured per bridge.
"Step 6: Run Run an integrity check to prevent errors during synchronization,

synchronizations" on and an optional simulation to understand details about the data
page 391 that will be updated.
Run manual synchronizations or enable synchronizations to run
automatically.
"Step 7: Review link Review the status of your links and investigate any errors that may
summaries and error have occurred during synchronization.
details" on page 395
You can view the run history for a specific link in the Run History
tab.
See also:
l "Synchronize ALM Octane with ALM or JIRA" on page 343
l "Link status reference" on page 397

Synchronization
l "How can I improve synchronization performance?" on page 401
Prepare for ALM synchronization

Before synchronizing records between ALM Octane and ALM, adapt the data in either endpoint
to match the fields supported in the other endpoint, as well as synchronization requirements.
For example, ALM Octane defects can also be associated with a feature. To synchronize this field,
you must create a corresponding user-defined field in ALM.
In ALM Octane, user stories are often arranged in a hierarchy, under features and epics. To
synchronize these records and their hierarchy with ALM, you must create a corresponding
hierarchy of requirement types.
In this topic:
l "Optional: In both endpoints, create corresponding ID fields" below
l "Create a subset of requirements or releases" below
l "In ALM, prepare requirement types to match ALM Octane's (requirement synchronization)" on
page 350
l "Check for releases that already exist in both endpoints (Releases synchronization)" on
page 351
l "In ALM, create or modify fields" on page 353
l "ALM version control" on page 354
l "Notes for epics, features, teams, and attachments" on page 355
l "Notes about maximum record sizes" on page 355
Optional: In both endpoints, create corresponding ID fields

In both endpoints, we recommend creating user-defined or custom fields to represent the record
ID in the other endpoint. Define these fields as Number or Numeric fields.
l In ALM, create a field named ALM Octane ID.
l In ALM Octane, create a field named ALM or QC ID.
Later, map these corresponding fields in the link's Field Mapping tab. For details, see "Edit field
mapping" on page 376.
Create a subset of requirements or releases

By default, ALM Octane Synchronizer synchronizes:
l the entire ALM Requirements root folder, including sub-folders.
l all current releases (with an end date that has not yet passed) in the ALMReleases root folder,
including sub-folders.

Synchronization
To synchronize only a subset of the requirements or releases in your ALM project, you can specify
an alternate root folder in the synchronization link.
Note: If you use both favorites and alternate root folders, Synchronizer considers the
alternate root folder before the favorites.
In the ALM project's tree, create a sub-folder that contains only the requirements or releases that
you want to synchronize. This sub-folder can also include additional sub-folders.
Example of an alternate root folder

In the image below:
l The user stories in ALM OctaneWorkspace1 are synchronized with the requirements in the
ALMAG_Project1 folder instead of the Requirements folder.
l The user stories in ALM OctaneWorkspace2 are synchronized with the requirements in the
ALMAG_Project2 folder instead of the Requirements folder.
l In both ALM projects, other folders in the Requirements folder are ignored by ALM Octane
Synchronizer. If there are additional sub-folders under the AG_ProjectX folders, all mapped
requirement types they contain are synchronized.
l You could similarly set up an alternate root folder for releases.
For details on defining the alternate root folder in your synchronization link, see "Optional
(ALM only): Define an alternate root folder (requirement and release links)" on page 368.

Synchronization
In ALM, prepare requirement types to match ALM Octane's (requirement

synchronization)
Decide on ALM requirement types that represent ALM Octane epics, features, and user stories,
and arrange them in a hierarchy that matches the one in ALM Octane.
Rules for matching the ALM and ALM Octane hierarchies

l You can map one or more ALM requirement types to each of the ALM Octane types: user story,
feature.
l You can map only one ALM requirement type to ALM Octane epics.
l If you do not map a specific ALM requirement type, requirements of that type are not
synchronized.
l ALM Octane quality stories are not synchronized.
l If your ALM hierarchy does not match the ALM Octane hierarchy, Synchronizer can
synchronize requirements directly to the root of ALM Octane's backlog tree. This is relevant
only for requirements mapped to epics or user stories. For details, see "Optional: Specify how to
handle requirements whose hierarchy does not match the backlog tree (requirement links)" on
page 369.
l Synchronization may fail if:
l You do not map all requirement types, including Epic, Feature, and User Story.
l Synchronized requirements are not located in the correct location in the ALM hierarchy. For
example, if a feature requirement is located under a user story requirement in the ALM
requirement tree.
l You change a requirement's type after it was synchronized.
To create the requirement hierarchy in ALM

1. If needed, create new user-defined requirement types in ALM customization.
Note: You can include requirements of type Folder in your hierarchy. These are
considered requirement sub-folders. Folder type requirements are not synchronized,
but the requirements they contain are synchronized.
Here is a suggestion for a simple hierarchy to use:

l Use the ALM's out-of-the-box Business requirement type to represent epics.
l Use ALM's out-of-the-box Functional requirement type to represent features.
l Create a new User Story requirement type in ALM to represent user stories.

Synchronization
2. Create or modify the requirement tree with a maximum of three levels (representing epics,
features, and user stories).
l Requirements synchronized with epics must be at the top of the hierarchy.
l Requirements synchronized with features must be under epics.
l Requirements synchronized with user stories can be under features, or at the top level,
but not under epics.

ALM Octane Synchronizer retains the hierarchy during synchronization.
The three-level hierarchy can be stored in any requirement folder or sub-folder. In ALM
Octane, the synchronized tree is stored under the Backlog root.
Example of a requirement hierarchy
Requirement type mapping:

l ALM Group requirements >> ALM Octane epics.
l ALM Functional requirements >> ALM Octane features.
l ALM Performance and Testing requirements >> ALM Octane user stories.
After synchronizing:
l The requirements ALM Group 001 (epic) and ALM Group 002 (epic) are created on ALM
Octane as two sibling epics under the root of the ALM Octane backlog tree.
l The requirement ALM Functional 002 (feature) is created as a feature under the epic ALM
Group 002 (epic).

l The requirement ALM Testing 002 (userstory) is created as a user story under the feature
ALM Functional 002 (feature).

l The requirement ALM Performance 002 (userstory 2nd) is created as a user story under the
root of the ALM Octane backlog tree.
Check for releases that already exist in both endpoints (Releases

synchronization)
Check whether you have releases or sprints/cycles with the same names defined in both ALM and
ALM Octane. If you do, we recommend that in the release synchronization link, you select the Map
pairs of new releases and sprints/cycles with identical names option.

Synchronization
The data from the dominant endpoint is then used for all release entities, overriding any data in
the other endpoint.
Why select this option?

If identically named releases or sprints are found and are not mapped, these releases or sprints are
not synchronized at all and a "duplicate entities" error is generated in the Run Report.
This is because ALM Octane Synchronizer tries to handle the release as a new record, creating it in
the destination endpoint.
The synchronization fails because the destination endpoint already has a release or sprint/cycle
with the same name.
If you later change the name of one of the releases or sprints, so that the duplication does not
occur, the ALM Octane Synchronizer re-creates it in the destination endpoint.
Mapping option is limited to current releases

When mapping, ALM Octane Synchronizer checks only the releases that are included in the
synchronized time frame. Releases or sprints/cycles with identical names are not mapped if they
are in a past release (or a release whose end date is older than the one you specified for
synchronization).
For details on synchronizing past releases, see "Synchronize past releases" on page 363.
For example:
If... Then...
l You have a current ALM release named l The two releases are mapped.
Release_1.3, as well as a current l All data in the ALM release Release_1.3 is
ALM Octane release named Release_1.3 overwritten by the data in the ALM Octane
l You define ALM Octane as the dominant release Release_1.3.
endpoint for the release link fields (in the
Field Mapping tab)
l You select the Map pairs of new releases
or sprints found with identical names
option in the Rules tab

Synchronization
If... Then...
l You have: The ALM release is not relevant for mapping,
An ALM release named Release_1.3, because it is too far in the past.
whose end date is July 20, 2017. However, synchronizing Release_1.3 to ALM
An ALM Octane release named Release_ fails because it tries to create a release on
1.3. whose end date is July 30, 2017. ALM with a name that already exists.
l You define ALM Octane as the dominant
endpoint for the release link fields (in the
Field Mapping tab)
l You select Synchronize past releases. End
date can be this date or later: July 25,
2017.
l You select the Map pairs of new releases
or sprints found with identical names
option in the Rules tab.
In ALM, create or modify fields

In ALM, modify the fields listed in the following table. If a field does not already exist in ALM,
create a user-defined field to correspond to this data in ALM Octane. For details about mapping
fields after setting up your link, see "Edit field mapping" on page 376.
Defining fields as Lookup List fields lets you have empty lists, but still use this field for grouping in
ALM.
Field name Description

Application Define as a Lookup List field.
module
Configure ALM to Allow Multiple Values and not to verify this value.
Tip: Alternatively, when editing your link, map the ALM Octane
Application module field to the ALM Product field.
Owner Define as a User List field.
Blocked Define as a String field.
Feature Define as a Lookup List field.

Configure ALM not to verify this value.
Rank Define as a Number field.

Synchronization
Field name Description

Story points Define as a Number field.
Phase Define as a Lookup List field.

Team Define as a Lookup List field.

Epic Define as a Lookup List field.

Note: Required for requirements being synchronized as features.
Tip: You may want to create an additional user-defined field to distinguish between
entities created directly in ALM and those synchronized from ALM Octane.
To do so, create a field in ALM named Creation Method. Later, when you are mapping
fields, assign a constant value of created by ALM Octane Synchronizer. For details about
assigning constant values, see "Edit field mapping" on page 376.
ALM version control

If you synchronize with an ALM project that uses version control, ALM Octane Synchronizer
conforms to the versioning rules. Changes made by the synchronization process are checked in
with a comment: Modified by Synchronizer.
During synchronization, ALM Octane connects to ALM using the credentials of an ALM user that
you specify.
l When synchronizing an entity that is checked out by that user, the entity is updated and
checked in.
l When synchronizing an entity that is checked out by a different user, the ALM entity is not
modified.
l If the synchronization is governed by the ALM Octane side, a synchronization error occurs
due to the locked entity in ALM.

l If the synchronization is governed by the ALM side, the ALM Octane entity is updated
based on the last checked-in version on ALM.

Synchronization
Notes for epics, features, teams, and attachments

Epics and feature names must be unique in both ALM and ALM Octane, and team names must be
unique in ALM. If duplicate values are found during synchronization, the related record is not
synchronized.
In ALM Octane, records assigned to a specific feature must also have an epic defined. If you
synchronize features, you must also synchronize their epics. Therefore, if you map epic and
feature fields, we recommend making them required fields in ALM to avoid synchronization
errors.
Note: Avoid special characters (~!@#$%()^&) in attachment names, as these may cause
unexpected behavior during synchronization.
Notes about maximum record sizes

ALM Octane Synchronizer supports a maximum record size of 12 MB. This means that
synchronizing records larger than 12 MB will cause errors.
If you have records that are larger than 12 MB, move some of the data from the Description,
Comment, or any other custom free text field, to a separate file. Then, add the file to the record as
an attachment. Attachment sizes are not included in the maximum record size, though they are
synchronized between the endpoints.
See also:
l "Step 1: Define a Synchronizer Admin user" on page 361
l "Synchronization steps" on page 345
Prepare for JIRA synchronization

Before synchronizing records between ALM Octane and JIRA, adapt the data in either endpoint
to match the fields supported in the other endpoint, as well as synchronization requirements.
Note: The authentication to JIRA REST API is done through basic authentication, based
on the capabilities provided by JIRA. The integration user that is used in the
synchronization must have minimal permissions to perform the required operations.
In this topic:
l "Create mandatory entities in ALM Octane and JIRA" on the next page
l "Create optional entities if needed" on the next page
l "Synchronize sprints" on page 357

Synchronization
l "Mapping multiple JIRA projects" on the next page

l "Notes and limitations" on page 360
Create mandatory entities in ALM Octane and JIRA

l Before synchronizing ALM Octane and JIRA, you should have at least one JIRA issue from
each type defined in your system. For example, the default Jira issue types are epic, story,
subtask, defect and task. If you are missing any one of these, create a "dummy" entity that you
can manually delete later.
At the end of the synchronization process, the Synchronizer removes the "dummy" entities if
the JIRA user has permission to delete entities. Otherwise, these "dummy" entities will remain in
the project.
Tip: If you do not want to create a separate JIRA issue for every issue type, you can edit
the file jira\conf\adapter.properties which defines which issue types are synchronized.
a. Uncomment the entry issuetypes.requirement and specify which issue types you
want to synchronize, using commas but no blank spaces. For example:
issuetypes.requirement = Feature,TestIssue,Story
Note that Story is mandatory.
b. After saving your changes to the file, stop the Integration Bridge service and then
start it again using Stop and Start.
l In ALM Octane, each release must have a start and end date, but in JIRA these dates are
optional. To enable synchronization, each entity in JIRA must be associated with a release that
has a defined start date. Make sure all of your JIRA entities meet this requirement before
synchronizing.
Create optional entities if needed

l In epics, the summary field is mandatory in JIRA but does not exist by default in ALM Octane. If
you want to map summary data from JIRA, create a summary field in ALM Octane before
synchronizing. (In other entities, summary is mapped by default to the name field in
ALM Octane.)
If you do not need the summary field in addition to the epic name, you can map the
ALM Octane name field with one direction to the summary field in JIRA.
l Phases in ALM Octane are called Status in JIRA. These values are mapped by default, but if you
customized these fields in ALM Octane or JIRA you will need to manually adjust the mapping
accordingly.

Synchronization
Synchronize sprints
Sprints in ALM Octane are always associated with a specific release, with a specific start and end
date. In JIRA the only definition of a sprint is a time frame, and within a time frame you can have
issues that belong to different versions. In addition, JIRA sprints are defined in the context of a
board, and a sprint can appear in multiple boards. As a result of these differences, sprints are
synchronized between ALM Octane and JIRA according to the following guidelines:
Creating and updating sprints

Sprints created or updated in ALM Octane can be synchronized to JIRA using the Releases link.
However, sprints that are created in JIRA cannot be synchronized to ALM Octane.
Sprints that are defined in ALM Octane are then synchronized to the first board defined in the
mapped JIRA project. These sprints are “flattened” in JIRA, and do not belong to a specific
release.
There is no ability to turn off sprint creation on the Releases link from ALM Octane to JIRA.
Assigning sprints to defects or requirements

If you have sprints defined in both ALM Octane and JIRA, you can map them to one another
using the Defects and Backlog links. In this case, there are two options for mapping:
l Map the ALM Octane Sprint field <-> JIRA Sprint field. In this case the mapping will be by ID,
with a fall-back to name mapping if necessary. When a defect or user story is assigned to a
sprint, ALM Octane forces the entity to also be assigned to the matching release.
l Map an ALM Octane user defined field called Sprint (of type List) <-> JIRA Sprint field. In this
case the sprint in ALM Octane will not be a real sprint but only an attribute. The mapping will be
by name so make sure the names on both sides match.
Tip: If the sprint assignments are originally set in JIRA, start with setting the mapping
direction from JIRA to ALM Octane only. You can later switch to bi-directional mapping if
relevant to your use case.
Mapping multiple JIRA projects

When synchronizing with JIRA you can map multiple JIRA projects to a single ALM Octane
workspace, using the JIRA optional fields Project Name and Project Key.
1. For each entity that you are synchronizing (defect, feature, and user story), create two user-
defined fields in ALM Octane: Project Name and Project Key. The UDFs should be field type
String. For details, see "Customize fields" on page 547.
2. In Synchronizer, map these fields from JIRA to ALM Octane as follows:

Synchronization
l Project (Jira) > Project Name (ALM Octane)

l Project Key (Jira) > Project Key (ALM Octane)
3. In the ALM Octane Backlog module, create a filter for each entity using the Save filter to
Synchronizer button . For details, see "Create favorites" on page 362.
In the filter, define the Project Key field to match your Project Key value in JIRA.
Example: Suppose we want to synchronize features and user stories. We create a

filter for features in the Backlog > Features tab:

Synchronization
Then we create a filter for user stories in the Backlog > Backlog Items tab:
4. In the Synchronizer General tab, select the link where you mapped the project name and key
earlier. Click Edit link, and specify the filters that you created in the Backlog module. You can
select multiple filters for a Backlog link:

Synchronization
5. Run the synchronization.

The items that are synchronized from JIRA to ALM Octane are populated with values for the
Project Key and Project Name fields. Note that this workflow is one-directional, and is supported
only from JIRA to ALM Octane. Do not change the values of these fields in ALM Octane.
Notes and limitations

l ALM Octane uses a hierarchy of epics > features > stories, while JIRA uses epics > stories. When
you synchronize, map features in ALM Octane to epics in JIRA. Epics in ALM Octane will not be
synchronized to JIRA.
l If you have epics in ALM Octane, when you create a Backlog link you must select the
Synchronize epics and user stories to the Backlog root checkbox.
l If a defect is associated with an epic or story, synchronization does not carry over this
association.
l Attachments are not carried over during synchronization. Instead, a link to the attachment is
created, enabling you to access the attachment when needed.
l Multi-value lists of complex types (for example multi-value user types) are not supported.
l Comment fields are synchronized from JIRA to ALM Octane. However, comments which
originated in ALM Octane lose their original user name in JIRA, and are assigned the name of
the user used by the REST API.
l Versions associated with defects in JIRA are mapped to releases in ALM Octane. However, in
ALM Octane releases are single value lists (unlike releases in JIRA), so that if you have multiple
versions in a defect in JIRA, ALM Octane only takes the first value in the list.
l In JIRA every release has a status, but not in ALM Octane. Release status is not synchronized.
l The integration does not support the following two mappings together: Octane Sprint ->
JIRA Sprint and Octane UDF Sprint <- JIRA Sprint.
l The following fields are supported in Release synchronization: Name, Start date, End date, and
Description.
l Rich text is not supported in the release description.
l If you delete a release in JIRA or ALM Octane after they have been synchronized, and then run
a manual sync, the manual sync does not recreate the deleted release, but rather fails with an
error.
l One-day long sprints are not synchronized from ALM Octane to JIRA.
l If you perform the following steps, sprints are not recreated from JIRA to ALM Octane:

Synchronization
a. Create a release in both ALM Octane and JIRA.

b. Select the rule “Recreate the record in ALM Octane based on the corresponding record in
JIRA.”
c. Run Manual Sync. This creates two releases in ALM Octane and two in JIRA, because the
sync copies each endpoint’s record to the other endpoint.
d. If you delete the original release in both JIRA and ALM Octane, the deleted release is
recreated from the other endpoint based on the rule, but sprints are not recreated from
JIRA to ALM Octane.
See also:
l "Step 1: Define a Synchronizer Admin user" below
Step 1: Define a Synchronizer Admin user

Before using ALM Octane Synchronizer, assign the Synchronizer Admin role to one or more of
the ALM Octane users.
For details about assigning roles in the Spaces > Users settings page, see "Assign roles and
If you work with multiple workspaces, make sure that you assign a user to the Synchronizer
Admin role for each workspace you want to synchronize.
If you want the same user to be able to configure links from multiple workspaces, make sure that
this user is assigned to the Synchronizer Admin role in all relevant workspaces.
Synchronizer Admin users are responsible for the following:
l Creating and managing links
l Scheduling and running tasks
l Monitoring and troubleshooting errors
The Synchronizer settings area, where you create and manage synchronization links, is only visible
to Synchronizer Admin users.
See also:
l "Step 2: Define the synchronization scope" below
Step 2: Define the synchronization scope

You can modify the scope of synchronization using favorites, and by specifying whether to
include past releases. In ALM you can also create a subset of releases or requirements to

Synchronization
synchronize.
In this topic:
l "Create favorites" below
l "Synchronize past releases" on the next page
Create favorites
When synchronization is run, the synchronizer looks for new records in ALM Octane and ALM or
JIRA based on the favorites configured for the link. If no favorite is configured, all records are
synchronized. If a favorite is configured, items included in the selected favorite are synchronized
with the other endpoint as newly created items. It is recommended to use favorites, but not
required.
Favorites are specifically useful when first configuring your link. Start by using a favorite that
contains only one record, and expand it slowly. Run simulation synchronizations to verify that the
synchronization works as you expect.
How to use favorites

l In ALM Octane, a user with Synchronizer Admin role can create or modify Synchronizer filters
in the Backlog module (for epics, features, and user stories) and the Defects module (for
defects), using the Save filter to Synchronizer button .
We recommend that you save a Favorite in ALM Octane with the same name as the
Synchronizer filter, to be able to modify the filter. If you modify the Favorite, you must
overwrite the Synchronizer filter as well.
When defining a filter, do not use relative labels such as current user (“Me”), current release, last
24 hours, last 7 days, or last 30 days.
l In ALM or JIRA, the selected favorite must be available to the integration user used by the
integration bridge to connect to ALM or JIRA.

You can select from a maximum of 50 favorites for a specific ALM project.
Remember to schedule a full synchronization each time you modify a favorite to synchronize the
newly included records. For details, see "Full synchronizations" on page 394.
You can select favorites to use for synchronization when creating or editing the link. For details,
see:
l "Optional: Select favorites (requirement and defect links)" on page 368
l "View or modify synchronization favorites (defect and requirement links)" on page 373

Synchronization
Caution:
l Once a record in one endpoint is mapped to a record in the other endpoint, these
records continue to be synchronized even if they no longer match the link's favorite. Be
sure that you want to synchronize data in a specific record or type of record before
including it in your favorite.
l When a new requirement is created in the master endpoint, and the requirement is the
child of requirements that were not previously synchronized, the parent requirements
are also created in the other endpoint. If a favorite is defined, the parent requirements
are synchronized even if they do not match the favorite.
Synchronize past releases

By default only current and future releases are synchronized. Releases with an earlier end date in
ALM Octane, ALM, or JIRA are not synchronized. However, you can also instruct synchronizer to
include past releases.
To synchronize past releases:
1. Determine the end date of the oldest release you want to synchronize.
2. Specify this date on the Rules tab of your synchronization link, when selecting the
Synchronize past releases... option. For details, see "Specify how to handle existing or past
releases (release links)" on page 369.
See also:
l "Step 3: Create a synchronization link" below
Step 3: Create a synchronization link
To create a synchronization link:

1. From the ALM Octane settings area, select Synchronizer.
2. Do one of the following to open the Add Link wizard.
l To create your first link, click Create synchronization links.
Caution: If the button is disabled and no Integration Bridge is installed, do one of

the following:

Synchronization
o JIRA/On-Premises ALM. Follow the instructions here: "Set up the Integration

Bridge Agent" on page 311.
o SaaS ALM: To synchronize with SaaS ALM, ask ALM Octane Support to install
and configure the integration bridge (Help > Send Us Feedback > Open
ticket).
l For additional links, select a bridge on the left of the Link Configuration page and click
Add Link.
Tip: If the Synchronizer opens to the Dashboard and you see the Links
summary, click to open the Link Configuration page.
3. Use the wizard to configure your link, following the steps described below.
The order of the steps may vary, depending on the type of entity synchronized over this link
(defects, requirements, or releases).
l "Define connection settings" below
l "Define link properties" on the next page
l "Map requirement types (requirement links)" on page 366

l "Set the rules that define which endpoint controls the synchronized entities" on page 366
l "Optional: Select favorites (requirement and defect links)" on page 368
l "Optional (ALM only): Define an alternate root folder (requirement and release links)" on
page 368
l "Optional: Specify how to handle requirements whose hierarchy does not match the
backlog tree (requirement links)" on page 369
l "Specify how to handle existing or past releases (release links)" on page 369
Define connection settings

1. Select the type of connection you are creating: ALM or JIRA.
2. Select Existing Connection and choose a previously defined endpoint, or select New
Connection and populate the following fields:
Field Description
For ALM: URL to the ALM deployment that hosts the project you want to
ALM/QC synchronize with.
Server URL Use the following syntax: http(s)://<hostname>:<port>/qcbin

Synchronization
Field Description
For JIRA: URL to the JIRA deployment that hosts the project you want to
JIRA synchronize with.
Server URL Use the following syntax: http(s)://<hostname>:<port>
Note: The following URL formats are accepted as input:
l JIRA-DOMAIN:PORT (e.g. http://sync.almoctane.com:8086)

l JIRA-DOMAIN:PORT/login.jsp (e.g.
http://sync.almoctane.com:8086/login.jsp)
l JIRA-DOMAIN:PORT/BASEPATH (e.g.
http://sync.almoctane.com:8086/jira)
l JIRA-DOMAIN:PORT/BASEPATH/secure/Dashboard.jspa (e.g.
http://sync.almoctane.com:8086/secure/Dashboard.jspa)
Endpoint Identifies this connection to ALM or JIRA.

Display
Name Tip: Assign this name when creating a new link. If you later select
Existing Connection to create additional links to this project, you
can select this display name from the list.
Credentials Select a predefined credentials record from the drop-down list.

Display These records are defined by ALM Octane Support when they install your
Name Integration Bridge.
For ALM: Enter the ALM domain and project you want to synchronize with.
ALM/QC Click Authenticate to retrieve available values, and select the domain or
Domain project names from the listed items.
and Project
For JIRA: Enter the JIRA project you want to synchronize with.
JIRA Click Authenticate to retrieve available values, and select the domain or
Project project names from the listed items.
Define link properties

1. Select the type of entity synchronized over this link (defects, requirements, or releases).
2. Define a name for your link, and an optional description.
3. If you work with multiple workspaces, select the workspace you want to synchronize with

Synchronization
ALM or JIRA.
If you do not see your workspace in the drop-down list, make sure you are defined as a
Synchronizer Admin in this workspace. For details, see "Step 1: Define a Synchronizer Admin
user" on page 361.
4. Click Check Connectivity and Continue.
Map requirement types (requirement links)
ALM:
Specify the ALM requirement types that match user stories, features, and epics, according to the
hierarchy that you defined in advance in ALM. For details on setting up this hierarchy, see "In
ALM, prepare requirement types to match ALM Octane's (requirement synchronization)" on
page 350.
You can map multiple ALM requirement types to user stories and features. Specify one type as
the default for ALM. This requirement type is used when synchronizing new ALM Octane items
with ALM.
JIRA:
Map JIRA epics and stories to ALM Octane features and stories. Note that ALM Octane has three
levels of hierarchy while JIRA has two levels, so ALM Octane epics are not mapped.
You can then define which endpoint controls the synchronized entities.
Note: Only mapped requirement types are synchronized.
Set the rules that define which endpoint controls the synchronized entities
Select where you plan to manage your releases, defects, and different types of requirements.
Caution: ALM Octane does not support custom release fields.
For releases, Synchronized data includes:

l Releases: Names, start and end dates, descriptions, and attachments.
l Sprints/cycles: Names, start and end dates.
If you have custom release fields that are mandatory in ALM or JIRA, synchronize release
data only from ALM or JIRA to ALM Octane, and not from ALM Octane to ALM or JIRA.

Synchronization
l Select one of the following:

Option Description
ALM Select this option to create defects, requirements, or releases in ALM Octane
Octane only.
During synchronization, corresponding entities are created automatically on
ALM or JIRA.
Updates made to existing entities in either endpoint are synchronized with the
other endpoint.
For requirement links: This option means that you manage the entity's
hierarchy (epic > feature > user story) in ALM Octane. Changes that you make
to the structure of your requirements tree in ALM or JIRA will be reverted by
the synchronization.
ALM/JIRA Select this option to create defects, requirements, or releases in ALM or JIRA
only.
During synchronization, corresponding entities are created automatically on
ALM Octane.
Updates made to existing entities in either endpoint are synchronized with the
other endpoint.
For requirement links: This option means that you manage the structure of
your requirements tree in ALM or JIRA. Changes that you make to the entity's
hierarchy (epic > feature > user story) in ALM Octane will be reverted by the
synchronization.
Both Select this option to create and update defects, requirements, or releases in
ALM both ALM Octane and ALM or JIRA, for a full range of planning and testing
Octane functionality. Changes made in either endpoint are synchronized with the other
and endpoint.
ALM/JIRA
Note: Two options are available for managing entities in both endpoints.
One sets ALM Octane as the dominant side, in case of conflicts, and the
other sets ALM or JIRA as the dominant side.
For requirement links: This option means that you can change the entity's
hierarchy (epic > feature > user story) in either endpoint. Changes that you
make to the structure of your requirements tree are synchronized in the other
endpoint. In case of conflict, the structure of the dominant side is used.
l When you synchronize a release, all related ALM Octane sprints are synchronized with ALM
cycles or JIRA sprints.
For a release link, select the endpoint to use as the dominant side for sprint and cycle
synchronization, in case of conflicts.

Synchronization
You can view the rules in more detail after you create the synchronization link, and adjust them if
necessary, in the Rules tab, as described in "Edit synchronization rules" on page 375.
Optional: Select favorites (requirement and defect links)

You can limit the synchronization to a subset of your ALM, JIRA. or ALM Octane database by
using ALM Octane and ALM or JIRA favorites.
Tip: For requirement links, you can also use an alternate root folder for a similar purpose.
If you define both favorites and an alternate root folder, the alternate root folder is
considered first.
Select favorites to use as filters for new items when synchronizing between endpoints. For details,
see "Step 2: Define the synchronization scope" on page 361.
No favorites are defined by default. This means that all records in the ALM Octane workspace and
the ALM or JIRA project are synchronized.
Optional (ALM only): Define an alternate root folder (requirement and release

links)
You can limit the synchronization to a subset of your ALM database by selecting an alternate
ALM root folder.
Select Use an alternate root folder and enter the path to a sub-folder in your ALM project's
Requirements or Releases folder.
The path must replicate the exact hierarchy in ALM starting with the Requirements or Releases
folder, according to the ALM locale. For example: Requirements\MyProject.
Note: For a requirement link, if you define both favorites and an alternate root folder, the
alternate root folder is considered first.
Caution:
l Make sure the folder that you enter already exists in your ALM folder structure.
l Specifying an alternate root folder for synchronization can cause unexpected behavior.
If you reorganize the Requirements or Releases module in ALM after having run a
synchronization task, carefully move the records while retaining the same hierarchy to
retain the synchronization. Do not delete records and create new ones in the new
location, as ALM Octane Synchronizer recognizes records according to their ALM ID.
When you move records, make sure to retain the same hierarchy as is defined for the
link in ALM Octane Synchronizer.

Synchronization
l If you move a record out of the alternate root folder in ALM, this record is no longer
synchronized with ALM Octane.
However, if you move a release out of the alternate root folder, the release is no longer
synchronized, but its cycles are still synchronized.
l You can change the path to the alternate root folder until you run the first successful
synchronization for the link.
Optional: Specify how to handle requirements whose hierarchy does not

match the backlog tree (requirement links)
Your ALM or JIRA requirement synchronization hierarchy might not fully match the ALM Octane
epic > feature > user story hierarchy.
For example, if a requirement of a type mapped to user stories is a child of a requirement whose
type is mapped to epics. A requirement of a type mapped to features may be a child of a
requirement not mapped for synchronization at all.
For requirement types mapped to epics or user stories, you can instruct Synchronizer to ignore a
requirement's hierarchy when it does not match. Such requirements are then synchronized
directly to the root of the ALM Octane backlog tree: Select Synchronize epics and user stories to
the Backlog root.
Tip: We recommend that you select this option.
This option is not relevant for features. Features whose parents are not epics will still fail to
synchronize.
Specify how to handle existing or past releases (release links)

l Select Synchronize past releases... if you want to synchronize releases whose end date is in the
past. By default, ALM Octane Synchronizer synchronizes only current releases.
If you select this option, enter a date to prevent synchronizing old releases that you do not
need. This date cannot be in the future.
l Select Map pairs of new releases and sprints/cycles with identical names if you want to use
data from the dominant endpoint for all fields of the identically named release or sprint/cycle in
the other endpoint.
In ALM synchronization, if you do not select this option the pairs of identically named release
or sprints/cycles are not synchronized at all. A "duplicate entities" error is generated in the run
report.
Note: When mapping, ALM Octane Synchronizer checks only the releases that are

Synchronization
included in the synchronized time frame. Releases or sprints/cycles with identical names
are not mapped if they are in a past release (or a release whose end date is older than
the one you specified for synchronization).
If you are working in a shared space (see "Manage spaces" on page 514), when you
update a shared release in a remote endpoint this is not synchronized to ALM Octane.
Releases created in a remote endpoint are not shared in ALM Octane.
Next Steps
Click Next to complete the wizard, and then Finish to create the link. The new link appears in the
navigation tree on the left of the Link Configuration page.
When you are finished creating your link, do the following:
l "Step 4: View and edit link configuration" below
l "Step 5: Configure synchronizer notifications" on page 390
l "Step 6: Run synchronizations" on page 391
l "Step 7: Review link summaries and error details" on page 395
l "View the run history for a specific link" on page 396
Caution: If you create a link and then delete it, and you then create it again using the same
conditions, any defects or requirements that were already synched will be duplicated (in
either direction of synchronization).
See also:
l "Link status reference" on page 397
l "How can I improve synchronization performance?" on page 401
Step 4: View and edit link configuration

After you create a synchronization link, the new link appears in the navigation tree on the left of
the Link Configuration page.
To open the Link Configuration page: From the ALM Octane settings area, select Synchronizer. If
the Synchronizer opens to the Dashboard and you see the Links summary, click to open
the Link Configuration page.

Synchronization
For requirement links, the tree includes one node for the general link settings, and additional sub
nodes for each mapped requirement type. Select each of these nodes and view its detailed
settings.
Tip: Use the search box above the tree to filter by link name. The search box is disabled
while you are in edit mode.
Page through the link tabs to view and update current settings. Click Save Link to save your
changes, Cancel Edit to discard changes and leave edit mode, or Edit Link to return to edit mode.
For details, see:
l "Edit general link settings" below
l "Edit requirement type mapping (ALM synchronization only)" on page 374
l "Edit synchronization rules" on page 375
l "Edit field mapping" on page 376
l "Map user list fields" on page 387
Next steps:
l "Step 5: Configure synchronizer notifications" on page 390
l "Step 6: Run synchronizations" on page 391
l "Step 7: Review link summaries and error details" on page 395
l "View the run history for a specific link" on page 396
Edit general link settings

On the link configuration page, expand the nodes in the navigation tree and select the link you
want to edit. In the General tab, modify settings and view general details about the link.
Click Edit Link to modify settings, and Save Link to save your changes.
Note: You must always run an integrity check after modifying a link's configuration. We
also recommend running a simulation to prevent errors occurring in the actual
synchronization.
For details, see "Step 6: Run synchronizations" on page 391.
Modify settings and view link statuses as follows:

l "View or edit basic link details" on the next page
l "View link status" on the next page
l "Check connectivity to ALM or JIRA" on page 373

Synchronization
l "View or modify synchronization favorites (defect and requirement links)" on the next page
l "For ALM synchronization only: View or modify the alternate root folder" on the next page
l "View the setting for handling requirement hierarchy mismatch (requirement links)" on
page 374
View or edit basic link details
Entity Type Defines the type of entity being synchronized (defect, requirement, or
release).
Read-only.
Link Name The name of the link. Used, for example, in the navigation tree on the left.
Description A free-text description field for the link.
Synchronization Defines whether automatic synchronizations are running for this link.
mode Change this mode by right-clicking the link name in the tree on the left, and
selecting one of the following:
l Start Automatic Mode
l Stop Automatic Mode
Note: You cannot start automatic mode until you have run a
successful integrity check, and saved your changes.
View link status

The link status is indicated by an icon in the navigation tree. Additionally, see the following details
on the General tab:
Last Provides details about the most recent synchronization run, including the date, as
Sync. well as if the run finished with errors or passed.
Click View report to view a summary of events that occurred during the run.

Synchronization
Link Displays the link's current status, as well as a summary of any issues remaining from
Status previous runs.
Link statuses reflect whether integrity checks have passed or not, and whether recent
synchronizations have generated errors or warnings.
l Hover over the Link Status details for information about the last integrity check
and synchronization. From the tooltip, click View report for details about each
item.
l Click View in Dashboard for more details about issues remaining from previous
runs.
For details and action items required for each status, see "Link status reference" on
page 397.
Check connectivity to ALM or JIRA

View the connection details for the configured endpoint. Click Check Connectivity to validate
these details.
View or modify synchronization favorites (defect and requirement links)

View the favorites defined to limit your synchronization link to a subset of your ALM, JIRA, or
ALM Octane database.
You can switch favorites as needed. However, once a record in one endpoint is mapped to a
record in the other endpoint, these records continue to be synchronized even if they no longer
match the link's favorite.
Note: If you want to add, change, or delete favorites from the list of available favorites, do
so in the Backlog or Defects module.
If you modify favorites after having run a successful synchronization, you will need to schedule a
full synchronization for the next run. For details, see "Full synchronizations" on page 394.
For more details, see "Step 2: Define the synchronization scope" on page 361.
For ALM synchronization only: View or modify the alternate root folder

For release requirement synchronization links, view the alternate root folder selected to limit the
synchronization to a subset of ALM's releases or requirements.
You can change the path to the alternate root folder until you run the first successful
synchronization for the link.
For more details, see "Optional (ALM only): Define an alternate root folder (requirement and
release links)" on page 368.

Synchronization
View the setting for handling requirement hierarchy mismatch (requirement links)
For requirement synchronization links, view the option selected for situations when an ALM or
JIRA requirement's hierarchy does not match the ALM Octane backlog tree.
You can modify this option until you run the first successful synchronization for the link.
For details, see "Optional: Specify how to handle requirements whose hierarchy does not match
the backlog tree (requirement links)" on page 369
See also:
l "Edit requirement type mapping (ALM synchronization only)" below
l "Edit synchronization rules" on the next page
l "Edit field mapping" on page 376
Edit requirement type mapping (ALM synchronization only)

When you create a link, you can map one or more ALM requirement types to each of the ALM
Octane types: user story, feature. You can map one ALM requirement type to ALM Octane epics.
On the link configuration page, expand the nodes in the navigation tree and select the
requirement link you want to edit.
Click Edit Link to enable changes, and Save Link to save your changes.
Requirement link nodes contain sub nodes for each mapped ALM requirement type. Each sub
node displays the names of the mapped ALM Octane - ALM requirement types. If multiple
requirement types are mapped to features or user stories, one type is used as the default. (Expand
the pane to view the full names.)
l The hierarchy of the mapped types in the ALM requirement tree must match the Epic
> Feature > User Story hierarchy in ALM Octane. For details, see "In ALM, prepare requirement
types to match ALM Octane's (requirement synchronization)" on page 350.
For requirement types mapped to epics or user stories, you can instruct Synchronizer to ignore
a requirement's hierarchy when it does not match. Such requirements are then synchronized
directly to the root of the ALM Octane backlog tree: Select Synchronize epics and user stories
to the Backlog root. This option is located in the requirement link's General tab.
l You must always run an integrity check after modifying a link's configuration. We also
recommend running a simulation to prevent errors occurring in the actual synchronization. For
details, see "Step 6: Run synchronizations" on page 391.

Synchronization
What do you want to do?
Remove a Right-click the sub node for the requirement type and select Remove
mapped Requirement Type.
requirement type
Available only before you run the first successful synchronization for the
link.
Map an Right-click the node for the requirement link and select Add Requirement
additional Type.
requirement type
You can map additional requirement types to user stories and features.
You can map a requirement type to epics, if they are not already mapped.
See also:
l "Edit general link settings" on page 371
l "Edit synchronization rules" below
l "Edit field mapping" on the next page
Edit synchronization rules

Synchronization rules describe how the synchronization process handles creation, modification,
and deletion of entities in each endpoint.
View the current settings on the link configuration Rules tab, and modify as needed.
For requirement links, select the sub node for each requirement type in the tree to view its rules.
Read each option carefully before selecting.
l In the ALM Octane column, select the action that you want to occur in ALM or JIRA for
changes made in ALM Octane.
In the ALM/JIRA column, select the action that you want to occur in ALM Octane for changes
made in ALM or JIRA.
The direction arrows between the two columns change to reflect your selections. Selecting
specific rules affect your ability to select other rules.
For example, if you select When a record is created in ALM Octane > Create a corresponding
record in ALM/QC, the same rule is automatically selected for updated records below, and you
cannot change this selection.
l For a requirement link:

Synchronization
l Specify which endpoint serves as the dominant side for synchronizing the requirement
hierarchy.
l There are separate defaults for epics, features (for ALM), and user stories.
l For a release link:

l Specify which endpoints serves as the dominant side for synchronizing sprints and cycles, in
case of conflicts.
l Specify how to handle existing or past releases. For details, see "Specify how to handle
existing or past releases (release links)" on page 369.
Caution: Modifying rules may also affect your field mapping. After making changes on this
tab, be sure to verify the mappings defined on the Field Mapping tab. For details, see "Edit
field mapping" below.
Additionally, if you modify rules after having run a successful synchronization, you will
need to schedule a full synchronization for the next run. For details, see "Full
synchronizations" on page 394.
synchronization. For details, see "Step 6: Run synchronizations" on page 391.
See also:
l "Edit field mapping" below
Edit field mapping

ALM Octane and ALM or JIRA fields are mapped to specify pairs of fields with synchronized data.
Field mapping includes specific field value mapping (for list fields), as well as the direction in which
the data is synchronized.
For details about mapping user list field values, see "Map user list fields" on page 387.
synchronization.

Synchronization
For details, see "Step 6: Run synchronizations" on page 391.
In this topic:
l "Field mapping overview" below
l "Notes about Type, Attributes, and Required in the Field Mapping tab" below
l "Map a pair of fields or define constant values" below
l "Additional field mapping tasks" on page 379
Field mapping overview

When you first create a link, some system fields and field values are mapped automatically, as long
as the field or field values have not been modified. To view an example, see "Examples of
automatically mapped fields: ALM or JIRA defects" on page 384.
On the link configuration Field Mapping tab, view the automatic mapping and modify it if
necessary, and map user defined and other optional fields. Mandatory fields must be mapped to
synchronize records correctly.
For requirement links, select the sub node for each requirement type in the tree to view its field
mapping.
Tip: Before you start synchronizing, it is highly recommended that you read "Field
mapping guidelines" on page 381. For additional recommendations before synchronizing,
see "Prepare for ALM synchronization" on page 348.
Notes about Type, Attributes, and Required in the Field Mapping tab
The Type and Attributes columns are populated automatically. The red asterisk indicating a field
is Required is set by the system as well.
Type. If the type is Reference, that means this field links the entity to an item created in ALM
Octane. For example, a release, a sprint, a user, or another backlog item. The possible values for
this field depend on the items defined in the system.
Attributes. Some fields, such as IDs, are marked in the Attributes columns as R (Read only). This
means the field values are set by the system and cannot be entered by the user, or set via
synchronization. For example, the ALM Octane Defect ID is a read only field. You cannot map it to
synchronize bidirectionally. However, you can map it for unidirectional synchronization, setting a
custom ALM Octane ID field in the ALM or JIRA endpoint.
Required. You cannot manually set a field as required for synchronization.
Map a pair of fields or define constant values

On the link configuration Field Mapping tab, view the existing mapping and modify it if necessary.

Synchronization
1. Above the mapping grid, toggle between showing ALM Octane Fields and ALM/JIRA Fields
to determine how the fields are listed in the grid.
2. Select the row for the field you want to map, and define the following:
a. In the Direction column , select whether you want to map the field from ALM Octane to
ALM or JIRA, vice versa, or as bidirectional.
If the field has no corresponding field in the other endpoint, select Constant.
b. In the mapped field column (ALM Octane Field or ALM/JIRA Field, depending on how
you are viewing the fields) select a field from the dropdown list. Use the search box to
filter the fields displayed.
If you are mapping a constant value, enter the value in the corresponding column cell.
The constant value is assigned to the field when ALM Octane Synchronizer creates new
entities, and is not updated in subsequent synchronizations.
Example: If you created a Creation Method user-defined field in ALM to

distinguish between entities created directly in ALM and those synchronized from
ALM Octane, enter created by ALM Octane Synchronizer as the mapped
constant value. For details, see "Prepare for ALM synchronization" on page 348.
If you need to map multiple fields in the opposite endpoint, click in the Multi-Mapping
column. When you do this, your direction options are limited to prevent conflicts.
Field Mapping tab grid actions

The Field Mapping grid supports the following actions:
Action Description
Select
Use the column selector above the grid to select the columns
columns
to view displayed.
Refresh
Above the grid, click to refresh the grid after making changes to the list of
grid
fields in either endpoint. For example, refresh the grid after adding new
values to a list field.
Sort or Hover over a column heading and click the arrow to sort or group the grid
group by by the selected column. This menu also lets you hide this column from the
column grid.

Synchronization
Action Description
Show The grid footer lets you filter the grid by fields that are mapped or unmapped,
only or are causing errors or warnings in integrity checks. You can also select to
specific show all fields.
fields At the bottom of the grid, select:
l Mapped to view only mapped fields
l Unmapped to view only unmapped fields
l Errors to view only fields with mappings that will cause errors, and will also
prevent synchronizations from running
l Warnings to view only fields with mappings that may cause errors but will
not prevent synchronization from running
l Total Items to view all fields, regardless of mapping status
Additional field mapping tasks

l "Define a dominant endpoint" below
l "Map specific field values" below
l "View other field properties" on the next page
l "Remove a field mapping" on the next page
Define a dominant endpoint

Define a Dominant Endpoint to determine the source of the synchronized value in case of
conflicts.
1. On the Field Mapping tab, select a pair of mapped fields to view additional properties on the
right.
2. On the right, expand the Mapping Properties section.
3. Select the endpoint you want to define as the dominant endpoint.
Map specific field values

Mapping specific field values is relevant only for mapped list fields. Select and map values and
mapping directions for each field in the endpoints.
Caution: If you have different numbers of values in the field for each endpoint (such as 5
values in ALM Octane and 6 values in ALM), bidirectional value mapping may result in
some data loss when records are synchronized back and forth. For details and
recommendations, see "Guidelines for mapping specific field values" on page 381.

Synchronization
right.
2. On the right, expand the Values section.
3. Map specific values in the each field to corresponding values in the opposite field, as well as
their directions. If relevant, you can map one of the values to an empty string.
4. Define a Default value to use when the field value is empty in the source endpoint, but
mandatory in the destination endpoint.
Default values replace the empty values, and help to avoid synchronization errors. Leave this
field empty if you do not want to use a default value.
Note: ALM Octane Synchronizer uses the default value only when creating a new
entity, not when updating.
The Default value field is displayed only:

l in the field mapping properties for the endpoint where the field is mandatory.
l if the field is mandatory in the destination endpoint.
Possible warnings on this field:

If the Default value field is highlighted in red, run an integrity check and review the warnings
it provides. As long as the integrity check does not contain errors, you may be able to ignore
some of these warnings. They warn of potential issues that could arise during
synchronization.
For example:
l The length of the field in ALM Octane is shorter than the length of the mapped JIRA field.
l In ALM Octane, the list has fixed set of possible values, but in ALM the list is not set to
verify values, and will accept any value.

"Example of mapping field values: ALM Octane Phase and ALM or JIRA Status" on page 386
View other field properties

right.
2. Expand the Field Properties section to view the available properties, such as the field schema
names in either endpoint, or whether the field is read-only.
The displayed properties differ, depending on the type of field you select.
Remove a field mapping

To unmap a pair of ALM or JIRA and ALM Octane fields, when there are multiple fields mapped in
one endpoint to a single field in the opposite endpoint, click in the Multi-Mapping column.

Synchronization
To remove a single field mapping (a pair of ALM or JIRA and ALM Octane fields that have one
field in each endpoint), click in the mapped field.
See also:
l "Edit synchronization rules" on page 375
Field mapping guidelines

Once a record in one endpoint is mapped to a record in the other endpoint, it is always
synchronized if there is new data, regardless of whether the record still matches the link's filter.
Therefore, before you start synchronizing, it is highly recommended that you read the following
guidelines for specific types of synchronizations.
For further recommendations before synchronizing, see "Prepare for ALM synchronization" on
page 348 and "Prepare for JIRA synchronization" on page 355.
Guidelines for mapping specific field values

Mapping field values when the number of values differ in each endpoint
If you have a different number of values for the field in each endpoint, make sure each value is
mapped to a value in the other endpoint.
"Example of mapping field values: ALM Octane Phase and ALM or JIRA Status" on page 386.
New field values created during synchronization (Synchronize back on create)
ALM Octane Synchronizer sends any new field values created in a destination endpoint (during
synchronization) back to the source endpoint, if they are mapped.
Guidelines for mapping attachments

When synchronizing files attached to records, ALM Octane Synchronizer generates a URL for the
file, and passes that URL to the destination record. Users in the destination endpoint access the
file via the URL, which essentially remains in the source endpoint.
If a URL attachment is added to the record in the source endpoint, ALM Octane Synchronizer
simply passes the attached URL to the destination.
For this reason, if you map attachment fields, users must have appropriate permissions in both
endpoints to open the synchronized attachment. For example, if a file was originally attached to a
record in ALM or JIRA, ALM Octane users must have access to the project to open the
attachment.

Synchronization
Attachment Attachments to the same record must have unique names. Attaching a file or
file names URL to a record in opposite endpoints, with the same file name, will cause
errors.
File Supported file encoding when synchronizing attachments: UTF-8, UTF-16LE,

encoding or UTF-16BE
Attachment ALM Octane Synchronizer updates an attachment only if both of the following

updates have changed:
l The record to which the file is attached
l The attachment name, size, or last modified property
The attachment description is synchronized only during the initial attachment

synchronization, and is never updated.
Deleted l If an attachment is deleted from the record in the source endpoint,

attachments Synchronizer also deletes it from the corresponding record in the
destination endpoint.
l If an attachment is deleted from a destination endpoint, and changes are
simultaneously made to the attachment in the source endpoint, the
attachment is recreated in the destination endpoint. Otherwise, the
attachment remains in the source endpoint only.
Note: ALM System Info attachments (.tsi files) are opened from ALM in a built-in ALM
viewer. They are opened from ALM Octane as XML files.
Guidelines for mapping fields with string, float, and numeric values
If... Then...
If you map a string field that has a The string value will be truncated as necessary in
maximum length in the destination the source endpoint during synchronization.
endpoint, and a synchronized value
exceeds this maximum
If you map a string field in the source For the synchronization to succeed, the string field
endpoint with a numeric field in the value must be an integer.
destination endpoint

Synchronization
If... Then...
If you map a numeric or date field in the For the synchronization to succeed, the numeric or
source endpoint with a list field in the date field value must be one of the values in the
destination endpoint list.
Note: In ALM, a list field can be defined not

to verify values. In this case, a numeric or
date field mapped to the list can contain
values that are not in the list.
If you map a date field with a string field Synchronizer recognizes date strings of the
following formats:
l yyyy-MM-dd (for example: 2015-11-20)
l dd-MMM-yy (for example: 25-Dec-16
l M/d/yyyy
l M/d/yy
l MM/dd/yy
l MM/dd/yyyy
Note: Synchronization of multi-value user-defined fields is not supported.
Guidelines for mapping links between entities
Note: It is important to distinguish between Synchronizer endpoint links (such as those

between ALM and ALM Octane) and entity links between entities, such as defects and
requirements.
Links between entities are not synchronized.
Guidelines for mapping Release and Cycle fields in defect and requirement links
If you map ALM Target Cycle or Detected in Cycle fields, you must also map the corresponding
release fields.
Additionally:
l Release and cycle or sprint names must be identical in both endpoints. These names are case-
sensitive.
l Release names must be unique in both endpoints.

Synchronization
l Requirements must have a single target release in ALM. Synchronizing requirements from ALM
with multiple target releases will fail.
Tip: If you cannot modify these release names but you want to map these fields:
Map specific field values to define the full path of the release. For example, you can map
each value of the Target Release field to a value in a corresponding field in the other
endpoint.
Define the full path of the ALM release in the format \<Release_Folder_Name>\<Release_
Name>. For example, \Flight Application\Release_2.
You do not need to include the root Releases folder in the path.
For details about mapping specific field values, see "View other field properties" on
page 380.
Examples of automatically mapped fields: ALM or JIRA defects

The following table lists some of the fields that are automatically mapped for new defect
synchronization links. You can modify the mapping, but keep in mind that mandatory fields must
be mapped to prevent errors.
Note: Fields that have been customized with modified list values in either endpoint are not
automatically mapped.
ALM automatic mapping

ALM Octane field Direction ALM field
Attachments Bidirectional Attachments
Author Unidirectional Detected By
Closed on Bidirectional Closing Date
Comments Bidirectional Comments
Creation Time Bidirectional Detected on Date
Description Bidirectional Description
Detected By Bidirectional Detected By

Synchronization
ALM Octane field Direction ALM field

Detected in Release Bidirectional Detected in Release
Name (mandatory) Bidirectional Summary
Owner Bidirectional Assigned To
Phase (mandatory) Bidirectional Status
Priority Bidirectional Priority
Release Bidirectional Target Release
Severity Bidirectional Severity
Sprint Bidirectional Target Cycle
Story Points Bidirectional Estimated Fix Time
JIRA automatic mapping

ALM Octane field Direction JIRA field
Attachments Bidirectional Attachments
Author Unidirectional Reporter
Closed on Unidirectional Resolved
Comments Bidirectional Comment
Creation Time Unidirectional Created
Description Bidirectional Description
Detected By Bidirectional Reporter
Detected in Release Bidirectional Affects Version/s
Name (mandatory) Bidirectional Summary
Owner Bidirectional Assignee
Phase (mandatory) Bidirectional Status
Release Bidirectional Fix Version/s
Priority Bidirectional Priority

Synchronization
Example of mapping field values: ALM Octane Phase and ALM or JIRA Status
ALM Octane Synchronizer lets you map specific field values in one endpoint to specific values for
the corresponding field in the other endpoint. A good example of when you might need to do this
is when mapping defect phases.
ALM Octane and ALM or JIRA have different defect phase or status options.
l The ALM Octane Phase field has the following values: New, Opened, Fixed, Proposed Closed,
Closed, Deferred, Duplicate, Rejected
l By default, the ALM Status field has the following values for defects: New, Open, Fixed, Reopen,
Closed, Rejected.
l By default, the JIRA Status field has the following values for defects: To Do, In Progress, Done,
Closed.
Because these are standard fields, ALM Octane Synchronizer provides a default mapping for
these values, shown in the table below.
You can modify the mapping as needed for your link.
ALM Status values

Values
ALM Octane Direction ALM
New Bidirectional New
Opened Unidirectional Reopen
Fixed Bidirectional Fixed
Closed Bidirectional Closed
Proposed Closed Unidirectional Rejected
Deferred Unidirectional New
Duplicate Unidirectional Rejected
Rejected Bidirectional Rejected
JIRA Status values

Values

Synchronization
ALM Octane Direction JIRA
New Bidirectional To Do
Opened Bidirectional In Progress
Fixed Unidirectional Done
Closed Bidirectional Closed
Proposed Closed Unidirectional Closed
Deferred Unidirectional To Do
Duplicate Unidirectional Closed
Rejected Unidirectional Closed
Map user list fields

ALM Octane and ALM or JIRA maintain separate lists of user list fields, such as for the Owner
field.
Users in these lists are mapped once for each pair of endpoints. This means that if you mapped
the users between an ALM Octane workspace and an ALM or JIRA project when creating a
requirement link, the same mapping is used when you create a defect link between the same two
endpoints.
The following chart describes how ALM Octane Synchronizer recognizes mapped users, using
manual or automatic mapping methods.

Synchronization
Automatic user mapping

ALM or JIRA users defined with an email address that is identical to the one used to log in to
ALM Octane are automatically mapped for all user list fields.
If a user has multiple email addresses defined in ALM or JIRA, only the first email address is
synchronized with ALM Octane.
When the ALM Octane user list does not contain a user that matches the ALM or JIRA user, then:
1. If you defined a Default user for the ALM Octane endpoint, this user is mapped to the ALM
or JIRA user. For details, see "Define default users for when there is no matching user in the
destination endpoint." on the next page
2. If no default is defined, synchronization fails. You can manually map this ALM or JIRA user to
an existing ALM Octane user, or create a new user (either active or inactive) with the email
address defined in ALM or JIRA. For details on adding or activating users in ALM Octane, see
"Assign roles and permissions" on page 529.
When you are done, re-run synchronization.
Manual user mapping

Map ALM or JIRA and ALM Octane users manually if the email addresses are not identical, or if
the ALM or JIRA user is not defined with an email address.

Synchronization
1. Access the User Mapping dialog box.

On the link configuration page, select a link to edit its user mapping. .
From the Select More Actions > Edit User Mapping.
More Actions
menu
From a user On the Field Mapping tab, select a user list field, such as Assigned To.
list field The selected field must be mapped to a user list field in the other
endpoint.
On the right, expand the User Mapping node, and click edit.
The User Mapping dialog box displays only users mapped manually. Users mapped
automatically are not listed.
Tip:
l Periodically, use the Refresh button at the top of this dialog box to make sure you
are working with the most up-to-date ALM Octane and ALM or JIRA user lists.
2. Define default users for when there is no matching user in the destination
endpoint.
This may happen, for example, if a user once existed in an endpoint's user list, and is
therefore listed as a user list value, but has since been deleted from the other endpoint's user
list.
Expand the Default user area, and define default users for destination endpoints in both
ALM Octane and ALM or JIRA.
Caution: If you map a user field bidirectionally, the default value will overwrite the
value that no longer exists in the user list.
For example:
peter@domain.com is listed as the owner of a defect in ALM Octane, but does not
appear in the user list in ALM.
When synchronizing the defect, peter@domain.com from ALM Octane is mapped to

default@alm.com in ALM.
After bidirectional synchronization, the defect in ALM Octane lists defualt@alm.com

as the defect owner.

Synchronization
See step #4 below for another solution for this situation.
3. Map users manually

Select corresponding users from the dropdown menus for each endpoint, set the direction,
and then click Add Mapping.
Tip:
l Select Show unmapped only to display only users who are not yet mapped in the
dropdown lists.
4. Map an ALM Octane user to a user that is not included in the ALM or JIRA user
list
a. In the Manual Mapping area, select an ALM Octane user name.
b. In the ALM/JIRA Users box, type a name of a user that does not exist in the ALM or JIRA
user list, and select the map to non-existing user entry.
During synchronization, the user name that you mapped is entered in the relevant user fields,
without adding it to the ALM or JIRA user list.
Caution: In ALM, user fields can be set to Verify value. This means that in this field,
ALM only allows users who exist in the user list. If you bidirectionally synchronize
such user fields, using a non-existent ALM user could fail the synchronization.
Step 5: Configure synchronizer notifications

ALM Octane Synchronizer sends cumulative notifications for issues that occur during
synchronizations, as well as digests summarizing all links in a specific workspace.
When a new version of the Integration Bridge is available, the bridge is automatically updated to
the new version. A notification is sent at the beginning and end of this process.
Link notifications
Link notifications are configured for all links in a workspace. On the Link Configuration page,
click the workspace's name in the navigation tree, and then click the Notifications tab.
Issue notifications
Configure cumulative notifications sent for issues occurring during synchronizations. You can
configure notifications for only new issues, or both new and known, still unfixed issues.

Synchronization
l Select how often you want the system to send notifications, summarizing:
l New issues that have occurred since the last notification.
l Known issues that have been reported in previous notifications, and are still unfixed.
l Determine who receives issue notifications. Click the Select from workspace users drop-down,
and select one or more recipients.
Note: To send notifications for known issues, you must also configure notifications for
new issues.
Link summary digests

Configure how often you want to receive digests, summarizing the status of all links in the current
workspace.
Link summary digests are only sent to Synchronizer Admins. If you want additional users to
receive digest notifications, assign them to the Synchronizer Admin role for the specific
workspace.
Bridge upgrade notifications

Upgrade notifications are configured for each bridge, and sent only to selected Synchronizer
Admins. On the Link Configuration page, click the bridge's name in the navigation tree, and
then click the Notifications tab.
Determine who receives upgrade notifications. Click the Select from Synchronizer Admins drop-
down, and select one or more recipients.
Note: You can select or deselect only Synchronizer Admins that belong to the same
workspace as you.
See also:
l "Step 6: Run synchronizations" below
Step 6: Run synchronizations

After your link is created and configured, run an integrity check to verify that records will be
synchronized correctly. If the integrity check passes, run a simulation to verify how much data will
change. Then run manual tasks, or start automatic synchronizations.

Synchronization
Caution: Once records have been synchronized, they cannot be removed from the
synchronization. When first setting up a link's configuration, use a favorite defined with
one record only. Widen the favorite slowly, ensuring that the synchronizations run as you
expect.
However, if you use an alternate root folder to limit the synchronized requirements or
releases:
l Requirements removed from the alternate root folder in ALM will no longer be
synchronized.
l Releases removed from the alternate root folder in ALM will no longer be synchronized,
but their cycles will still be synchronized.
Note that if you make certain changes to a link's configuration after having already synchronized,
such as updated rules or field mapping, you'll need to run a full synchronization to ensure that all
records are aligned with those changes. ALM Octane will notify you when a full synchronization is
required. If you delete a workspace, its links are automatically deleted.
Integrity checks
You must run an integrity check before running a synchronization task to verify that the task will
run smoothly. Use the integrity check to debug any errors before synchronizing the records.
The integrity check makes sure that your synchronization link is configured correctly. For
example, it makes sure that you mapped all mandatory fields.
To run an integrity check:

1. Right-click the link in the navigation tree on the left and select Run Integrity Check, or while
viewing the link details, select Run > Run Integrity Check from the toolbar.
The integrity check status is displayed at the bottom of the screen.
2. Click the expand arrow at the top of the status to display all log messages. From there, click
View Report or View Log for more details.
l If your integrity check passes, you can run a simulation to verify how many records will be
added or updated in the next synchronization, or you can start synchronizing, by running
a manual task or starting automatic synchronizations.
l If your integrity check fails with errors, fix the errors in your link configuration and try
again.
l If the integrity check returns warnings, you can run the synchronization, but some items
may fail to synchronize depending on field values in the source endpoint.

Synchronization
Based on your knowledge of the synchronized endpoints, you may decide to ignore
specific warnings and run the synchronization.
Simulation runs
Run a simulation after your integrity check passes, and before you synchronize your data. The
simulation checks the records in the folders and favorites you specified for synchronization and
reflects the number of items that will be added or updated in the next synchronization.
Note: For various reasons, the simulation results may include more items than the actual
synchronization run. For example, the simulation run may include items that encounter
errors and fail to update, or items whose changes were in fields that are not mapped for
synchronization.
To start a simulation run:

1. Right-click the link in the navigation tree on the left and select Run Simulation, or while
viewing the link details, select Run > Run Simulation from the toolbar.
The run status is displayed at the bottom of the screen.
The following data is included in the simulation report:
l The number of items to be created, or re-created, in each endpoint
l The number of items to be updated in each endpoint
l The number of items to be deleted in each endpoint
l Connection data for each endpoint
Manual synchronizations
Run tasks manually when you want to test a link, such as when configuring or debugging the link
settings. If there were errors in the last synchronization run, a manual synchronization will
automatically re-synchronize those records.
1. If you are currently in Automatic Mode, stop automatic synchronizations. For details, see
"Stop automatic synchronizations" on the next page.
2. Right-click the link in the navigation tree on the left and select Run Manual Sync., or while
viewing the link details, select Run > Run Manual Sync. from the toolbar.
The run status is displayed at the bottom of the screen.

Synchronization
Automatic synchronizations
Automatic synchronizations are scheduled to run regularly, around the clock. Defect and
requirement links synchronize every minute, and release links synchronize every 5 minutes.
Note: If a single run task takes longer than 1 minute, the automatic runs are performed
farther apart as needed.
Start automatic Right-click the link in the navigation tree on the left and select Start
synchronizations Automatic Mode, or while viewing the link details, select Run > Start
Automatic Mode from the toolbar.
l The current run status is displayed at the bottom of the screen.
l Click the expand arrow at the top of the status to display all log
messages. From there, click View Report or View Log for more
details.
Stop automatic Right-click the link in the navigation tree on the left and select Stop
synchronizations Automatic Mode, or while viewing the link details, select Run > Stop
Automatic Mode from the toolbar.
If you stop automatic synchronizations, you will need to run a
manual synchronization task or start automatic synchronizations
again to update your records.
Full synchronizations
Certain types of changes detected in your link, such as updated favorites, rules, or field mapping,
require you to synchronize all records in your link. ALM Octane will notify you when a full
synchronization is required.
Synchronizing all records ensures that all records are aligned with the changes in the link
configuration or fields.
Note: Performing a full synchronization may take some time. We recommend doing this
when the system is not otherwise busy.
To run a full synchronization, in the navigation tree, right-click the link name, or select the link.
Then, select More Actions > Schedule Full Sync. in Next Run.
The next synchronization that starts will synchronize all records in the link.
Re-synchronizing records with fixed errors (automatic mode only)

If your link is in automatic mode, and a synchronization ran with errors, the records with errors are

Synchronization
not necessarily fixed in subsequent runs.

This may happen if the errors occurred because of changes outside of the link configuration, such
as if the schema changed, but the field mapping was not updated. If you fix the cause of the error
(such as refreshing the Field Mapping tab and map the new fields), ALM Octane Synchronizer will
re-synchronize those records if changes in the actual record are detected.
ALM Octane Synchronizer also periodically re-synchronizes all records, including those that had
run with errors, but have had no subsequent changes.
To ensure that records that ran with errors are re-synchronized in the next upcoming run,
manually set the link to re-synchronize those records.
On the Link Right-click the link name, or select the link and then select More Actions >
Configuration Retry Errors in Next Run.
page
On the In the Link Summary area, expand the workspace and link nodes until you
Dashboard see the specific issues that occurred in recent synchronizations.
Find the link for which you want to retry records with issues, and click Retry
next run next to the link.
The records that ran with errors will be re-synchronized next run.
See also:
l "Step 7: Review link summaries and error details" below
l "ALM Octane Synchronizer FAQs and troubleshooting" on page 399
Step 7: Review link summaries and error details

You can review the state of your links in widgets displayed on both the Link Configuration
and Dashboard pages. Toggle between the two buttons in the upper-right corner to switch
between the pages.
For example, view a Link Summary:

Synchronization
These widgets display the numbers of links for each type. Links with issues are links that
generated errors or warnings during the last integrity check or synchronization.
Additionally, you can view configuration details and statuses for all links in a specific bridge or
workspace by clicking on the relevant node in the tree on the Link Configuration page.
Data is displayed in a grid, with a row for each link in the selected section. In the grid, click the links
in the Last Run and Last Integrity Run columns to access the logs for a specific run.
View data for:
l All links configured for a specific bridge. Click the bridge name in the navigation tree.
l All links configured for a specific workspace, on a specific bridge. Expand the bridge node,
and then click the workspace name.
The Dashboard displays basic synchronization statistics as well as detailed reports for each
synchronization.
To view data for a specific link, or to investigate specific errors, do the following:
l "View the run history for a specific link" below
l "Drill down to specific errors on the Dashboard" below
View the run history for a specific link
1. Click the Link Configuration button in the upper right-hand corner.

2. In the navigation tree, browse to and click the link name. Then, click the Run History tab.
3. Select how far back you want to show the run history.
4. If you want to filter out any runs that finished successfully (without errors), select Show
finished with errors only.
The grid is populated with the relevant data for the selected link.
Drill down to specific errors on the Dashboard

1. Click the Dashboard button in the upper right-hand corner.
2. If issues are listed, expand issue types and click specific issues to drill down for more details.
3. Read the issue description and suggested solution. If necessary, modify your link
configuration and field mapping to fix the errors. Run an integrity check after making any
changes.
By default, records with errors are only periodically synchronized again in the next automatic run
if there are no changes to the record.

Synchronization
To ensure that all records with errors synchronized again in the next run, do one of the following:
l Run a manual synchronization. Manual synchronizations always synchronize all records.
l If your link is in automatic mode, click Retry next run for the relevant link.
All records in the link with issues will be synchronized again in the next successful run,
regardless of whether there are changes.
Note: The Retry next run button is shown only if there has been an unsuccessful run.
You can view details about fixed issues in the Fixed errors area. Expand each workspace node to
view details about individual issues.
See also:
l "Link status reference" below
l "ALM Octane Synchronizer FAQs and troubleshooting" on page 399
Link status reference

Link status is displayed across the ALM Octane Synchronizer interface, such as in the link
summary table, the link's General tab, and as an icon next to the link name in the left-hand
navigation tree.
/ Status: OK
Icons
Automatic / Manual
Description Integrity checks passed without errors.

Link tasks are running as configured, without errors or warnings.
Action required No action required.

Links in automatic mode will run synchronization tasks.
Links in manual mode are ready to run manual synchronization tasks.
Status: Integrity check required
Description The link's filter, rules, or field mapping was modified, and an integrity
check has not been run.

Synchronization
Action required Run an integrity check before running a manual synchronization task,
or before starting automatic synchronizations.
Status: Integrity failed
Description Integrity check failed.
Action required Modify the link and run an integrity check again.
/ Status: Sync. Warning
Icons /
Automatic Manual
Description A recent synchronization task ran with some warnings.

If the link is in automatic mode, synchronizations continue to run. If the
link is in manual mode, you can run a manual task.
Action required
l On the ALM Octane Synchronizer Dashboard page, view issues
for the link and make changes to prevent them from reoccurring.
Changes might be required in the link field mapping, rules or filter.
Changes might also be required outside of ALM Octane
Synchronizer, such as in the ALM or JIRA schema or field values.
If you made changes in the link configuration, run an integrity check
after you save your changes to verify that the warnings are fixed.
l To run the records with warnings in the next synchronization even if
they were not modified, on the Dashboard, click Retry next run.
/ Status: Sync. Error
Icons
Automatic / Manual
Description Errors were found in the most recent synchronization task (automatic
or manual), and synchronization cannot run.
Action required Modify the link to fix the errors, and then run an integrity check.

Synchronization
Status: Integration bridge is offline
Description The integration bridge is offline.
Action required
Open a ticket on ALM Octane (Help > Send Us Feedback > Open
ticket).
Request that ALM Octane Support start the integration bridge and make
sure that the credentials the bridge is using to connect to ALM Octane are
still valid.
Status: Integration bridge is being upgraded automatically
Description The integration bridge is offline because an automatic upgrade is in

progress.
An upgrading icon is displayed next to the bridge name in the left-hand
navigation tree.
Action required No action required.

When the automatic upgrade process is completed, the bridge will be
automatically enabled.
Status: Integration bridge needs upgrade
Description The integration bridge is out of date.
Action required
Open a ticket on ALM Octane (Help > Send Us Feedback > Open
ticket).
Request that ALM Octane Support install the new version of the
Integration Bridge.
ALM Octane Synchronizer FAQs and troubleshooting

See the following common questions about ALM Octane Synchronizer below.
Why does my run history show updated records when I did not update any records,
but only created records?
New field values created in a destination endpoint during synchronization are automatically sent
back the record in the source endpoint.

Synchronization
So, for example, when you create a record in ALM and synchronize it to ALM Octane, that new
record is created in ALM Octane, and assigned an ALM Octane ID.
ALM Octane Synchronizer recognizes this new ID field value, and sends it back to ALM, adding it
to the source record.
This last step is the update you see in your run history.
Automatic synchronizations are scheduled to run once a minute. Why don't I see all
of these synchronization runs in my run history?
The following types of synchronization runs are removed from the run history after subsequent
synchronizations are run:
Run description Details

Runs that: An empty run is only displayed in the run
history when it is the latest run, and was run in
l Do not synchronize any data and ...
the last 10 days.
l Are more than 10 days old.
Runs that: Runs with errors that have not yet been
resolved are displayed in the run history until
l Finished with errors, and ...
the related records are synchronized
l Are more than 10 days old, unless ... successfully.
l The errors have not yet been resolved.
Previous runs that contain errors, which also
appeared in later runs, are deleted when they
are more than 10 days old.
Fatal runs that are more than 10 days old For synchronizations run in the last 10 days,
only the last 20 runs are displayed.
I modified my link to fix errors that occurred in previous synchronizations. Why do I

see these same errors occurring again?
If your link is in automatic mode, and a synchronization ran with errors, the records with errors are
not necessarily fixed in subsequent runs.
This may happen if the errors occurred because of changes outside of the link configuration, such
as if the schema changed, but the field mapping was not updated. If you fix the cause of the error
(such as refreshing the Field Mapping tab and map the new fields), ALM Octane Synchronizer will
re-synchronize those records if changes in the actual record are detected.
ALM Octane Synchronizer also periodically re-synchronizes all records, including those that had
run with errors, but have had no subsequent changes.

Synchronization
To ensure that records that ran with errors are re-synchronized in the next upcoming run,
manually set the link to re-synchronize those records.
For details, see "Re-synchronizing records with fixed errors (automatic mode only)" on page 394.
How can I improve synchronization performance?

To improve synchronization performance between ALM Octane and ALM, add indices to your
ALM project schema as follows, depending on the type of database you use for ALM:
Microsof CREATE INDEX BG_VTS_IDX ON [td].[BUG] (BG_VTS, BG_BUG_ID);

t SQL
CREATE INDEX RQ_VTS_IDX ON [td].[REQ] (RQ_VTS);
CREATE INDEX RT_VTS_IDX ON [td].[REQ_TRACE] (RT_VTS);
CREATE INDEX RT_CREATION_DATE_IDX ON [td].[REQ_TRACE] (RT_CREATION_

DATE);
CREATE INDEX LN_CREATION_DATE_IDX ON [td].[LINK] (LN_CREATION_

DATE);
Oracle CREATE INDEX BG_VTS_IDX ON BUG (BG_VTS, BG_BUG_ID);
CREATE INDEX RQ_VTS_IDX ON REQ (RQ_VTS);
CREATE INDEX RT_VTS_IDX ON REQ_TRACE (RT_VTS);
CREATE INDEX RT_CREATION_DATE_IDX ON REQ_TRACE (RT_CREATION_DATE);
CREATE INDEX LN_CREATION_DATE_IDX ON LINK (LN_CREATION_DATE);
Why is the Search Links box in the link tree disabled?

You cannot search in the link tree when a link is in edit mode. Save any changes or click Cancel
Edit to enable the search box.
Why can't I edit mapped requirement types in my synchronization link?

l After a link is synchronized, you can no longer remove mapped requirement types. You can still
add types that are not yet mapped.
l To edit requirement type mapping you must be in edit mode. For details see "Edit requirement
type mapping (ALM synchronization only)" on page 374.
Synchronization failed due to unmapped users. What should I do?

When synchronization fails because of unmapped users, check if the missing users exist. If they do
not, you can create them in ALM Octane (either as active users, or inactive). When you run
synchronization again, the ALM users that were missing will be mapped to the newly-created
users in ALM Octane. For details on adding or activating users in ALM Octane, see "Assign roles

Synchronization
and permissions" on page 529 and "Assign roles and permissions" on page 529.
During synchronization I received an error: “Some of the mapped fields were deleted
from ALM Octane.”
This error indicates that user defined fields were removed from ALM Octane, which were mapped
in a synchronization link. The list of missing fields is displayed in the UI.
Edit the relevant link within the Synchronizer UI, and click Refresh fields and field values in the
Field mapping tab. All the removed fields will be removed from field mapping. Run an integrity
check to verify that records will be synchronized correctly.
During synchronization I received an error: “Some of the fields used in the filter were
deleted from ALM Octane.”
This error indicates that you removed user defined fields from ALM Octane, which were used in a
Synchronizer filter within a particular synchronization link.
Either edit the existing filter, or create a new filter without the user defined fields that no longer
exist. If you create a new filter, within the Synchronizer UI edit the appropriate link and change
the Synchronizer filter in the General tab. Run an integrity check to verify that records will be
synchronized correctly.
Why are many random errors occurring during synchronization?

If inexplicable errors occur, such as an inability to read run reports, constant synchronization
failures, errors while creating links, verify that you are synchronizing with a supported version of
ALM. For details, see "Supported ALM and JIRA versions" on page 345.
If your version of ALM is supported, there may be too many files concurrently open on the ALM
Octane server.
If this is the case:
l The following error will appear in the ALM Octane log files: java.net.SocketException: Too
many open files
l The maximum number of open files allowed by the operating system is too low, and must be
increased.
Contact customer support (Help > Send Us Feedback > Open ticket).
Why is ALM Octane Synchronizer failing to find a custom field that was OK in the
past?
Check the list of custom fields defined in ALM Octane:
1. In Settings , clickand select a shared space or a workspace.

2. In Entities, click User-defined Fields and select the entity whose fields you want to check.

DevOps integrations
Make sure that the field in question still defined for the workspace you are synchronizing.
Why is the synchronization adding attachments named attachment.url to the ALM

Octane entities?
This may happen if an ALM entity has an attachment whose name contains special characters
(~!@#$%()^&).
Workaround: On ALM Octane, remove the added attachment. On ALM, rename the attachment so
that it does not contain special characters.
Why am I not receiving emails after configuring Issue notifications?

If you configured Issue notifications but you are not receiving emails as expected, define values
for FROM_EMAIL_ADDRESS & MAIL_SERVER_HOST in the sync_sa schema.
DevOps integrations
This section provides instructions for integrating DevOps with ALM Octane.
Topic Description
"Set up CI servers" below How to set up the connection between ALM Octane and a
CI server such as Jenkins or TeamCity.
"Set up your SCM system" How to customize SCM-related functionality.

on page 413
"Create and manage test How to set up rules that automatically assign automated tests to
assignment rules" on application modules and test owners using filter conditions.
page 416
"Manage all build failure How to set up rules that translate messages in a build log to
classification rules" on build failure classifications.
page 419
Set up CI servers
This topic describes how to set up the connection between ALM Octane and a CI server such as
Jenkins or TeamCity. This is the basis for working with pipelines in ALM Octane and for
integrating ALM Octane with UFT.
Caution: The permission mechanism of ALM Octane is not synchronized with the
permission mechanism of the CI server.

DevOps integrations
Therefore, ALM Octane users may have access to information from the CI server that they
would otherwise not be authorized to access. For example, log files, stack traces an so on.
See also:
l "Set up UFT integration" on page
421
In this topic:
l "Prerequisites: Obtain API access and make sure your CI server is supported" below
l "Install the ALM Octane CI plugin on your CI server" below
l "Add CI servers on ALM Octane" on the next page
l "Manage your CI servers" on the next page
Prerequisites: Obtain API access and make sure your CI server is

supported
l Obtain API Access. Ask your space admin for an API access Client ID and Client secret. The
plugin uses these for authentication when communicating with ALM Octane.
The space admin can obtain the Client ID and Client secret in ALM Octane Settings. The access
keys must be assigned the CI/CD Integration role in all relevant workspaces. For details, see "Set
up API access" on page 305.
l Obtain access to a CI server that meets the necessary requirements. For the CI servers that are
supported by the ALM Octane CI plugins, see "CI Servers" on page 60.
For a list of plugins that must be installed on the Jenkins server to enable ALM Octane
integration, as well as plugins that are supported by the ALM Octane integration but not
required, see Application Automation Tools wiki page.
Install the ALM Octane CI plugin on your CI server

Download, install, and configure the plugin that enables ALM Octane integration with your
CI server.
This plugin enables ALM Octane to retrieve and display your CI server's build pipelines,
synchronize test run results with the CI server, and trigger pipeline runs on the CI server.
For other CI servers, build your own plugin in Java using the CI Plugin SDK for ALM Octane
available on GitHub.
For details, see "Install and configure the ALM Octane CI plugin on your CI server" on page 406.

DevOps integrations
Add CI servers on ALM Octane

For ALM Octane to integrate with a CI server, the servers and their URLs must be added in ALM
Octane.

2. Click the DevOps tab. On the left side of the pane, select CI Servers.
3. Click + to add a CI server and enter a name for the server.
4. Select a URL from the list of CI servers.
The list displays all servers that meet the following conditions:
l The server has the ALM Octane CI plugin installed and configured to access your ALM
Octane.
l The API Access keys that the plugin is using are assigned the CI/CD Integration role in the
current workspace.
You can now create pipelines in ALM Octane that reflect the ones running on the CI server.
Manage your CI servers

In the list of CI servers, you can add or remove CI servers, view information about each server, and
suspend or resume the connection between ALM Octane and the CI server.
Open the list of CI servers

This list provides information about the servers' status, type, URL, and more.

2. Click the DevOps tab. On the left side of the pane, select CI Servers.
The list displays all servers that are set up with the ALM Octane CI plugin to access your ALM
Octane.
3. Select the columns that you want displayed. For example, for each server, you can see:
l Whether the server is currently connected.
l The CI server type.

l The version of the plugin installed on the server, or the SDK version used to develop the
plugin.
Keep your plugin up-to-date to benefit from all the latest enhancements and functionality.
l A link to the CI server's URL.

DevOps integrations
Tip: For this link to work properly, your CI server must have its Site URL properly
configured.
Suspend and resume data transfer from Jenkins to ALM Octane

Instruct a selected CI server to stop sending information to ALM Octane. This includes
information such as pipeline runs, test runs, SCM commits, and code coverage data.
A suspension may be useful, for example, in the following situations:
l Your CI server is undergoing maintenance and you don't want experimental data to be sent to
ALM Octane.
l You are investigating unexpected behavior on your CI
server and you want to isolate the
server.
l The network between your CI server and ALM Octane is going to be disconnected for
maintenance and you want to reduce overload on the CI server during that time.
To suspend or resume the connection between your CI server and ALM Octane:
Select a CI server and click the Suspend CI server input to ALM Octane button.
Note: The suspension is immediate, but it may take some time before the button in ALM
Octane reflects the change.
Select a CI server and click the Resume CI server input to ALM Octane button to reconnect the
CI server to ALM Octane.
Next steps:
Install and configure the ALM Octane CI plugin on your CI server

When setting up a CI server for ALM Octane for the first time, install the ALM Octane CI plugin on
your CI server and configure it to connect to ALM Octane.

DevOps integrations
l "Plugin overview" below

l "Install the ALM Octane CI plugin" on the next page
l "Configure the ALM Octane CI plugin to access ALM Octane" on page 409
l "Moving an existing CI server to a new address" on page 412
l "Upgrade from the ALM Octane CI Jenkins plugin to the Application Automation Tools plugin"
on page 412
Plugin overview
This plugin enables ALM Octane to integrate with a CI server, and provide the following abilities:
l Retrieve and display the build pipelines that run on the CI server
l Trigger pipeline runs on the CI server
l Retrieve build run results, test run results, and commit information from the CI server
l Retrieve code coverage reports from a Jenkins CI server
l Trigger UFT test execution on a Jenkins CI server
Prerequisites
l Obtain API Access. Ask your space admin for an API access Client ID and Client secret. The
plugin uses these for authentication when communicating with ALM Octane.
The space admin can obtain the Client ID and Client secret in ALM Octane Settings. The access
keys must be assigned the CI/CD Integration role in all relevant workspaces. For details, see "Set
up API access" on page 305.
l Obtain access to a CI server that meets the necessary requirements. For the CI servers that are
supported by the ALM Octane CI plugins, see "CI Servers" on page 60.
l SaaS: To enable the CI server to communicate with ALM Octane, make sure that the server can
access the Internet.
If your network requires a proxy to connect to the Internet, setup the required proxy
configuration.
For example, on a Jenkins CI server: Go to Manage Jenkins > Manage Plugins > Advanced and
define the necessary HTTP Proxy Configuration details.
l For all CI servers besides TeamCity, decide which CI server user or TFS Personal Access Token
(PAT) ALM Octane will use to access the CI server and execute jobs.
The CI server user or TFS PAT must have the following permissions:

DevOps integrations
On Bamboo: Build plan
On Jenkins, for working with Job Build

pipelines:
On Jenkins, for ALM Octane- Job Create, Delete, and Read

UFT integration without If your SCM repository requires credentials, Credentials
pipelines: create and update permissions are also required. This is so
that ALM Octane can save the SCM access credentials you
provide on the Jenkins server.
On TFS: Read permissions for: Build, Code, Project and team, Test
management
Execute permissions for Build
On GoCD: View permissions, and permissions to run a pipeline.
Caution: We strongly recommend limiting this user’s permissions to the minimum

required for this integration.
Install the ALM Octane CI plugin

Download the relevant plugin from the Internet and install it on your CI server. Do one of the
following:
Jenkins In your Jenkins server's user interface, open the plugin management area and
upload the plugin:
1. Click Manage Jenkins (on the left).
2. Click Manage Plugins, select the Advanced tab, and scroll down to Upload
Plugin.
3. Browse to the plugin file that you downloaded and click Upload.
4. Select the option to restart Jenkins when installation is complete and no jobs
are running.
TeamCity In your TeamCity server's user interface, open the plugin management area and
upload the plugin:
1. Go to Administration > Plugins List and click Upload plugin zip.
2. Browse to the plugin file that you downloaded and click Upload.
3. Restart the TeamCity server.

DevOps integrations
Bamboo In your Bamboo server's user interface, open the add on management area and
upload the plugin:
1. Click the Administration cogwheel button and select Add-ons from the menu.
2. Click Pause server to pause the server while you install a new add on, to avoid
adverse effects on currently running builds.
3. Click Upload add-on, browse to the plugin file that you downloaded and click
Upload.
4. Click Resume server at the top of the page.
TFS Run the downloaded MSI on your TFS machine to install the plugin.
GoCD Download the plugin's .jar file and store it on your GoCD server in <GoCD server
folder>/plugins/external/.
Before configuring the plugin to access ALM Octane, the plugin installation must be complete.
Wait for the CI server to restart (Jenkins or TeamCity), refresh the add-on management page
(Bamboo), or restart the CI server (TFS, GoCD).
Note:
l If you enable or disable the plugin at any time after installation, you must restart your CI
server (Jenkins, TeamCity, Bamboo).
l To update or reinstall the TFS plugin, you must first stop the TFS Windows service:
Visual Studio Team Foundation Background Job Agent. Restart the service after the
plugin is updated.
Configure the ALM Octane CI plugin to access ALM Octane

After you install the ALM Octane CI plugin on your CI server, configure the plugin to access ALM
Octane and, if necessary, the CI server.
Tip: After installing the plugin and before configuring it, wait for the CI server to restart
(Jenkins or TeamCity), refresh the add-on management page (Bamboo), or restart the
CI server (TFS, GoCD).

DevOps integrations
1. Open the plugin's configuration area. Do one of the following:

Jenkins In your Jenkins server's user interface, locate the configuration area
for the ALM Octane CI plugin:
a. Click Manage Jenkins (on the left).
b. Click Configure System.
c. Scroll down to the configuration area for the ALM Octane CI.
TeamCity In your TeamCity server's user interface, locate the configuration

area for the ALM Octane CI plugin:
a. Go to Administration.
b. Under Server Administration, click ALM Octane CI Plugin.
Bamboo In your Bamboo server's user interface, locate the configuration area
for the ALM Octane CI plugin:
a. Click the Administration cogwheel button and select Add-ons
from the menu.
b. In the left pane, click ALM Octane CI Plugin under
COMMUNICATION.
TFS On your TFS machine, access the plugin's console:

a. Go to http://localhost:4567.
b. Click Configuration.
For more details, see the plugin's readme:
https://github.com/MicroFocus/octane-tfs-plugin#configure-the-
setup.
GoCD In your GoCD server's user interface, open Admin > Plugins.
Click the cogwheel displayed for the OctaneGoCDPlugin.
2. Enter the following information:

DevOps integrations
Location The URL of the ALM Octane server, using its fully qualified
domain name (FQDN).
Use the following format (port number is optional):
http://<ALM Octane hostname / IP address> {:<port
number>}/ui/?p=<space ID>
Example:
In this URL, the space ID is 1002:

http://myServer.myCompany.com:8081/ui/?p=1002
Tip: You can copy the URL from the address bar of the
browser in which you opened ALM Octane.
Client ID The API access Client ID that the plugin should use to connect to
ALM Octane. For details, see prerequisites, above.
Client secret The Client secret that the plugin should use to connect to ALM
Octane. For details, see prerequisites, above.
Jenkins user / The CI server user account that will run jobs at ALM Octane's
Bamboo user request.
This option is available only on Jenkins and Bamboo.
Caution:
l Make sure the user exists in the CI server.

l In Bamboo, you must specify a user.
In Jenkins, if you do not specify a Jenkins user, ALM
Octane uses Anonymous, and is limited to Anonymous’s
permissions.
TFS location and HTTP address and Personal Access Token for the plugin to use to
TFS PAT access TFS. The permissions required for this PAT are specified
above.
These options are available only on TFS.
GoCD API username The credentials for the plugin to use to access GoCD.

and password
3. Click Test Connection to validate the configuration, and then save your changes.

DevOps integrations
Moving an existing CI server to a new address

If your Bamboo or TeamCity CI server moves to a new location and you reinstall the plugin, you
must re-create the CI server and its pipelines in ALM Octane.
In Jenkins or TFS, if you move your server and reinstall the plugin, you can adjust the plugin's
configuration to continue working with your existing pipelines.
Configure the Jenkins or TFS plugin to work with existing ALM Octane
pipelines
1. Get the plugin instance ID originally used to set up the CI server on ALM Octane:
a. In ALM Octane, in Settings , click Spaces and select a workspace.
b. Click the DevOps tab. On the left side of the pane, select CI servers.
c. In the grid, locate the Instance ID column and copy your CI server's Instance ID.
2. In TFS or Jenkins, update the new plugin to use the original instance ID.
Jenkins In your Jenkins server's user interface:
a. Click Manage Plugins in the left pane.
b. Click Configure System.
c. Scroll down to the ALM Octane CI configuration area.
d. Click Show plugin instance ID.
e. In the Instance ID box, enter the Instance ID you copied from ALM Octane
earlier.
TFS a. On the TFS server, go to http://localhost:4567 to access the plugin's

console.
b. Click Configuration.
c. In the Instance ID box, enter the Instance ID you copied from ALM Octane
earlier.
For more details, see the plugin's readme:
https://github.com/MicroFocus/octane-tfs-plugin#configure-the-setup.
Upgrade from the ALM Octane CI Jenkins plugin to the Application

Automation Tools plugin
The Application Automation Tools plugin now includes the functionality of the ALM Octane CI
Jenkins plugin and includes the latest plugin improvements.

DevOps integrations
To upgrade from the ALM Octane CI plugin to the Application Automation

Tools plugin:
1. In Jenkins, click Manage Plugins in the left pane.
2. Select the Installed tab and uninstall the ALM Octane CI plugin.
3. Restart Jenkins.
4. On the Application Automation Tools wiki page, click the link to the latest plugin version,
download the plugin, and install it on your Jenkins server.
5. Restart Jenkins.
6. "Configure the ALM Octane CI plugin to access ALM Octane" on page 409.
7. "Configure the Jenkins or TFS plugin to work with existing ALM Octane pipelines" on the
previous page.
Next steps:
l "Add CI servers on ALM Octane" on page 405
l "Create and configure pipelines" on page 163 or "Set up UFT integration" on page 421
Set up your SCM system

If your CI server is set up to work with a Source Control Management (SCM) system, such as Git or
Subversion (SVN), ALM Octane can help you track committed changes. For details, see "Track
changes committed to your Source Control Management system" on page 199.
This topic explains how to customize SCM-related functionality.
In this topic:
l "Enable linking to your repository viewer (Git or SVN only)" below

l "Customize commit message patterns" on the next page
Enable linking to your repository viewer (Git or SVN only)

For each file displayed in the list of changed files, ALM Octane can provide links to the file view
and diff view in your repository viewer. To enable this, configure templates for the HTTP links.
This functionality is provided for repository viewers whose HTTP link templates include the file
path and the revision.
To configure templates for links to your repository viewer:

1. In Settings , click Spaces and select the workspace that is set up to integrate with your
CI server.

DevOps integrations
2. Click the DevOps tab. On the left side of the pane, select SCM Repositories.
This page lists any Git and SVN repositories that integrate with your CI servers.
Note: A repository is only displayed in this list after a pipeline run includes commits to
the repository.
3. For each repository (each row in the grid) enter the following:
• File link template. A template for the HTTP link to the file view of a selected file.
• Diff link template. A template for the HTTP link to the diff view of a selected file version.
The templates must include the placeholders {filePath} and {revision}. ALM Octane
replaces these with the relevant file's path and revision when creating the links.
Examples
l To link to BitBucket repository viewers, you would use templates like this:
o File link template: myServer:myPort/myRepository/browse/{filePath}?until=
{revision}&at={revision}
o Diff link template: myServer:myPort/myRepository/diff/{filePath}?until=
{revision}&at={revision}
l To link to GitHub repository viewers, you would use templates like this:
o File link template: https://github.com/myGithubUser/myGithubRepoName/blob/
{revision}/{filePath}
o Diff link template: https://github.com/myGithugUser/myGithubRepoName/commit/
{revision}/{filePath}
Example: If you were working with the nodejs/node repository, your templates
would look like this:
https://github.com/nodejs/node/blob/{revision}/{filePath}
https://github.com/nodejs/node/commit/{revision}/{filePath}
Customize commit message patterns

Commit message patterns define the strings to include in commit messages to associate them with
ALM Octane stories.

DevOps integrations
To modify the default commit message patterns, define new patterns using
Java regular expressions:
1. In Settings , click Spaces and select the workspace that is set up to integrate with your
CI server.
2. Click the DevOps tab. On the left side of the pane, select Commit Patterns.
3. Define the Commit message patterns to use for associating commits to the ALM Octane
story types (User story, Quality story, Defect).
Change an existing Commit message pattern or click + to add a new pattern. Using Java
regular expressions, design a pattern that contains a single capturing group containing the
story ID. For details about capturing groups, see
https://docs.oracle.com/javase/tutorial/essential/regex/groups.html.
For example, the default pattern defect\s*#(\d+) represents the string defect<any number
of spaces>#<defect id>.
The patterns are not case sensitive.
4. Click Validate commit pattern in the toolbar, to experiment with your patterns and make
sure that they match the string that you had in mind.
In the Validate Commit Pattern dialog box, enter an experimental commit message or part of
a message. Click Validate to see the stories that your commit patterns associate with this
comment.
Repeat this step to test all of the patterns you defined.
Example: This commit message includes the string user story #4. Therefore, it
matches the pattern for user stories:

DevOps integrations
5. Make sure to tell your SCM users about the patterns their commit messages must follow.
See also:
l "Create and manage test assignment rules" below
l "Track changes committed to your Source Control Management system" on page 199
Create and manage test assignment rules

Create test assignment rules to automatically assign application modules, test owners, and test
fields to automated tests, using filter conditions.
In this topic:
l "Introduction" below
l "Create test assignment rules" on the next page
l "Run test assignment rules" on page 418
l "Manage test assignment rules" on page 418
Introduction
You can use test assignment rules to automatically populate automated tests with various details,
based on filter conditions. This enables ALM Octane to incorporate automated test run results

DevOps integrations
that it collects from automation servers or other sources into the product quality analysis.
When an automated test matches your filter criteria, the following information can be
automatically assigned to the test:
l Application module
l Test owner
l Test framework
l Test type
l Test level
l Testing tool
This topic describes how to manage test assignment rules from the ALM Octane settings area. For
details on managing test assignment rules from the Tests tab, see "Create and manage rules to
assign automated tests" on page 151.
If a default setting was configured in Topology > Job configuration > Test fields, the default
setting overrides the assignment rule.
Create test assignment rules

Each rule can assign one or more of the fields listed above, to the tests that match your filter
criteria.

2. Click the DevOps tab. On the left side of the pane, select Test Assignment Rules.
4. Give the rule a meaningful name. For example, EndToEndTests.
5. Specify one or more of the following:
l The application modules to which you want to assign automated tests.
l A test owner to assign to the tests.
l The test fields you want to assign (test framework, type, level, and testing tool).
6. Click Add filter to add conditions based on the values of the following fields: Class name,
Component, Name, and Package.
Filters can be multipart and complex and can include '*' as a wildcard. If necessary, click the
Add filter button multiple times to add multiple items to the filter.
Example:
l Name is equal to EndtoEnd*

l Component is not equal to *Internal
All conditions must be met for the rule to assign the selected values to an automated test.

DevOps integrations
7. Select whether the rule should assign application modules and a test owner even if those
fields already have values, or only if they are empty.
As you edit the rule, you can see how many currently existing tests will be modified once you
save the rule.
8. Click Save.
Application module and test owner settings affect both current and future tests that match
the filter. This includes tests currently in the system, as well as new automated tests detected
in pipelines in the future.
Automated test fields (test framework, type, level, and testing tool) affect future runs, and
are updated according to the latest run.
Run test assignment rules

Test assignment rules run automatically:
l When a rule is saved.
l Each time a new automated test is discovered.
Note: You cannot run a rule manually.
Manage test assignment rules

In the DevOps tab, select Test Assignment Rules.
l To edit a rule, click the rule ID link and modify its definitions as described above.
l To sort, filter, group, delete, and export rules, use the toolbar options similar to other entities in
ALM Octane grids.
Example: When trying to understand why some tests are not properly being assigned,
group or sort the rules according to the properties in the rule's filter. Then compare the
properties in the rules to the properties of the test.
See also:
l "Work with application modules" on page 148

DevOps integrations
Manage all build failure classification rules

Create rules that map Jenkins build log messages to build failure classifications. ALM Octane uses
these rules to analyze build logs and automatically classify build failures.
This topic describes how DevOps admins can manage build failure classification rules. Other users
can create classification rules inside a pipeline run, when analyzing build failures. For details, see
"Create rules to classify build failures automatically" on page 189.
In this topic:
l "Best practices for managing rules" below
l "Create a build failure classification rule" below
l "Modifying a rule that is already in use" on the next page
Best practices for managing rules

It's most convenient to create rules in a pipeline run's Builds tab. You can open a build log and
create a rule based on a specific message.
In Settings, you can edit existing rules or remove rules that are not necessary.
To access Settings:
2. Click the DevOps tab. On the left side of the pane, select Log Classification Rules.
The goal is to reach a small number of rules that cover most of the log messages and build failure
classifications that are relevant for your pipeline runs.
Create a build failure classification rule

1. In Settings, open Log Classification Rules as described above.
3. Give the rule a meaningful name, such as Null pointer.
4. Enter the pattern that identifies the log lines you want to map to a specific build failure
classification.
Use * as a wildcard and use a \ before special characters.
Example: *NullPointerException*
5. Select a classification to assign to log lines that match the pattern.
For example: Code issue

Testing integrations
Tip: To add classification labels to the list of available labels, go to a pipeline run's
Builds tab and click the Build Failure Classification button.
6. Click OK.
The rule is applied whenever ALM Octane receives a Jenkins build log for a failed build.
Log lines that match the pattern are labeled with the specified classification. If a line matches
more than one rule, it is classified by the most recently updated rule.
The relevant builds are automatically labeled with the first classification mapped in their log.
Modifying a rule that is already in use
What happens when I change a rule that is in use?

If you change a rule's classification, any log line already assigned by this rule is labeled with the
new classification.
This affects log files from previous builds, but does not affect the classification of any existing
builds. The change in the rule affects the classification of future builds only.
What happens when I delete a rule that is in use?

If you delete a rule that has already assigned a classification to a build log line, the classification is
removed from all log files, but remains on any builds is was assigned to.
See also:
This section provides instructions for integrating testing tools with ALM Octane.
Topic Description
"Set up UFT How to set up ALM Octane via Jenkins to discover and run UFT tests stored
integration" on in your SCM repository. Once the integration is set up, Jenkins and the
the next page SCM system are transparent and you can work with UFT and ALM Octane
directly.

Topic Description
"Set up How to bring your security testing into your development cycle by integrating
security ALM Octane and Fortify on Demand.
testing
integration" on
page 427
Set up UFT integration

This topic explains how to integrate ALM Octane with UFT via Jenkins. This integration enables
ALM Octane to reflect the UFT tests from your Source Code Management (SCM) repository as
executable automated tests. You can then include and run these UFT tests in test suites.
In this topic:
l "ALM Octane-UFT integration flow" below
l "Before you set up the integration" on the next page
l "In Jenkins, set up the connection to ALM Octane" on page 423
l "In ALM Octane, add your Jenkins CI server " on page 423
l "Create a testing tool connection in ALM Octane" on page 423
l "Assign the tests to your backlog and application modules" on page 424
l "Setup Jenkins and UFT so Jenkins can trigger UFT test runs" on page 425
ALM Octane-UFT integration flow

Once the UFT integration is set up, Jenkins and the SCM system are transparent and you can
work with UFT and ALM Octane directly:
l Create and edit your tests and their data tables in UFT and save them in a Git or SVN
repository.
l Run the tests and track their results in ALM Octane.
The ALM Octane-UFT integration flow includes the following:

Set up. To set up the integration, create a CI server and a testing tool connection in the ALM
Octane settings. This process is described in the sections below.
ALM Octane discovers UFT tests and data tables. ALM Octane creates automated test entities to
represent the GUI and API UFT tests stored in your repository.
ALM Octane periodically checks for changes in the repository.
Associate tests with ALM Octane entities. Associate the tests with your backlog and application
modules. This helps you use the test run results in ALM Octane to track your product and release
quality.

Run tests. Include the tests in test suites to plan and run them from ALM Octane. ALM Octane
triggers the test runs via the CI server. The tests run on UFT machines configured as Jenkins
execution nodes.
Analyze release and product quality. Track the UFT test results as part of the overall data in the
backlog, quality, and dashboard modules.
The image below summarizes the architecture of this integration:
Before you set up the integration

Set up UFT to store tests and data tables in a Git or SVN repository. For details, see the Help
Center: http://uft-https://admhelp.microfocus.com/uft/en/latest/UFT_Help/Content/User_
Guide/UFT_SVN_Integration.htm.
Note:
l UFT-SCM integration is supported for UFT 12.50 and later.

l For ALM Octane to locate the data tables in your repository, store them in an entirely
separate folder from your tests.
Set up a Jenkins server configured with an SCM plugin:

1. Install a Jenkins server. You do not need to configure a full CI system for this integration.
Configure only the area described below.

For the CI servers that are supported by the ALM Octane CI plugins, see "CI Servers" on
page 60.
2. Install the Jenkins Git plugin (version 2.4.4 or later) or the Subversion plugin (version 2.5 or
later) to create the Jenkins-SCM integration.
In Jenkins, set up the connection to ALM Octane

1. Install the Application Automation Tools plugin.
This plugin supports ALM Octane-Jenkins integration and enables Jenkins to run UFT tests.
If your tests are stored in ... Use this version of the plugin
Git 5.2 or later
SVN 5.3.5 (beta) or later

2. Configure the plugin to connect to ALM Octane. For details, see "Install and configure the
ALM Octane CI plugin on your CI server" on page 406.
Tip: Before configuring the plugin, obtain an API access Client ID and Client secret
from your space admin. For details, see "Set up API access" on page 305.
You do not need to create pipelines in ALM Octane or create any jobs in Jenkins.
In ALM Octane, add your Jenkins CI server

1. In ALM Octane, click Settings , select Spaces and select a workspace.
2. Select the DevOps > CI Server tab.
3. Add a CI server and select your Jenkins server's URL.
For more details, see "Add CI servers on ALM Octane" on page 405.
Create a testing tool connection in ALM Octane

Tip: You can only define one testing tool connection per workspace.
2. Select the DevOps > Testing Tools tab.

3. Click + Connection.

4. Select your Jenkins server.

The list displays all servers that meet the following conditions:
l The server has the ALM Octane CI plugin installed and configured to access your ALM
Octane.
l The API Access keys that the plugin is using are assigned the CI/CD Integration role in the
current workspace.
5. Specify the type and URL of the SCM repository that contains your UFT tests and data
tables.
6. Provide the authentication details for your repository.
7. Click Test Connection to make sure the configuration is correct.
8. Click Save and Connect to complete the connection.
ALM Octane creates a Jenkins job that connects to the repository and discovers the UFT tests
and data tables.
Tip: If necessary for troubleshooting, you can find this job on your Jenkins server based
on the connection ID.
The test scripts and the data table content are available in UFT only.
In the automated test entities in ALM Octane, the following fields are set:
l Testing tool type = UFT
l Test type = API or UI
l Executable = Yes. These tests can be added to test suites and run from ALM Octane.
ALM Octane continues to periodically check the repository and update its entities accordingly.
l If you add a new test in UFT or change an existing one, the changes are reflected in ALM
Octane.
l If you delete a test from UFT, the relevant test in ALM Octane is not deleted but is marked as
not executable. This way, the test and its history, runs, and reports remain available.
If you do not see all of the expected tests in the Tests tab in ALM Octane, try refreshing the
list of tests.
Assign the tests to your backlog and application modules

Assign tests to the backlog and to application modules to include them in your release and
product quality tracking. For example, you can check test coverage even before you run the tests.
For details, see "Assign tests to application modules and backlog items" on page 270.

Setup Jenkins and UFT so Jenkins can trigger UFT test runs
This section describes configuration required on your UFT machine and on Jenkins, to enable
Jenkins to run UFT tests.
Make sure UFT can run your tests

l When UFT opens, it must load all of the add-ins required for your tests.
l The UFT machine must be able to access the application under test.
Configure UFT to enable running tests over a disconnected remote

connection
This configuration is required if you are using execution nodes to run the UFT tests. Without this
configuration, test runs triggered by ALM Octane will remain Pending on Jenkins until someone
logs in to the execution node either directly or with a remote desktop connection.
To configure:
1. In the UFT Options dialog box, open the Run Sessions pane (Tools > Options > General tab
> Run Sessions node).
2. Select Allow UFT to continue running GUI or business process tests after disconnection
from an RDP computer.
3. Enter a user name and password of a user who can log in to the UFT machine.
Connect Jenkins to your UFT machines

1. On your Jenkins server, define your UFT machines as execution nodes. Jenkins will use these
nodes to run UFT tests that ALM Octane triggers.
Make sure the names of your execution nodes include the string uft.
2. On the UFT machine, connect the execution node to the Jenkins server:
Open the Jenkins server URL in a browser, go to Manage Jenkins > Manage Nodes.
Select the node, click Launch to download an agent program from the server to the execution
node, and then run that program on the UFT machine.
For details, see the section on execution nodes in the Application Automation Tools wiki page.
Note: If your Jenkins server is installed on a Windows machine, you can install UFT on the
same machine instead of creating execution nodes.

Set up Jenkins to enable running UFT API tests
Relevant if you are working with a UFT version earlier than 14.01.
To run API tests, ALM Octane needs the Script.dll and Script.pdb files that UFT generates when it
first runs the test.
By default, these files are not stored in the SCM repository.
To make these files available to ALM Octane:
1. Run the API test in UFT to generate the files.
2. Adjust your SCM definitions so Script.dll and Script.pdb are not ignored.
3. Push (Git) or commit (SVN) the tests from UFT to save the files in the repository.
4. Verify that the Script.dll and Script.pdp files are now in the repository.
Set up Jenkins to enable opening the UFT tests result from ALM Octane
By default, Jenkins' Content-Security-Policy header prevents viewing UFT test results reports
remotely.
To enable opening UFT reports from ALM Octane using the Testing tool report button in an
automated test, you must clear the CSP property.
Implement one of the following workarounds:
l Clear the property temporarily, until the next time the Jenkins server restarts:
In Jenkins, open Manage Jenkins > Script Console, and run:
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")
l Clear the property permanently:

Run Jenkins with JAVA_OPTS option and add the following option:
-Dhudson.model.DirectoryBrowserSupport.CSP=
Next steps:
l "Run UFT tests as part of a test suite" on page 276

Set up security testing integration

This topic explains how to set up integration with Fortify on Demand, bringing security testing
into your development cycle.
In this topic:
l "Overview of the ALM Octane integration with Fortify on Demand" below
l "Prerequisite: Set up Fortify on Demand and ALM Octane to integrate with Jenkins" on the
next page
l "Create a Fortify on Demand security tool connection in ALM Octane" on the next page
l "Create a pipeline with a Fortify on Demand Upload step" on page 429
l "Configuration options" on page 429
Overview of the ALM Octane integration with Fortify on Demand
What is Fortify on Demand?

Fortify on Demand is a cloud-based application security testing service. It performs static code
analysis on your application's code, assessing it for potential security vulnerabilities.
Why integrate ALM Octane with Fortify on Demand?

Integrate ALM Octane with Fortify on Demand to bring security testing into your development
cycle:
l Identify security vulnerabilities soon after they are introduced into the code and correct them.
l Raise developers' awareness, encouraging them developers to avoid introducing vulnerabilities.
How does the integration work?

Periodically, during the development cycle, run a pipeline on Jenkins that includes a Fortify on
Demand Upload step. After this step uploads the application's code to Fortify on Demand, a
security assessment of your code begins.
If the pipeline run is successful, ALM Octane polls the Fortify on Demand server. When the
assessment is complete, ALM Octane retrieves the newly found vulnerabilities and displays them
in the pipeline run.
After reviewing the vulnerabilities, you can create a relevant defect to fix in your code, or dismiss
and close the issue. For details, see "Track security vulnerabilities" on page 212.
Important privacy note: If your Fortify on Demand data contains personally identifiable

information (PII), contact your system administrators to check the geographical locations
of the Fortify on Demand data farm and the ALM Octane server. If the two are located in
different geographical locations, verify with your chief information security officer or
privacy office that this integration complies with your regional regulations.
Prerequisite: Set up Fortify on Demand and ALM Octane to

integrate with Jenkins
ALM Octane collects security assessment results after a pipeline runs a Jenkins job that uploads
your application's code to Fortify on Demand.
Start by setting up Jenkins to integrate with Fortify on Demand and setting up ALM Octane to
integrate with Jenkins:
1. Set up your Fortify on Demand account. For details, see https://software.microfocus.com/en-
us/software/fortify-on-demand.
Define an application whose code you want Fortify on Demand to assess.
We recommend that you run the first security assessment on your code manually and audit it
with security experts, before integrating with ALM Octane.
Obtain the URL and API keys required to access the Fortify on Demand server using API.
The keys must permit reading vulnerabilities.
2. Set up Jenkins to upload your code to Fortify on Demand.
a. Install and configure the Fortify on Demand Uploader plugin on your Jenkins server.
b. Create a Fortify on Demand Upload step on Jenkins to upload your application's code to
Fortify on demand for assessment. In the build step information (BSI) fields, configure
the application and release that you used to define your application in your Fortify on
Demand account.
For details, see
https://wiki.jenkins.io/display/JENKINS/Fortify+On+Demand+Uploader+Plugin.
3. Set up ALM Octane integration with your Jenkins server. For details, see "Set up CI servers"
on page 403.
Create a Fortify on Demand security tool connection in ALM Octane

Add Fortify on Demand as a security tool in the DevOps settings page, so ALM Octane can
retrieve the assessment results from the Fortify on Demand server:

2. Select the DevOps > Security Tools tab.
3. Click + Connection.

ChatOps integrations
4. Define a name for the connection and select the security tool (Fortify On Demand).
5. Enter the URL for your Fortify on Demand server, and the API keys required to access it.
6. Click Test Connection to make sure the configuration is correct.
7. Click Add to add the security tool to the list.
After a pipeline step uploads code to Fortify on Demand for assessment, ALM Octane will use
this connection information to contact Fortify on Demand and retrieve the assessment
results.
Create a pipeline with a Fortify on Demand Upload step

In ALM Octane, create a pipeline that includes the Fortify on Demand Jenkins Upload step that
you created earlier:
1.
In the Pipelines > Pipelines page, add a new pipeline.
2.
Select the Fortify on Demand Upload job or the root of a flow that includes it.
3.
In the Type field, select Security.
4.
Select the option This pipeline includes a Fortify on Demand job.
5.
Enter the Application and Release that you used when configuring the Jenkins Fortify on
Demand Upload step. These details identify the application whose code Fortify on Demand is
scanning.
After this pipeline runs successfully, ALM Octane polls the Fortify on Demand server, waiting to
retrieve the assessment results.
Configuration options
By default, ALM Octane checks Fortify on Demand every 2 minutes for 48 hours to see if the scan
is finished. If there are more than 100 vulnerabilities, ALM Octane retrieves none.
All these limits can be configured using the following configuration parameters:
l FORTIFY_POLLING_TIMEOUT_HOURS
l FORTIFY_POLLING_DELAY_MINUTES
l FORTIFY_UPPER_LIMIT_OF_ISSUES
For details, see "Configuration parameters" on page 480.
See also:
l "Track security vulnerabilities" on page 212
This section provides instructions for integrating a ChatOps application with ALM Octane.

Topic Description
"Set up Slack" How to set up Slack so stakeholders of a backlog item or a pipeline run failure
below can collaborate and communicate.
Set up Slack
Integrating with Slack enables all stakeholders of a backlog item or a pipeline run failure to
collaborate and communicate.
In this topic:
l "Overview" below
l "Configure integration with Slack" below
l "Create a Slack app for ALM Octane (on-premises)" on the next page
Overview
When you set up integration with Slack, you add your ALM Octane workspace to a Slack
workspace. Then, users can open Slack channels for discussions from within ALM Octane items.
For details, see "Collaborate with an item's stakeholders" on page 79.
If you configure the integration to expose ALM Octane data on Slack channels, information from
the backlog item is sent to the channel.
Note: You can add your ALM Octane workspace to only one Slack workspace.
We recommend using different Slack workspaces for different ALM Octane workspaces.
Configure integration with Slack

To enable your ALM Octane workspace users to collaborate in Slack, define Slack as a
collaboration tool in ALM Octane, and add your ALM Octane workspace to your Slack workspace:
1. Prerequisite On-premises: Create a Slack app for ALM Octane to use. For details, see "Create
a Slack app for ALM Octane (on-premises)" on the next page.
2. In ALM Octane, in Settings , click Spaces and select your workspace.
3. Click the DevOps tab. On the left side of the pane, select Collaboration Tools.
4. Click + to add Slack as a collaboration tool. The Add Collaboration Tool dialog box opens.
5. In Slack, make sure you have a workspace to use for all communication related to this ALM
Octane workspace. Add all of your ALM Octane workspace members to the Slack workspace.

If you do not have such a workspace, click the link in the Add Collaboration Tool dialog box
to open Slack and create a workspace.
l When creating a new Slack workspace, make sure to use an email address that you can
access. Slack sends a confirmation code to this address as part of the process.
You can use the same email address to create different Slack workspaces.
l You can add members to the Slack workspace at any time.
When you finish creating the Slack workspace, go back to the ALM Octane browser tab.
6. Consider carefully whether to allow exposing internal ALM Octane information on the Slack
channel.
If you select the checkbox for this option in the Add Collaboration Tool dialog box, ALM
Octane sends information about the relevant backlog items to the Slack channels it opens.
Note: You can modify this setting at any time in the collaboration tool grid.
7. Click to add your ALM Octane workspace to the Slack

workspace.
The ALM Octane chat application registered on Slack requests access to your Slack
workspace.
For SaaS ALM Octane, the name of the application is octanechatsapp. For on-premises ALM
Octane, the application is set up by your site admin.
8. Optionally, select a different Slack workspace and select whether to expose more or less
information about your Slack workspace to ALM Octane.
9. Click Authorize.
The integration with Slack is complete. The Chat w/ Slack button is now enabled in backlog items
and in a pipeline run's Tests tab.
Troubleshooting: If the integration setup fails due to a communication failure, reporting

an inaccessible redirect_url, contact your site admin to make sure that the configuration
parameter SERVER_BASE_URL is defined correctly.
For details, see the ALM Octane Installation and Administration Guide .
Create a Slack app for ALM Octane (on-premises)

To enable configuring Slack integration on your ALM Octane site, the site admin creates a Slack
app and configures ALM Octane to use it:

IDE integrations
1. Using a Slack account that belongs to ALM Octane's site admin, create a new Slack app for
ALM Octane to use.
One Slack application can serve many ALM Octane instances. For detailed instructions, see
https://api.slack.com/slack-apps.
2. Complete the new Slack app's configuration and activate distribution:
a. In Add features and Functionality, click Permissions and select any permission scope.
ALM Octane does not rely on this configuration.
b. In Manage Distribution, click Distribute App and configure sharing your app with other
workspaces. Add an OAuth Redirect URL with ALM Octane's URL.
Add the URL in the following format (port number is optional) and click Save URLs:
http://<ALM Octane hostname / IP address> {:<port number>}/internal-api
For example, http://myServer.myCompany.com:8081/internal-api
c. In Remove Hard Coded Information, select the check box.
d. Click the button to activate distribution.
e. At https://api.slack.com/apps, make sure the app's distribution status is Distribution
activated.
3. Provide ALM Octane with the credentials required for working on behalf of the Slack app you
created.
a. In the Slack app's Basic Information > App Credentials area, locate the Client ID and
Client Secret.
b. Enter the client ID and secret values respectively into the ALM Octane configuration
parameters: SLACK_INTEGRATION_CLIENT_ID, SLACK_INTEGRATION_SECRET.
For details, see "Set configuration parameters (technical preview)" on page 479.
IDE integrations
This section provides instructions for integrating integrated development environments (IDEs)
with ALM Octane.
For a feature support matrix, see "Functionality supported by IDE integrations" on page 304.
Topic Description
"Work in IntelliJ IDEA" How to do your ALM Octane work directly from the IntelliJ IDEA IDE.
on the next page To do so, install the ALM Octane plugin for IntelliJ IDEA.
"Work in Eclipse How to do your ALM Octane work directly from Eclipse IDEs, such as
Oxygen IDEs" on Neon and Mars. To do so, install the ALM Octane plugin for Eclipse.
page 440
"Work in the Microsoft How to do your ALM Octane work directly from the Microsoft Visual
Visual Studio IDE " on Studio development framework. To do so, install the ALM Octane
page 448 plugin for Visual Studio.

IDE integrations
Work in IntelliJ IDEA
You can do your ALM Octane work directly from the IntelliJ IDEA IDE. To do so, install the ALM
Octane plugin for IntelliJ IDEA.
Limitations: User-defined fields are not accessible from IntelliJ IDEA.
In this topic:
l "About the ALM Octane plugin for IntelliJ IDEA" below
l "Download and install the ALM Octane plugin for IntelliJ IDEA" on the next page
l "Connect to ALM Octane" on page 435
l "Work on your ALM Octane items" on page 436
About the ALM Octane plugin for IntelliJ IDEA

Using the plugin, developers can connect to an ALM Octane workspace, view ALM Octane items,
and make updates.
The plugin is open source. To access the source code, see https://github.com/MicroFocus/octane-
intellij-plugin.
The plugins support two-way integration:
l The plugin updates all data in the host IntelliJ IDEA application.
l Changes made in the IntelliJ IDEA impact data in ALM Octane.
Prerequisites
1. Verify that your operating system is supported:
l Windows 10 (Normal and Darcula themes)
l Ubuntu 16.04
l macOS 10.12
2. Verify that your software is supported:

App / Plugin Version
ALM Octane IntelliJ IDEA plugin 12.53.21 and later
ALM Octane 12.53.20 and later

IDE integrations

IntelliJ IDEA 2016.2 and later
Download and install the ALM Octane plugin for IntelliJ IDEA

1. Go to the JetBrains Plugins store: https://plugins.jetbrains.com/idea/plugin/9540-alm-
octane.
Click Download.
2. In IntelliJ IDEA, choose File -> Settings -> Plugins.
3. Click Install plugin from disk...
4. Navigate to, and select, the zip file that you downloaded.
5. Click Apply and OK.
6. Restart IntelliJ IDEA.
Tip: You can also look for the plugin in the IntelliJ store and install it directly using the
Browse Repositories… button.

IDE integrations
Connect to ALM Octane

After installing, a new category of settings is available in IntelliJ IDEA. We use this area to connect
IntelliJ IDEA to ALM Octane.
1. In IntelliJ IDEA, choose File -> Settings -> ALM Octane Settings.

2. Enter the URL for the ALM Octane server. The URL should include the query parameters for
the relevant space and the workspace. The format is:
https://<server>:<port>/ui/?p=<spaceID>/<workspaceID>
3. Enter the user name and password for logging into ALM Octane.
4. Click Test connection.
You can now work with ALM Octane from within IntelliJ IDEA.

IDE integrations
Work on your ALM Octane items

IDE integrations
This section describes how to do your ALM Octane from ALM Octane's My Work tab.

IDE integrations
1. Open the ALM Octane My Work tab

On the bottom left, click and select ALM Octane. The tab for My Work opens, displaying
work assigned to you, grouped by category.
When you start another session, the ALM Octane IntelliJ IDEA plugin remembers what you
were working on last time, and opens tabs in the ALM Octane pane accordingly.
Most ALM Octane items are available from the IDE.
You can use the buttons to refresh the display, and to expand or collapse the My
Work categories.
Tip: To indicate that you are working on a particular item, and associate code changes
with the item, right-click the item in the My Work list, and choose Start work. When
you are done, right-click and choose Stop work.

IDE integrations
2. View an item's details

Double-click most items to open their details in a separate pane.
Click to choose which fields to see. You can also choose None or All. These settings only
affect you. When you start another session, the ALM Octane IntelliJ IDEA plugin remembers
your field selection.
To display the details of an item in ALM Octane, click the item name, which is a link.
3. Search for items
You can search the list of items in My Work. The search results are opened in a new tab.
The plugin remembers the last five searches you ran. Click to select one and re-run the
search.
The search runs in the scope of the current IntelliJ IDEA project only.
Tip: The search looks through all ALM Octane items, not just the ones assigned to
you. You can use the search to assign an item to yourself.
4. Update your items

As you implement stories and fix defects in IntelliJ IDEA, update your ALM Octane items.
l Move the status of an item from one phase to another, according to the defined ALM
Octane workflow. Make sure to save .

l Click Comments to view and add comments.
5. Download Gherkin test scripts to implement automation
Gherkin tests can be initially created in ALM Octane, and then automated using IntelliJ IDEA.
In My Work, right-click a Gherkin test, and choose Download script.
Select the folder into which you want to download the Gherkin test. Click OK.
The downloaded script name is in the following format:
<TestName >-<TestID>.feature
If the file already exists, you are prompted to overwrite it. Alternatively, you can cancel, and
first rename the original script.
6. Commit changes with auto-complete
You can declare to the SCM system, such as Git, that you have started work on an item. This
means that when you commit your changes for that item, the commit message is auto-
completed.
You can commit changes for user stories, quality stories, defects, or active tasks.

IDE integrations
a. In My Work, right-click a user story, a quality story, a defect, or an active task.

b. Choose Start work. A "play button" appears on the icon for the item.
Also, the item appears as a button in the toolbar in IntelliJ IDEA. You can click
this button to open the item's details in a tab.
The auto-complete format for the commit message contains the type and the item ID,
followed by a colon (:). After the colon, enter more details for your commit message.
If committing tasks, the item related to the task (such as a story or defect) is also included.
To cancel the auto-complete of the commit message, in My Work, right-click the item and
choose Stop work.
Tip: You can also manually edit commit messages, without using auto-complete. For
details, see "Track changes committed to your Source Control Management system"
on page 199.
See also:
Work in Eclipse Oxygen IDEs

You can do your ALM Octane work directly from the Eclipse Oxygen IDE packages, such as Neon
and Mars. To do so, install the ALM Octane plugin for Eclipse.
In this topic:
l "Overview" below
l "Work in Eclipse Oxygen IDEs" above
l "Download and install the plugin" on the next page
l "Connect to ALM Octane" on page 443
Overview
and make updates.
The plugins are open source. To access the source code, see
https://github.com/MicroFocus/octane-eclipse-plugin.

IDE integrations

l The plugin updates all data in the host Eclipse application.
l Changes made in Eclipse impact data in ALM Octane.
Prerequisites
l Windows 10
l Windows 8
l Windows 7
l macOS 10.12

ALM Octane Eclipse plugin 12.55.4 and later

3. Verify that other software is supported:
Software Version
Java 1.8 and later
Download and install the plugin

There are three methods for downloading and installing the plugin.
l "From the Eclipse Marketplace" below
l "From inside the Eclipse IDE" below
l "From inside the Eclipse IDE for remote installation" on the next page
From the Eclipse Marketplace

1. From within the Eclipse IDE, choose Help -> Eclipse Marketplace.
2. In the Find box, search for the ALM Octane plugin. Follow the on-screen instructions to
install it.
From inside the Eclipse IDE

1. From within the Eclipse IDE, choose Help -> Install New Software.
2. Enter the URL for accessing the ALM Octane IDE plugin for Eclipse in Work with and click
Add.

IDE integrations
3. Enter a name for the software in the Add Repository dialog box.
4. Click Select All and Next twice.
5. Accept the terms, and click Finish.
6. Restart the Eclipse IDE.
7. Continue to "Connect to ALM Octane" on the next page.
From inside the Eclipse IDE for remote installation

To install the plugin at remote locations without Internet access, download a compressed archive
of the plugin onto a storage device.
1. Access this URL to download the archive:
https://github.com/MicroFocus/octane-eclipse-plugin/tree/gh-pages
2. Click Clone or Download.
3. Select Download ZIP.
4. Unzip onto the storage device.
Example: F:/MyEclipse/octane-eclipse-plugin-gh-pages
5. For each remote computer, start the Eclipse IDE and choose Help->Install New Software.
6. Enter the URL for accessing the ALM Octane IDE plugin for Eclipse in Work with.
To do this, click Local and navigate to the update-site folder:
<AnyName> - file:/F:/MyEclipse/octane-eclipse-plugin-gh-pages/update-site/
Click Add.
7. Click Select All and Next twice.
8. Accept the terms and click Finish.
9. Restart the Eclipse IDE.
10. Continue to "Connect to ALM Octane" on the next page.

IDE integrations

After installing, a new category of settings is available in Eclipse. We use this area to connect
Eclipse to ALM Octane.
1. In Eclipse, choose Window->Preferences-> ALM Octane Settings and continue to "Connect to

ALM Octane" above.
2. Enter the URL for the ALM Octane server. The URL should include the query parameters for
the relevant space and the workspace. The format is:
https://<server>:<port>/ui/?p=<spaceID>/<workspaceID>
4. Click Test connection.
Tip: In Eclipse, if prompted, you can specify password hints for recovering your password.
You can now work with ALM Octane from within Eclipse.

IDE integrations

IDE integrations
This section describes how to do your ALM Octane from the ALM Octane's My Work tab.
1. Open the ALM Octane My Work tab
Choose Window > Show View > Other. Then expand Octane: My Work and select the
connection. The My Work tab opens, displaying work assigned to you. Use the checkboxes in
the My Work tab to filter which items you can see.

IDE integrations
When you start another session, the ALM Octane Eclipse plugin remembers what you were
working on last time, and opens tabs in the ALM Octane pane accordingly.
You can see the comments in which you are mentioned. From a comment, you can navigate
to the item that has the comment. To do this, double-click.
Tip: To indicate that you are working on a particular item, and associate code changes
with the item, right-click the item in the My Work pane, and choose Start work. A
green triangle on the item icon indicates that you are "on it." When you are done,
right-click and choose Stop work.
2. View details
Double-click any item to open its details in a separate pane.
Click to choose which fields to see. You can also choose None or All. These settings only
affect you. When you start another session, the ALM Octane Eclipse plugin remembers your
field selection.
Tip: You can also open the item directly in ALM Octane in a browser. Right-click the
item in the My Work pane, and choose:
l View in Browser (System). This opens the item in a new browser window.
l View in Browser (Eclipse). This opens the item in a new pane in the current Eclipse
IDE.
To return to the regular Eclipse IDE view, right-click the item and choose Details View.
3. Search for items
You can search the list of items in the My Work pane and display the results in a new tab, the
relevant items based on search criteria. Enter a search string in the search box. The search
results are opened in a new pane.
The plugin remembers the last five searches you ran. Click to select one and re-run the
search.
The search runs in the scope of the current Eclipse project only.

IDE integrations
As you implement stories and fix defects in Eclipse, update your ALM Octane items.

l Update field values.
If a rule exists that makes a field read-only, and you modify its value, the plugin notifies
you when you save the item.
Gherkin tests can be initially created in ALM Octane, and then automated using Eclipse.
a. In the My Work pane, right-click a Gherkin test, and choose Download Script.
b. Select the folder into which you want to download the Gherkin test. Click OK.
The downloaded script name is in the following format:
<TestName >-<TestID>.feature
If the file already exists, you are prompted to overwrite it. Alternatively, you can cancel,
and first rename the original script.
6. Commit changes with generated messages
You can declare to the SCM system, such as Git, that you have started work on an item in
an Eclipse project. This means that when you commit changes for that item, automatically-
generated text can be copied and pasted into the commit message for the item.
a. In the My Work pane, right-click a user story, a quality story, a defect, or an active task.
b. Choose Start work. A "play button" appears on the icon for the item.
Also, the item appears as a button in the toolbar in Eclipse. You can click this
button to open the item's details in a tab.
c. To generate the text for the commit message and copy it into the clipboard, right-click
and select Commit Message to Clipboard.
d. Commit your changes. In the Git Staging area, paste the contents of the clipboard into
the Commit Message area.
The format for the commit message contains the type and the item ID, followed by a
colon (:). After the colon, enter more details for your commit message.
For tasks, the item related to the task (such as a story or defect) is also included.
To cancel the commit message, in the My Work pane, right-click the item and choose Stop
work.
You can also manually edit commit messages. For details, see "Track changes committed to
your Source Control Management system" on page 199.

IDE integrations
See also:
Work in the Microsoft Visual Studio IDE

You can do your ALM Octane work directly from the Microsoft Visual Studio development
framework. To do so, install the ALM Octane plugin for Visual Studio.
In this topic:
l "Overview" below
l "Work in the Microsoft Visual Studio IDE " above
l "Download and install the plugin" on the next page
l "Connect to ALM Octane" on the next page
Overview
and make updates.
The plugins are open source.
l The plugin updates all data in the host Visual Studio application.
l Changes made in Visual Studio impact data in ALM Octane.
Prerequisites
l Windows 10
l Windows 8
l Windows 7

Microsoft Visual Studio 2015 and 2017
All editions: Community, Professional, and Enterprise

IDE integrations

ALM Octane Visual Studio plugin 12.55.7 and later
Download and install the plugin

Download the plugin from the Visual Studio Marketplace.
1. From within the Visual Studio IDE, choose Tools > Extensions and Updates > Online
> Visual Studio Marketplace.
Or, go to the Visual Studio Marketplace.
2. Search for the ALM Octane plugin. Follow the on-screen instructions to install it.
3. Continue to "Connect to ALM Octane" below.

After installing, a new category of settings is available in Visual Studio. We use this area to connect
Visual Studio to ALM Octane.
1. In Visual Studio, choose Tools > Settings > ALM Octane.

2. Enter the URL for the ALM Octane server. The format is:

IDE integrations
https://<server>:<port>
You can now work with ALM Octane from within Visual Studio.

This section describes how to do your ALM Octane from the ALM Octane pane.
1. Open the ALM Octane pane
Choose View > Other Windows > ALM Octane. The ALM Octane pane displays work
assigned to you.
When you start another session, the ALM Octane Visual Studio plugin remembers what you
were working on last time, and opens tabs in the ALM Octane pane accordingly.
2. View an item's details
Double-click most items to open their details in a separate pane.
Click to choose which fields to see. These settings only affect you. When you start
another session, the ALM Octane Visual Studio plugin remembers your field selection.
Click to view the item's comments.
Tip: You can also:

IDE integrations
l Open the item directly in ALM Octane in a browser. Press Alt and double-click the
item in the ALM Octane pane.
l Right-click the item and choose one of the following options from the context
menu: Show Details and Open in Browser.
3. Search for items

You can search all ALM Octane items and display the results in a new tab, showing only the
relevant items based on search criteria.
Enter a search string in the search box. The search results are opened in a new pane.
The plugin remembers the last five searches you ran. Click the drop-down arrow to select one
and re-run the search.
As you implement stories and fix defects in Visual Studio, update your ALM Octane items.

Gherkin tests can be initially created in ALM Octane, and then automated using Visual Studio.
In the ALM Octane pane, right-click a Gherkin test, and choose Download Gherkin Script.
6. Commit changes with generated messages
When you commit changes for an item, automatically-generated text can be copied and
pasted into the commit message for the item.
a. In the ALM Octane pane, right-click a user story, a quality story, a defect, or an active
task.
b. To generate the text for the commit message and copy it into the clipboard, right-click
the item and select Commit Message to Clipboard.
c. Commit your changes. In the Git Staging area, paste the contents of the clipboard into
the Commit Message area.
The format for the commit message contains the item type, the item ID, a colon (:), and
the item name. You can enter more details for your commit message after the name.
For tasks, the item related to the task (such as a story or defect) is also included.
You can also manually edit commit messages. For details, see "Track changes committed to
your Source Control Management system" on page 199.

Reporting integrations
See also:
This section provides instructions for integrating reporting and business intelligence (BI) tools
with ALM Octane.
Topic Description
"OData support for How to use OData (Open Data Protocol) to extend and improve
extended reporting reporting capabilities, above and beyond the functionality provided
(technical preview)" by ALM Octane dashboard widgets.
below
OData support for extended reporting (technical

preview)
ALM Octane supports OData (Open Data Protocol), the OASIS REST-based standard for
accessing data. You can use OData to extend and improve reporting capabilities, above and
beyond the functionality provided by ALM Octane dashboard widgets. This topic provides
instructions for working with OData and ALM Octane.
In this topic:
l "Overview" below
l "Supported OData versions" on the next page
l "The ALM Octane server base URI" on the next page
l "Authenticating" on the next page
l "Accessing ALM Octane data from a reporting or BI tool" on page 454
l "Scenario: A template for ALM Octane OData and Power BI" on page 454
l "Scenario: A template for ALM Octane OData and Power BI" on page 454
Overview
This overview describes the use cases for using the OData standard to access ALM Octane.
You can retrieve ALM Octane data over OData with reporting and business intelligence tools.
You can use these reporting and business intelligence tools that support OData (such as Power
BI) to generate reports and charts, instead of relying only on ALM Octane dashboard widgets.
Connect to ALM Octane's OData support from the application's interface.

Supported OData versions

ALM Octane supports OData version 2.0.
Any tool that supports OData version 2.0 is likely to work well with ALM Octane.
ALM Octane OData support has been tested with Power BI and Excel.
Prerequisites
Request that the site admin or the space admin activate basic authentication with the SUPPORTS_
BASIC_AUTHENTICATION configuration parameter for each space. For details, see "SUPPORTS_
BASIC_AUTHENTICATION" on page 501.
The ALM Octane server base URI

The ALM Octane server base URI for accessing ALM Octane data using OData is:
<https://server>/odata/v2/shared_spaces/<space_ID>/workspaces/<workspace_ID>/
Troubleshooting: If ALM Octane does not respond successfully to an OData consumer request, it
might be because the base URL used to refer to ALM Octane is different than expected. Consider
modifying ODATA_USE_SERVER_BASE_URL and SERVER_BASE_URL as described under
"Configuration parameters" on page 480.
Authenticating
To work with OData, review the prerequisites for basic authentication under "Prerequisites"
above, and then authenticate with basic authentication.
Caution: Activating basic authentication enables external systems to access ALM Octane
using this authentication method, not just OData.
You can authenticate with either:

l Your user name and password.
l An API access key.
For details, see the information about basic authentication in the Developer Help.
Tip: When working with basic authentication, on each successful authentication, ALM
Octane includes the LWSSO_COOKIE_KEY cookie in the response. We recommend that you
send the LWSSO_COOKIE_KEY cookie with each subsequent OData request for enhanced
performance. For details, see the information about the LWSSO_COOKIE_KEY in the

Developer Help.
Accessing ALM Octane data from a reporting or BI tool

Any reporting or business intelligence tool with OData support can integrate with ALM Octane,
including Excel 2010 and later, Power BI, Power Query for Excel, and Power Pivot for Excel.
For a list of many of the tools that support OData, go to http://www.odata.org/ecosystem/ and
click Consumers on the left.
Example of how to access ALM Octane using Power BI

1. Choose Home > Get Data > OData Feed.
2. Enter the ALM Octane server base URI and click OK.
3. Under Basic, enter the ALM Octane user name and password.
Now you can see all ALM Octane entities in the Navigator.
Example of how to access ALM Octane using Excel

1. Choose DATA > From Other Sources > From OData Data Feed.
2. Enter the ALM Octane server base URI and click OK.
3. Select Use this name and password and enter the information.
Now you can see all ALM Octane entities.
Scenario: A template for ALM Octane OData and Power BI

For a Power BI template that you can deploy and import, see
https://marketplace.microfocus.com/appdelivery/content/power-bi-desktop-template-for-
octane-odata.
Scenario: A traceability report with ALM Octane OData and Power

BI
This example demonstrates how to use Power BI to access ALM Octane data using OData. It
shows, step by step, how to create a traceability report.
1. In Power BI, set up the data feed for ALM Octane with OData. For details, see "Example of
how to access ALM Octane using Power BI" above.

Set up a basic feed using the ALM Octane URI.

Enter the user name and password for basic authentication and click Connect.
2. Now we have connected and can see all ALM Octane entities. Let's start creating our report.
To see only stories, click on stories and then Edit.

We now select the columns we want to see. Click Choose Columns.

For our report, let's select the ID, name, release, and tests columns.

Releases and tests are references to other entities. We can get more information about releases
and tests by clicking on the right button for each column to expand them.
Click the button for the release. We would like the name of the release, so we select name.
Similarly, click the button for tests, and then select the name and ID attributes.
Let's filter for items in release 2.2.

Click Close & Apply. Here is the result so far.
Now we will create the graph with data we select.

From the right pane:
l Select the values.
l Select matrix visualizations.
l Arrange the rows, columns and values.

We can also add the pie chart visualization.

Save and refresh the data.

See also:
l Information about OData in the Developer Help

Configuration
Perform administrative setup tasks for your site, spaces, workspaces, teams, and releases.
To view configuration pages, click Settings to open the configuration area of ALM Octane.
This area is available to administrators only.
With shared spaces, you can manage multiple projects or products, and apply common settings to
all workspaces, such as rules and users.
Administrators can switch between workspaces to which they are assigned.
In this topic:
• Installation guides 465
• Initial setup 465
• Log in to Settings 465
• Set preferences 465
• Learn about spaces and workspaces 466
• The configuration flow 466
• Site configuration (on-premises) 467
• Administer the site (on-premises) 468
• Manage licenses (on-premises) 474
• Set configuration parameters (technical preview) 479
• Set up LDAP (on-premises) 502
• Change passwords 511
• Space configuration 513
• Manage spaces 514
• Manage workspaces 519
• Manage users 524
• Assign roles and permissions 529
• Set up a release 535
• Manage teams 540
• Design forms 543
• Customize fields 547
• Set up lists 553
• Set up workflow phases and transitions 557
• Set up rules 568

Installation guides
Installation guides
This section lists available installation guides for ALM Octane. Printer-friendly documentation is
available for each guide in Adobe portable document format (PDF).
Link Last Updated

Installation Guide for Linux (12.60.4) 27 July 2018
Installation Guide for Microsoft Windows (12.60.4) 27 July 2018
Synchronizer Installation Guide (on-premises) (12.60.4) 27 July 2018
Initial setup
This topic describes the flow and tasks for initially setting up and configuring ALM Octane. Most
setup and administrative tasks are done in the Settings area of ALM Octane.
Some topics are relevant only for on-premises.
In this topic:
l "Log in to Settings" below
l "Set preferences" below
l "Learn about spaces and workspaces" on the next page
l "The configuration flow" on the next page
Log in to Settings
To configure, log into the Settings area.
Admin permissions are required (site admin, workspace admin, space admin, and so on).
In the top banner, click Settings .

Then select the area to configure:
l Site. Site settings (on-premises).
l Spaces. Space and workspace settings.
Set preferences
You can set preferences using the Settings drop-down menu.

Initial setup
In the top banner, click Settings . Then toggle on/off preferences:

l Email me when I am mentioned in a comment. Enables ALM Octane to send you a notification
via email when someone tags you in a comment with the @ character.
l Use Sprinter to run manual tests. Enables ALM Octane to run manual tests in Sprinter rather
than in the Manual Runner. For details see "Run and edit manual tests in Sprinter" on page 256.
Learn about spaces and workspaces

Data in ALM Octane is divided into separate areas within a larger environment. The separate areas
are called workspaces. The environment is called the space. The spaces can be isolated or shared.
Workspaces associated with shared spaces can share data.
Shared space admins Workspace admins Workspace members

Can create multiple Can manage data inside their Can only access workspaces that
workspaces to workspaces that are associated they are assigned to.
represent multiple with isolated spaces. This
All users are automatically
projects, programs, or includes releases, teams, users,
assigned basic access privileges
products managed on the backlog, application modules,
within the default workspace. To
the same ALM Octane tests, defects, and so on.
learn more about users and their
site.
roles, see "Assign roles and
Can also add users, permissions" on page 529.
and assign users
different roles within
workspaces. They also
assign workspace
admins for each
workspace.
The configuration flow

The flow for configuration is provided here.
Some topics are relevant only for on-premises.

Site configuration (on-premises)
Before users can work effectively in the product, we recommend that admins create and configure
the following:
l Spaces and workspaces.
On-premises: For on-premises, the site admin creates spaces that will be containers for all the
workspaces in your environment. Spaces can be isolated or shared. For details, see "Create
spaces for a site" on page 471.
Then, for both on-premises and SaaS, the space admin creates workspaces that will be
containers for all the items that define your environment:
l Put workspaces that will share data in the same shared space.
l Put workspaces that will not share data in an isolated space.

For details, see "Manage spaces" on page 514.
l Other items. Set up your releases, teams, users, and so on. These items are the building blocks
that help define how users work in ALM Octane.
Define items that workspaces will share, such as releases, in their associated shared space.
Define non-shared items in the relevant workspaces.
l Rules. After defining the items above, configure how the ALM Octane user interface works, and
control the actions users can perform.
Next steps:
l "Site configuration (on-premises)" below
l "Space configuration" on page 513

This section provides instructions that site admins can use to configure the site.

Topic Description
"Administer the site (on- Instructions for managing the overall site, such as ALM
premises)" below Octane database servers, mail servers, and logs.
"Manage licenses (on-premises)" How to manage your ALM Octane licenses.

on page 474
"Set configuration parameters How admins can set configuration parameters for the site
(technical preview)" on page 479 and spaces.
"Set up LDAP (on-premises)" on Instructions for managing and authenticating ALM

page 502 Octane users using your organization's LDAP system.
"Change passwords" on page 511 How all users can change their passwords, or have an
administrator change their passwords for them.
Administer the site (on-premises)

Here are instructions for managing the overall site, such as ALM Octane database servers, mail
servers, and logs. This context is also for adding spaces and reviewing the history of modifications
to spaces. On-premises site admins can manage the site from the Site area in Settings.
l "About the site" below
l "Manage servers" below
l "Manage users at the site level" on the next page
l "Manage spaces at the site level" on page 471
l "Set configuration parameters " on page 473
l "View sessions" on page 473
About the site

Site administration includes tasks such as managing ALM Octane database servers, mail servers,
and logs.
The site context is also for adding spaces and reviewing the history of modifications to spaces.
On-premises site admins can manage the site from the Site area in Settings.
Manage servers
You can perform the following server management actions in Settings .
Click Site and then click the Servers tab.

Task How to
Refresh the status of the Click the relevant server, and then click .
servers to test
connectivity.
Change log details. In the Application Logs area, click the log file name, change the
Level and Max Size, and click Save.
l Path
The path of the log file. (Read only)
The log is written to the relevant log file in the specified path,
according to the context in which you are working.
Example: When you are working in the context of the main ALM
Octane application, the log is written to the app.log file located
in Path.
l Level
Determines the severity of the events to include in the log.
Valid values are: Fatal, Error, Warn, Info, Debug, Trace.
Note: If you change the log level to Debug, make sure to change
it back when you are finished debugging.
l Max Size
When the log size reaches this maximum size in MB, a new log
file opens.
Change the database In the Database Servers area, click the server name, change the
admin password. Admin password, and click Save.
Change the mail server In the Mail Servers are, click the server name, change the Host
host name and port. name and Port, and click Save.
Manage users at the site level

Site admins can delete, activate, and deactivate users from the Site area in Settings. They can also
assign other users the site admin role.
Space admins and workspace admins can also activate and deactivate users For details, see
"Activate or deactivate a user" on page 528.
Assign the site admin role to existing users

1. In Settings , click Site.
2. In the Users tab grid view, select the user who should also be a site admin.

3. Click to display the Roles column.

4. Select Site Admin in the Roles column for that user.
Delete a user
Note: Before deleting in ALM Octane, SaaS operators should delete the user from the
system before deleting the user in ALM Octane.
1. In Settings , click Site.

2. In the Users grid, select a user.
3. In the toolbar, click and answer Yes to confirm.

4. On-premises: If your site is configured to erase all traces of the deleted user, the following
appears.
Limitation: The ability to erase all traces of deleted users is not supported for SaaS.
We strongly recommend that you manage an external file that maps deleted ALM Octane
users to reference codes.
Enter a reference code for the user from this external file.
Internally, references to the user are replaced by this reference code in ALM Octane.
If you do not enter a reference code, the user is not deleted.
For details on how to configure the site to erase deleted users' details, see the FORGET_
USER_ON_DELETE configuration parameter under "LOGIN_PAGE_NOTICE " on page 494.
Note that setting the value for this parameter only affects how users are deleted from this

point forward. Setting this parameter to true does not erase the details of already-deleted
users.
Tip: You can also delete multiple users using the REST API. For details, see the Developer
Help.
Manage spaces at the site level

Site admins can view, add, and upgrade spaces (including monitoring background jobs) from the
Site area in Settings.
For details about how the space admin manages spaces, see "Manage spaces" on page 514.
View spaces for a site

In Settings , select Site. See a list of spaces at the site, and select one to see its details.
Icons indicate if the space is shared or isolated .

While looking at the details, you can also see the history of changes made to the space. For details,
see "View an item's history" on page 93.
Create spaces for a site

1. In Settings , select Site.
To create a shared space, click .
To create an isolated space, click .

2. Name the space.
3. If the database at your site is managed by database administrators, and ALM Octane is not
authorized to create its own schemas, check Use existing schema. Enter the name of the
existing space schema to use, and its password.
Tip: You can create exception files to list any warnings to ignore when ALM Octane
creates spaces using an existing schema. This is useful if the DBA manually added
objects, such as tables, indexes, and so on, to the database schema. For details, see
Using exception files for manual database changes.
4. Create workspaces and associate them with the space. For details, see "Manage workspaces"
on page 519.

Edit space admins

Add or remove space admins.
1. In Settings , click Site, and then click the Spaces tab.

2. In the Administrators column, click in the cell of the space you want to edit.
3. From the list, select or remove admins for this space.
Upgrade spaces
After upgrading from a previous ALM Octane version, check if any spaces must be upgraded.
Upgrade these spaces using the instructions below.
1. In Settings , click Site, and then click the Spaces tab.

2. Select spaces and click Upgrade.
Upgrade is available only if a space needs to be upgraded.
Click Refresh to see the updated status for the spaces.
3. Review the statuses of the spaces.
Active, The space retained its state from before the upgrade.
Inactive No action necessary.
Upgrading The space is waiting to be sent for upgrade but the upgrade has not yet
started. When the upgrade is actually in progress, the current step being
processed is displayed. See the status "Step # of #" below.
The number of spaces that can be upgraded concurrently is limited.
No action necessary.
Step # of # As the upgrade progresses, the current step and operation are displayed.
No action necessary.
Suspended A recoverable error occurred.

Review the error and the logs. Display the Recovery guidelines field, and
follow the instructions. Restart the upgrade.
Corrupted An unrecoverable error occurred.

Restore schemas from the previous version. For details, see the ALM Octane
Installation Guide.
4. The workspace name is a unique identifier within a space. ALM Octane adds a numeric suffix
(_1, _2, and so on) to any upgraded workspaces with the same name. If necessary, ALM
Octane truncates the last characters from workspace names longer than 255 characters

before adding the suffix.

After upgrading, review the names of the workspaces. You can rename them if you want.
See a space's background jobs

Background jobs include processes that run after upgrading a space, among other activities. A
space is only fully upgraded after all background jobs have completed. Check periodically to see
when an upgraded space is ready.
1. In Settings , click Site and then click the Spaces tab.

2. Select the shared space and click Background Jobs.
Note: Until all of the background jobs have completed, some data may be unavailable in
trend graphs.
Set configuration parameters

Site admins and space admins can set configuration parameters, such as parameters for setting
the language, determining from where the Help Center opens, activating basic authentication, and
so on:
l In Settings (technical preview)
For details, see "Set configuration parameters (technical preview)" on page 479.
l Using the REST API
For details, see Setting configuration parameters in the Developer Help.
View sessions
You can see information about each session that logged into ALM Octane. This includes:
l The user ID that logged in
l The type of access for the session (UI, API user, or API key)
l The IP address used for the session
l The duration of the session
To view sessions, click Site and then click the Servers tab.
See also:
l "Set configuration parameters (technical preview)" on page 479

l The information about setting configuration parameters using the REST API in the Developer
Help
Manage licenses (on-premises)

This section describes how to manage your ALM Octane licenses.
In this topic:
l "License modes: Standalone or shared" below

l "License types: Named or concurrent" below
l "Install a standalone license" on the next page
l "View license and session details" on page 476
l "Calculate license usage" on page 476
l "Share licenses with ALM or Quality Center" on page 477
License modes: Standalone or shared

You can work with licenses in the following ways:
l Standalone mode. For standalone mode, you install a license directly in ALM Octane, as
described in "Install a standalone license" on the next page.
l Shared license mode. For shared license mode, you allocate licenses from ALM or Quality
Center for use in ALM Octane, as described in "Share licenses with ALM or Quality Center" on
page 477.
You define your license mode during installation. By default, ALM Octane is set to work in
standalone mode.
License types: Named or concurrent

There are two types of licenses in ALM Octane:
l Named. This defines how many users you can register in ALM Octane.
l Concurrent. This defines how many users can access the system at the same time.
ALM Octane does not allow you to work with mixed licenses. You can either use named licenses,
or concurrent licenses. Note that license sharing with ALM or Quality Center is for concurrent
licenses only.
An active license is released when a user logs out of a session, or after the session timeout (by
default, 3 hours). If there are no available licenses, a user trying to log in receives an error
message.

Working with named licenses:

l To view details on your license capacity, access Settings > Site > Users. On the top right you will
see how many licenses are in use, and how many are still available.
l If you need to deactivate a user to release a license, the site admin should deactivate the user at
the site level. If you deactivate a user at the shared space or workspace level, their license is not
released.
Working with concurrent licenses:

l In the concurrent model, license consumption is per user, and per machine. When a user opens
multiple sessions on a single machine, one license is consumed. When a user opens sessions on
different machines, multiple licenses are consumed.
l For details on how to view information regarding usage, see "Calculate license usage" on the
next page.
Switching between license types:

l You can switch from a named license to a concurrent license without limitation.
l If you need to switch from a concurrent license to a named license, the number of active users
must be within the named license capacity limits.
You switch modes when the site admin installs a new license of the other type (for example named
instead of concurrent).
Install a standalone license
To install a standalone license:

1. Access Settings > Site > Licenses.
2. Click Install License, browse to the license file that you received from Micro Focus, and click
Install .
To switch from sharing to standalone mode:

If you were previously sharing licenses with ALM or Quality Center and you now want to work in
standalone mode, you need to edit the octane.yml file.
1. Open the /opt/octane/conf/octane.yml configuration file (in Windows:
C:\octane\conf\octane.yml) and locate the license section.
2. Change the value of mode to standalone.

For details on how to work with the octane.yml file, refer to the ALM Octane Installation Guide .
View license and session details

l To view details on your active license edition, access Settings > Site > Licenses.
l To view details on active sessions, access Settings > Site > Sessions.

Details include the user ID that logged in, the type of access (UI, API user, or API key), the
IP address used for the session, the start and end time of the session, and the license edition.
Calculate license usage

You can export data on sessions to Excel, and then generate graphs tracking license usage based
on sessions.
1. Access Settings > Site > Sessions.
2. Make sure all the columns are visible, and in their default order:
3. Filter Access Type by USER_UI_ACCESS.

4. Sort by Start Time to show the least recent start time on top.
5. Click the Export to Excel button .

6. Open the Excel file, and add a column to the right of the License Edition column named
Active Sessions. Your header row should now look like this:

7. In cell I2, directly under the heading Active Sessions, paste the following formula:
=COUNTIFS(G$2:G2, ">="&A2)+COUNTBLANK( G$2:G2)
The Active Sessions column now shows the number of sessions that are active at every given
session start time.
Note: In this formula, column A represents Start time and column G represents End
time. The formula assumes that you have followed the previous steps, and now have
all the columns as displayed above. If you change the order of the columns or remove
columns, you need an understanding of Excel to modify the formula accordingly. For
example, if you move Start time to column F, you would change the formula to
=COUNTIFS(G$2:G2, ">="&F2)+COUNTBLANK( G$2:G2)
8. Select the Start time and Active Sessions columns, using Ctrl-click for multiple selection.
9. In the Excel toolbar, select Insert > Recommended Charts. Generate one of the following
graphs: Scatter with smooth lines for ongoing data, or Clustered Bar Chart to see maximum
usage per day. Here's an example of a scatter chart:
Share licenses with ALM or Quality Center

You can allocate licenses from ALM Edition or Quality Center Enterprise Edition to ALM Octane.
After allocating licenses you can change the allocation dynamically. If you need more licenses in
ALM Octane, you can allocate more from ALM or Quality Center. If you need fewer in ALM
Octane, you can reduce the number of licenses allocated.
License sharing is supported for concurrent licenses only.
Supported ALM, QC, and ALM Octane editions

For details on supported ALM and QC versions, see "Installation, setup, and synchronization" on
page 61.
You can allocate licenses as follows:

l ALM (ALM.Net) Edition to ALM Octane Enterprise Edition

l Quality Center (QC) Enterprise Edition to ALM Octane Pro Edition
For details about Enterprise and Pro capabilities, see "ALM Octane editions" on page 53.
Step 1: Perform the following in ALM or QC site administration:

1. Define an integration user and password to be used for the license integration. You can
either create a new user, or use an existing integration user. The user must have Viewer
permissions.
2. Create a dedicated project which will be used for the integration only.
3. Assign the above user to this project.
4. Define a new site parameter: OCTANE_INTEGRATION_PROJECT_NAME. Assign the value:
<domain name>/<project name>.
5. Allocate a number of ALM or QC full licenses to the project:
a. In the Licenses > License Assignments tab, locate the integration project.
At the bottom of the tab you can see how many licenses are available, which means the
number of licenses that are not yet assigned to a project.
b. In the Full License column, type the number of licenses you want to allocate from ALM or
QC to ALM Octane, and click Save.
The license allocation is done out of the available quota in the licenses pool.
Note: To enable license sharing, you need to set up a connection between the ALM Octane
server and the ALM or QC server. If there is a Forward proxy server between the systems
that requires authentication, license sharing cannot be configured.
Step 2: Define the following in the ALM Octane octane.yml file:

1. Open the /opt/octane/conf/octane.yml configuration file (in Windows:
C:\octane\conf\octane.yml) and locate the license section. Change the value of mode to
almSharing.
For details on how to work with the octane.yml file, refer to the ALM Octane Installation
Guide.
2. In the almSharing section, define the following:

l url . Enter the full path that you use to access ALM or QC .
l almIntegrationUser. Enter the user that you defined in ALM or QC for the integration.
l almIntegrationPassword. Enter the password for the above user. This password is
automatically encrypted after you restart the ALM Octane server.
Note: If you are using an LDAP user in ALM or QC whose password changes
periodically, you will need to regularly update the password here to maintain
license sharing.
3. Restart ALM Octane. ALM Octane is now updated with the allocated licenses.
If there is a connectivity problem such as network issues or changes to user or password, an email
is sent to the ALM Octane administrator describing the problem. Details are written to site.log.
Users will be able to log in to ALM Octane for a limited time, enabling you to fix the problem
before access is blocked.
If you add licenses to the designated project in ALM or QC , ALM Octane can take up to 3 hours
to update the license allocation.
See also:
l "ALM Octane editions" on page 53
Set configuration parameters (technical preview)

Site and space admins can set configuration parameters that determine how ALM Octane works.
l "Overview" below
l "How to set configuration parameters" on the next page
Overview
Admins can set configuration parameters from the Site and Spaces areas in Settings.
Tip: Admins can also set configuration parameters using the REST API. For details, see
the information about setting configuration parameters in the Developer Help.
For a comprehensive list of all publicly-available configuration parameters, see "Configuration

parameters" on the next page.
Admins only see the parameters that are relevant for them. For example, space admins can only
see the space-level parameters that they have the ability to change. There may be other space-
level parameters that only the site admin can change.

The following table shows which types of parameters admins can configure.
Admin Site parameters Space parameters

Space admin (on-premises)
Space admin (SaaS) Open a support ticket
Site admin (on-premises)
The values of parameters set on the space level override the values of the same parameters set at
the site level. For example, if a site admin sets a site-level parameter called DEFAULT_LANGUAGE
to lang.en for English, and the space admin changes the same DEFAULT_LANGUAGE parameter
on the site level to lang.de, the default language for the space will be English while the rest of the
site will be in German.
How to set configuration parameters

Admins can set configuration parameter values.
1. In Settings, click Site or Spaces, and then click the Parameters tab.
2. If you clicked Site, choose the level at which you want to configure parameters. You can
choose Site, or select a specific space.
3. Locate the parameter you want to set.
Use the search box at the top of the grid to find a parameter.
4. Change the value.
5. For each configuration parameter you set, click Save.
6. Changes to configuration parameters may require that you refresh Settings. Click Refresh.
See also:
l "Configuration parameters" below
l Setting configuration parameters in the Developer Help.
Configuration parameters
This reference contains all publicly-available configuration parameters, including configuration
parameters for the site and spaces.
To set configuration parameters:
l In Settings: See "Set configuration parameters (technical preview)" on the previous page.
l With the REST API: Setting configuration parameters in the Developer Help.

* Unless otherwise indicated, the configuration parameter is customizable on the site level only, and not per
space. *
Configuration parameter Description
ALLOW_HTTP_METHOD_ Enables override method through HTTP header. This is not enabled for
OVERRIDE GET requests.
Type: boolean
Default: false
ALLOW_WORKSPACE_USERS_ Enables or prevents the workspace admin from doing the following, using
CREATION both the ALM Octane UI and from the REST API:
l Add workspace users.

l Import LDAP users at workspace level.
l Include users from the space level into the workspace.
Type: boolean
Default: true
ATTACHMENTS_FILE_ Defines a list of prohibited extensions for file types for ALM Octane
EXTENSION_BLACK_LIST attachments.
After saving this parameter, any extensions listed in this value are
removed from the list of permitted extensions in the ATTACHMENTS_
FILE_EXTENSION_WHITE_LIST configuration parameter. The extensions
are removed for the entire site and all spaces.
Separate each extension with a semi-colon (;).
Type: string
Default:
empty

space. *
ATTACHMENTS_FILE_ Defines a list of the permitted extensions for file types for ALM Octane
EXTENSION_WHITE_LIST attachments.
To permit all attachments, regardless of file extension, enter an * (asterisk).

For security purposes, this is not recommended.
You cannot add extensions that are prohibited, as specified in the

ATTACHMENTS_FILE_EXTENSION_BLACK_LIST configuration parameter.
Note: You can also add additional, custom file extensions to the list of
permitted extensions for ALM Octane attachments. The file types (mime
types) must be one of ALM Octane's supported mime types, but you can
choose any extension you like. For details, see the EXTENSION_TO_MIME_
TYPE configuration parameter.
Type: string
Default:
ngalink; links;
jpg; bmp; png;
pdf; word; doc;
docx; msg; xml;
xls; xlsx; ppt;
pptx; zip; txt;
wmv; mp4; m4p;
mkv; vob; log;
wrf; fbr; jpeg
Customizable for: Both site and space
ATTACHMENTS_URL_DOMAIN_ Defines a list of the permitted domains for ALM Octane attachment URLs.
WHITE_LIST
Used only if ATTACHMENTS_URL_ENABLE_DOMAIN_WHITE_LIST is set
to true.
Type: string

space. *
ATTACHMENTS_URL_ENABLE_ Enables or disables usage of the domain white list validation of attachment
DOMAIN_WHITE_LIST URL, as enabled as defined with ATTACHMENTS_URL_DOMAIN_WHITE_
LIST.
Type: boolean
Default: false
AUDIT_LOG_FILE_MAX_SIZE Defines the maximum size (in KB) of each audit log file.
Type: integer
Default: 10240
Minimum: 1024
Maximum: 102400
AUDIT_LOG_FILE_ROLLING_SIZE Defines the number of audit log files that are retained.
Type: integer
Default: 10
Minimum: 10
Maximum: 100
AUTHENTICATION_DELAY_ On-premises: Sets whether user login attempts are monitored for
ACTIVE suspicious activity. By setting this, the AUTHENTICATION_DELAY_
SECONDS, and the AUTHENTICATION_MAX_ATTEMPTS site
configuration parameters, you can control if ALM Octane ignores or
prevents suspicious login attempts.
For details on how ALM Octane handled login attempts, see the audit log.
Type: boolean
Default: true

space. *
AUTHENTICATION_DELAY_ On-premises: If AUTHENTICATION_DELAY_ACTIVE is set to true, the

SECONDS number of seconds after which ALM Octane stops checking entered login
credentials. The counts starts after the first failed login attempt. After the
number of seconds has lapsed, ALM Octane starts to check login
credentials again.
After setting this site configuration parameter, restart the ALM Octane
server.
Type: integer
Default: 15 seconds
AUTHENTICATION_MAX_ On-premises: If AUTHENTICATION_DELAY_ACTIVE is set to true, the

ATTEMPTS number of attempts after which ALM Octane locks out the user trying to
log in.
Type: integer
Default: 3
CLUSTERING_MAX_TESTS_ Defines the number to be used as a threshold for test clustering analysis.
THRESHOLD For example, if this parameter is set to 200, and more than 200 tests fail
for a pipeline run, ALM Octane does not analyze clustering.
Type: integer
Default: 200
Minimum: 0
Maximum: 50000
DEFAULT_GET_PAGE_SIZE The default number of items to return.
Type: integer
Default: 1000
Maximum: 10000

space. *
DEFAULT_LANGUAGE The default language for the site or the shared space.
Type: string
Default: lang.en
Values:
English: lang.en
French: lang.fr
German: lang.de
Japanese: lang.jpn
Russian: lang.ru
Simplified Chinese: lang.chs
Spanish: lang.esp
Note: These are the values are currently supported. Support for some of
these languages may be discontinued, and support for others might be
added.
ENABLE_AUDIT Defines whether the audit log is used.
Type: boolean
Default: true
ENABLE_LEGACY_TECH_ Defines whether the REST API still accepts the HPE_REST_API_TECH_

PREVIEW_CLIENT_TYPE PREVIEW value for the HPECLIENTTYPE request header. This request
header is used for working with REST API resources that are a technical
preview.
Use the ALM_OCTANE_TECH_PREVIEW value instead, because the HPE_

REST_API_TECH_PREVIEW value will soon be deprecated.
Type: boolean
Default: true
ENABLE_OUTPUT_ Defines whether to sanitize the REST output.

SANITIZATION
Type: boolean
Default: true

space. *
ENABLE_SPRINTER_USAGE Defines whether users see the toggle switch in Settings, which enables
them to use Sprinter to run manual tests.
Type: boolean
Default: true
ENABLE_STORAGE_ MAX_SIZE_ Defines whether the maximum size for storage of files should be validated.
VALIDATION
Type: boolean
Default: true
EXTENSION_TO_MIME_TYPE Enables site admins to add additional, custom file extensions to the list of
permitted extensions for ALM Octane attachments, as defined with
configuration parameter "ATTACHMENTS_FILE_EXTENSION_WHITE_
LIST" on page 482.
The file types (mime types) must be one of ALM Octane's supported mime
types, but you can choose any extension you like.
Note: ALM Octane supports all mime types defined as valid by Apache

Tika:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tika/tika-
core/0.6/org/apache/tika/mime/tika-mimetypes.xml
The value of this parameter is one or more mappings between a custom

file extension and its mime type.
Format: <custom_extension>=text/plain [, <another_custom_

extension>=text/plain]
Separate each mapping with a semi-colon (;).
To bypass the validation of if an attachment's mime type matches the file

extension, enter the string value false. For security purposes, this is not
recommended.
Type: string
Example:
ext1=text/plain;
ext2=text/plain

space. *
EXTERNAL_HELP_URL Whether the ALM Octane Help Center opens on the cloud or on the local
server.
l true. The help center opens externally, at this location:

https://admhelp.microfocus.com/octane/
l false or blank. The help center opens on the local server. Use this
option only if users do not have internet access. For details, see
Download Help Center.
Type: boolean
Default: true
FILE_EXTENSION_WHITE_LIST_ File extensions that are allowed to be downloaded via open attachments,
DOWNLOAD the REST API, or FTP Explorer.
Type: string
Default: txt;doc;docx
FAILURE_ANALYSIS_INSIGHT_ Defines the percentage of failed tests above which the tests and their
TEST_FAILURE_THRESHOLD corresponding builds are displayed as failure analysis insight cards for a
specific pipeline.
This threshold is relevant only for quality insight issues, such as “QUALITY
- Committers related to most test failures” and “QUALITY – Builds with
most failed tests.”
Type: integer
Default: 20
Minimum: 0
Maximum: 100
FILE_EXTENSION_WHITE_LIST_ File extensions that are allowed to be uploaded via open attachments,
UPLOAD extended storage, the REST API, or FTP Explorer.
Type: string
Default: txt;doc;docx

space. *
FORGET_USER_ON_DELETE Determines if ALM Octane should erase all user details when a user is
deleted, from this point forward. Internally, a user-specified reference code
is used as a substitute for the details.
After modifying this parameter, make sure to reload ALM Octane Settings
before deleting users.
Setting this parameter does not impact users already deleted.
Type: boolean
Default: false
FORTIFY_POLLING_DELAY_ Sets the interval for checking if Fortify on Demand has finished scanning
MINUTES (in minutes).
Type: integer
Default: 2
FORTIFY_POLLING_ TIMEOUT_ Determines when ALM Octane should stop checking to see if Fortify on
HOURS Demand has finished scanning (in hours).
Type: integer
Default: 48
FORTIFY_UPPER_LIMIT_OF_ Sets how many issues ALM Octane should retrieve from Fortify on Demand.
ISSUES
Type: integer
Default 100
Maximum: 500

space. *
GDPR_NOTICE_BODY Defines the terms for personal data processing to display in a dialog box
when first-time users log in to ALM Octane.
The terms are only displayed if the GDPR_REQUIRE_USER_CONSENT

configuration parameter is true.
Basic html text is supported.
The text cannot exceed 1000 characters, so for long notices, use a link to a
different page. When linking to another page, we recommend you use the
target="_blank" attribute to open the notice in a different window.
Tip: You can set a title for the dialog box using the GDPR_NOTICE_TITLE
configuration parameter.
Type: string
Default: blank
Maximum number of characters: 1000
Examples:
l Welcome to ThisCompany. Only authorized users allowed.
l Welcome to ThisCompany. See <a
href="https://www.thiscompany.com" target="_blank" > my
terms.</a> By logging in, you are acknowledging these terms and
signifying your acceptance and willingness to use this product
accordingly.
GDPR_NOTICE_TITLE Defines the title of the dialog box that displays the terms for personal data
processing when first-time users log in to ALM Octane.
The title is only displayed if the GDPR_REQUIRE_USER_CONSENT

parameter is true.
Type: string
Default: blank

space. *
GDPR_REQUIRE_USER_CONSENT Determines if consent is required for first-time users logging in to ALM

Octane. Terms of data usage are defined using the GDPR_NOTICE_
TITLE and GDPR_NOTICE_BODY configuration parameters.
If the user does not consent, the user cannot log in.
If the user does consent, the date and time of the consent is stored in the
user's GDPR consent time field at the site level.
Type: boolean
Default: false
IMPORT_TESTS_FUSE Defines the maximum number of tests that can be imported in one import
operation.
Type: integer
Default: 300
IMPORT_WORK_ITEMS_FUSE Defines the maximum number of work items (epics, features, stories,
defects) that can be imported in one import operation.
Type: integer
Default: 1000
LIST_NODE_CHILDREN_ Defines the maximum number of values that can be added to a user-
AMOUNT_PARAM_ID defined list.
Default: 150

space. *
LOG_APPENDER_MAX_SIZE Defines the maximum size for each Apache Log4j appender (in MB).
The format is:
<log>Appender=#;<log>Appender=#;<log>Appender=#
Where:
l appAppender is the name for the ALM Octane UI log.

l siteAppender is the name for the ALM Octane SiteAdmin and
SharedSpace admin log.
l restAppender is the name for the ALM Octane REST API log.
Each log setting is separated by a semi-colon (;).
Types:
l string for the list of log appenders
l integer for each log size
Example:
appAppender=16;
siteAppender=20;
restAppender=11
Minimum size for each log: 1

Maximum size for each log: 100

space. *
LOG_LEVEL Changes the log level for specific log files.
The format is:
<log_file>=<level>; <log_file>=<level>
Types:
l string for the list of logs
l string for each level
Example:
com.hp.mqm.dal=DEBUG;
com.hp.mqm.test=WARN
Valid values for log levels:

l DEBUG
l WARN
l INFO
l WARN
l FATAL
l ERROR
l TRACE

space. *
LOG_ROOT_LEVEL Changes the log level for specific Apache Log4j appenders.
The format is:
<log>Appender=<level>;<log>Appender=<level>;<log>Appender=<level>
Where:
l appAppender is the name for the ALM Octane UI log.

l siteAppender is the name for the ALM Octane Settings log.
l restAppender is the name for the ALM Octane REST API log.
Types:
l string for the list of logs
l string for each level
Example:
appAppender=WARN;
siteAppender=ERROR;
restAppender=TRACE
Valid values for log levels:

l DEBUG
l WARN
l INFO
l WARN
l FATAL
l ERROR
l TRACE

space. *
LOGIN_PAGE_NOTICE On-premises: Sets html text to display at the bottom of the Login page
under the Login button.
Basic html text is supported.
The text cannot exceed 1000 characters, so for long notices, use a link to a
different page.
When linking to another page, we recommend you use the target="_

blank" attribute to open the notice in a different window.
Type: string
Default: blank
Examples:
l Welcome to ThisCompany. Only authorized users allowed.
l Welcome to ThisCompany. See <a
href="https://www.thiscompany.com" target="_blank" > my
terms.</a> By logging in, you are acknowledging these terms and
signifying your acceptance and willingness to use this product
accordingly.
LOGO_TEXT Sets the text to display at the top left of ALM Octane, such as the company
name.
Unicode emojis are supported.
This parameter can be set both at the site level and at the shared space
level. The shared space level parameter overrides the value set at the site
level.
Type: string
Default: ALM OCTANE

space. *
MAIL_ATTACH_MAX_SIZE Sets the maximum file size (in KB) for attachments to mail sent from ALM
Octane.
Type: integer
Default: 10485760
Minimum: 10240
Maximum: 10485760
MAIL_ATTACH_TOTAL_MAX_ Sets the total maximum file size (in KB) for all attachments to mail sent
SIZE from ALM Octane.
Type: integer
Default: 10485760
Minimum: 10240
Maximum: 10485760
MAIL_FOOTER Defines the footer (rich text) for emails. Can be blank.
Type: string
MAIL_FORMAT Defines the format that mails are sent in.
Type: string
Default: HTML
Valid values:
l HTML
l TEXT
MAIL_HEADER Defines the header (rich text) for emails. Can be blank.
Type: string
MAIL_MESSAGE_CHARSET The characters set for sent emails.
Type: string
Default: UTF-8

space. *
MAIL_PROTOCOL The mail protocol.
Type: string
Default: smtp
MAIL_SERVER_HOST The mail server host.
You can also set the host in the ALM Octane UI: Settings > Site > Servers
tab.
Type: string
MAIL_SERVER_PORT The mail server port.
You can also set the port in the ALM Octane UI: Settings > Site > Servers
tab.
Type: integer
Default: 25
MAX_ ACTIVE_USERS_PER_ The maximum number of active users per shared space.
SHAREDSPACE
Type: integer
Default: 1000
MAX_ATTACHMENT_COUNT_ The maximum number of attachments that can be added to any one
PER_ENTITY entity.
Note that in some cases, the specified number of attachments may be

marginally exceeded, for example when multiple uploads are processed
simultaneously.
Type: integer
Default: 30
MAX_CARDS_TO_DISPLAY The maximum number of cards to display in the Board view of the board.
Type: integer
Default: 200

space. *
MAX_PAGE_SIZE The maximum number of items that can be returned.
Type: integer
Default: 20000
Minimum: 5000
Maximum: 20000
MEMO_UDFS_LIMIT The maximum number of memo-type UDFs that can be defined per
workspace.
Type: numeric
Default: 10
Maximum: 30
MINUTES_UNTIL_GLOBAL_ The maximum number of minutes that the session lasts even if the session
SESSION_TIMEOUT is in use.
Type: integer
Default: 1440 minutes (24 hours)
MINUTES_UNTIL_IDLE_SESSION_ The maximum number of minutes that the session lasts while the session
TIMEOUT is not in use.
Type: integer
Default: 180 minutes (3 hours)
ODATA_USE_SERVER_BASE_URL If ALM Octane does not respond successfully to an OData consumer

request, it might be because the base URL used to refer to ALM Octane is
different than expected.
l true. ALM Octane uses the URL specified in the SERVER_BASE_URL

site configuration parameter.
l false. ALM Octane uses the original URL as requested from the
consumer.
Type: boolean
Default: true

space. *
SERVER_BASE_URL The base URL of the server.
The ALM Octane server is often unaware of the base URL used to refer to it
from the outside world, because the base URL is often set at the proxy
server level.
Use this parameter to manually specify the externally-used URL. This is

especially useful for scenarios where the ALM Octane server needs to send
the base URL to other applications that do not run inside the server's local
network.
Type: string
Example:
http://host.domain:8080
SHARED_SPACES_LOG_LEVEL Changes the log level for specific shared space logs.
The format is:
<shared_space_ID>=<level>;<shared_space_ID>=<level>;<shared_space_
ID>=<level>
Each level setting is separated by a semi-colon (;).
Type: string
Example:
1001=INFO;2001=WARN
Valid values:
l DEBUG
l WARN
l INFO
l WARN
l FATAL
l ERROR
l TRACE

space. *
SLACK_INTEGRATION_CLIENT_ When enabling Slack integration with ALM Octane, this parameter sets the
ID client ID for accessing Slack. You can find this in the Slack app's Basic
Information > App Credentials area.
Type: string
SLACK_INTEGRATION_SECRET When enabling Slack integration with ALM Octane, this parameter sets the
client secret for accessing Slack. You can find this in the Slack app's Basic
Information > App Credentials area.
Type: string
SMTP_ADMIN_MAIL Sets the "From" email address to be used when a user clicks the Send
Email button on the toolbar for an entity.
If blank, the mail is sent from the current user.
Type: string
SMTP_AUTHENTICATION Defines whether the SMTP server needs to be authenticated.
Type: boolean
Default: false
SMTP_ENABLE_STARTTLS Determines whether STARTTLS is used when connecting to the mail

server.
Type: boolean
Default: false

space. *
SMTP_NOTIFICATION_SENDER_ Sets the "From" email address to be used when ALM Octane sends an
EMAIL email for notifications such as "follow" notifications or notifications from
rules.
This parameter is relevant only if notifications are turned on:
l If his parameter is not specified, ALM Octane uses the value specified in
"SMTP_ADMIN_MAIL" on the previous page.
l If no values are specified for both this parameter and SMTP_ADMIN_
MAIL, no notifications are sent.
This parameter can be set both at the site level and at the shared space
level. The shared space level parameter overrides the value set at the site
level.
Type: string
SMTP_PASSWORD Sets the password for connecting to the SMTP server.
Type: string
SMTP_SSL_SUPPORT Defines whether to connect to the SMTP server using SSL
Type: boolean
Default: false
SMTP_USER Sets the user for connecting to the SMTP server.
Type: string
STORAGE_MAX_FILE_SIZE Sets the maximum size for storage files, including attachments (in bytes).
This parameter is set at the site level, and not at the shared space level.
Type: integer
Default: 10000000
Minimum: 10000
Maximum: 100000000

space. *
STORAGE_MAX_SIZE Sets the maximum size for storage per shared space (in MB).
Available workspace storage is set on the space level, and not per
workspace. This means the amount of total available workspace storage is
shared between the workspaces in the space.
Type: integer
Default: 10000
Minimum: 6000
Maximum: 20000
SUPPORTS_BASIC_ Sets whether the basic authentication is activated for the REST API and
AUTHENTICATION OData per space.
When setting this configuration parameter:
l Make sure to specify the space ID.

l Send an HPECLIENTTYPE header with the value HPE_REST_API_
TECH_PREVIEW in your requests to configure this parameter.
Type: boolean
Default: false
Example: See "Configuration parameters" on page 480.
TREE_COMPONENT_MAX_ Sets the limit for the number of items to display in the tree for the Backlog,
ITEMS_PER_PARENT Quality, and Requirement modules. Also sets the number of items to return
using the REST API.
If the tree contains a parent with more than this number of children, a
message displays indicating that not all items are displayed. You can
search for items by name if the one you need is not displayed.
Type: integer
Default: 500 (recommended, for performance reasons)
Customizable for: Both site and space, by site admin only

space. *
WEBHOOK_ALLOW_HTTP If the URL specified in Trigger webhook rules can use the http protocol in
addition to the secure https protocol.
When using HTTP, use only the standard port 80 for outgoing requests,
Type: boolean
Default: false
WEBHOOK_REQUEST_TIMEOUT On-premises: The number of seconds to wait for the webhook response.
Type: integer
Default: 30 seconds
Minimum: 10 seconds
Maximum: 60 seconds
See also:
l "Set configuration parameters (technical preview)" on page 479
l Setting configuration parameters with the REST API in the Developer Help.
Set up LDAP (on-premises)

You can manage and authenticate ALM Octane users using your organization's LDAP system.
Caution: Once you set up LDAP authentication, you cannot continue using ALM Octane
built-in, native, internal user management. You cannot have a mix of users created with
ALM Octane internal user management and users imported from LDAP.
In this topic:
1. "LDAP configuration flow" on the next page

2. "Plan how to set up LDAP user authentication" on page 504
3. "Export users from LDAP" on page 507
4. "Import LDAP users into ALM Octane" on page 508
5. "Include LDAP users in ALM Octane (on-premises)" on page 509
6. "Update LDAP user and server properties (optional)" on page 510

LDAP configuration flow
Plan Learn how ALM Octane works with LDAP for user management, and plan
accordingly. For details, see "Plan how to set up LDAP user authentication" on
the next page.
Configure Define LDAP settings in the octane.yml file either during installation or any
time after. For details, see how to configure other settings in the ALM Octane
Installation Guide.
Restart Restart the ALM Octane server. The LDAP settings defined in the octane.yml
file take effect each time you restart the ALM Octane server. For details on
restarting the server, see the ALM Octane Installation Guide .
Note: After restarting the server, any previously-defined native ALM Octane
users (both admins and regular) can no longer access the ALM Octane server.
Only the AdminDN user defined in the octane.yml file has access. The
AdminDN logs in using the specified dn (not using the name defined in
octane.yml).
Export users Export users using your LDAP configuration tool. For details, see "Export
from users from LDAP" on page 507.
LDAP system
Import Import LDAP users using the ALM Octane Settings area. LDAP users can be
LDAP users imported to the space or to the workspace. You need space admin or
into ALM workspace admin permissions, respectively. See "Import LDAP users into ALM
Octane Octane" on page 508.
Include Instead of exporting and importing all LDAP users as a batch operation, you
LDAP users can include LDAP users in the ALM Octane Settings area. For details, see "Set
in ALM up LDAP (on-premises)" on the previous page.
Octane

Update Over time, update LDAP users or the LDAP server properties as necessary.

(optional) For details, see "Update LDAP user and server properties (optional)" on
page 510.
Plan how to set up LDAP user authentication

Here we provide general information for planning how to set up ALM Octane for LDAP user
authentication.
Important considerations
Once you configure for LDAP user management, you cannot return back to native, internal user
management.
ALM Octane does not support the management of both LDAP and native, internal users
simultaneously.
Native, internal users will not be able to log into ALM Octane after LDAP is configured. You have
to include or import them as LDAP users. Therefore, we recommend that you deactivate these
users after LDAP configuration.
Learn how ALM Octane authenticates LDAP users

ALM Octane authenticates LDAP users when they log in.
1. When logging into ALM Octane, the LDAP user enters the name and password.
2. ALM Octane looks up the name in its list of LDAP users.
3. ALM Octane locates the corresponding LDAP dn for the LDAP user.
ALM Octane does this using the mapping settings in a configuration file, called octane.yml.
For details, see "Configure" on the previous page.
4. ALM Octane locates the user in LDAP by dn to see if the user is authenticated.

Decide how to create ALM Octane users based on your organization's LDAP
system
You manage your users using your organization's LDAP system.
However, you use one of the following methods to take the details about existing users in your
LDAP system and import these details into ALM Octane:
Method Description
Export Export LDAP users to a .csv file, and then import the .csv file using ALM Octane
and settings. See "Import LDAP users into ALM Octane" on page 508. This is useful for
import first-time LDAP configuration, when you have many LDAP users to add to ALM
Octane at one time.
Include Include LDAP users in the ALM Octane Settings area. This is useful for adding
users LDAP users periodically, without having to re-export and re-import. See "Set up
LDAP (on-premises)" on page 502.
REST API You can create an LDAP user using the REST API by posting the user with certain
LDAP attributes.
You cannot use the REST API to import existing LDAP users from a .csv file. You
can only create new ones manually that represent the details of the existing users
in the LDAP system.
For details about using the REST API to create users, see the information about
creating LDAP users in the Developer Help.
Understand how ALM Octane identifies and adds users from LDAP
Learn how your LDAP users will map to existing users in ALM Octane, if any exist.

How does ALM Octane determine a match?

ALM Octane compares the following details of each imported LDAP user to the existing user
information in ALM Octane:
LDAP User Attribute ALM Octane User Field

The immutable LDAP UUID (universally unique ID) uid
The logon name Login Name (name field in REST API)
See "Mapping" below for how a summary of how ALM Octane maps ALM Octane and
LDAP attributes.
There is a match!
If either of these attributes matches, the imported LDAP user is considered existing.
ALM Octane updates the details of the existing, native ALM Octane user to those of the
corresponding LDAP user.
ALM Octane was not able to match an LDAP user to an ALM Octane user
The imported LDAP user is considered new.
ALM Octane creates new users using the details of the corresponding LDAP users. New users are
assigned to the default workspace with the team member role.
Users in ALM Octane did not match any LDAP user

Because you cannot have a mix of users created with ALM Octane internal user management and
users imported from LDAP, the non-LDAP ALM Octane users are unable to log in to ALM
Octane. In this case, we recommend you manually deactivate these users. For details on
deactivating users, see "Assign roles and permissions" on page 529.
Mapping
Mappings are configured in the octane.yml file. For details, see how to configure other settings in
the ALM Octane Installation Guide .
octane.yml field Field in ALM Field in ALM In

Mapping for mapping Octane UI Octane REST API LDAP Example
Immutable, universally- uid uid uid UUID entryUUID in

unique identifier OpenLDAP
Unique identifier across all logonName Login name Logon mail

ALM Octane users Name field Name

Export users from LDAP

These instructions describe how to export users from LDAP into a .csv file. Later, we import the
users listed in the .csv file into ALM Octane.
This is useful for first-time, initial addition of LDAP users in ALM Octane, when many users have
to be created at once.
1. The LDAP admin should define the relevant filters in LDAP so that relevant users only are
exported. It is unlikely that all LDAP users need to be exported into ALM Octane.
2. In your LDAP configuration tool, export user details to a .csv file.
If you have more than one LDAP server, create a separate .csv file for each one.
When you export user details, you must use the exact attributes listed in the octane.yml file,
and in the exact order the attributes are listed there.
Your .csv file should have the following:
l A header line containing the attribute names in the octane.yml file.
l Lines for each user, containing the values for the attributes included in the header.
Example
entryDN,entryUUID,givenName,sn,cn,mail,telephoneNumber
"cn=admin1,ou=pcoe_alm_users,dc=maxcrc,dc=com","b5d4a886-2347-435a-8557-
e3d8561b5f38","Tony ","Stark ","Tony Stark ","TS@TheCompany.com",0133456789
"cn=admin10,ou=pcoe_alm_users,dc=maxcrc,dc=com","e2e455ad-9248-48bf-b6ce-
86ffc8d11f9c","Chris ","Thompson ","Chris Thompson
","CT@TheCompany.com",5223456789
"cn=admin11,ou=pcoe_alm_users,dc=maxcrc,dc=com","10fd9c99-3ea2-4a67-bb22-
053aef055635","Greg ","Santora ","Greg Santora
","GS@TheCompany.com",0120956789
"cn=admin2,ou=pcoe_alm_users,dc=maxcrc,dc=com","05f85a65-f661-4a0e-a21b-
567944b7e779","Kenny ","Smith ","Kenny Smith
","KS@TheCompany.com",0123456734
"cn=admin3,ou=pcoe_alm_users,dc=maxcrc,dc=com","54734767-2a83-4527-86d3-
260c893e52d8","Maria ","Jose ","Maria Jose ","MJ@TheCompany.com",0123555789
"cn=admin4,ou=pcoe_alm_users,dc=maxcrc,dc=com","96920f66-a0dd-4d38-b25f-
ee76e0bffd90","Peter ","Klein ","Peter Klein
","PK@TheCompany.com",0111156789
If your .csv file was exported in such a way that it contains an extra line between the header
line and the user lines, remove the extra line.
For an example of how to do this, see this KB article.

3. After exporting to the .csv file, verify the following using a simple text editor like Notepad
(not Microsoft Excel):
l The file contains all headers.
l The columns are in the order of the octane.yml file.
l The export process did not add additional columns. This is because some
LDAP configuration tools add columns, such as DN, automatically when exporting.
Caution: Do not open the file in Microsoft Excel, even just for viewing purposes. This
is because opening a .csv file in Microsoft Excel can change the file to a non-csv
format. ALM Octane supports only the csv file format.
Import LDAP users into ALM Octane

These instructions describe how to import LDAP users from a .csv file (created in a previous step)
into ALM Octane.
1. Log in to ALM Octane using the login name for the AdminDn user as defined in the
octane.yml file.
2. In Settings , choose Space, and select a space or workspace. This determines the context in
which you import the users.
Space Creates or updates space users.
New users are assigned to the default workspace with the team member role,
which is the default role for all new users until other roles are assigned.
Workspace Creates or updates a workspace user.

The users are assigned with the role selected in the import dialog.
3. Choose the Users tab.
4. In the toolbar, click Import.
Permissions required: Create User
5. In the import dialog, select:
l The relevant .csv file.
Note: If you have more than one LDAP server, import each file separately.
l The LDAP server from which the .csv file was exported.
Click OK to import.
6. Check the response that is returned after the import. This includes the number of users
successfully imported, and errors for each user that did not import successfully.

The errors indicate specifically which users in the .csv file were not imported successfully.
Users are identified by the index of the line number in the .csv file, keeping in mind that the
first line is the header line and does not contain actual data.
If there are errors, resolve them in your LDAP user configuration tools or in the .csv file. Then
re-import the .csv file.
An error report can also be found in the server logs by the correlation ID. See the log site.log,
which is generally stored here: C:/octane/log/nga/site/site.log
Include LDAP users in ALM Octane (on-premises)

These instructions describe how to include LDAP users into ALM Octane.
This is useful, for example, after all LDAP users were initially imported, and then new users were
added to LDAP.
1. Log in to ALM Octane.
2. In Settings , choose Space, and select a space.
3. Choose the Users tab grid view.
4. In the toolbar, click .

5. In the Include LDAP Users dialog, enter:
LDAP server The name of the LDAP server from which you are including users.
This is the LDAP server defined with the host setting in the octane.yml file.
For details on this configuration file, see the ALM Octane Installation
Guide.
Directory The root of the LDAP path from which to search for users.
base This is the LDAP server defined with the baseDirectories setting in the
octane.yml file. For details on this configuration file, see the ALM Octane
Installation Guide.
Base filter LDAP filters to use when searching.
These are the LDAP server filters defined with the baseFilters setting in the
octane.yml file. For details on this configuration file, see the ALM Octane
Installation Guide.
Search text Enter the exact string to search for. Partial matches are not supported.
You can search for a specific first name, last name, email, and login name.
3. Click .
A list of LDAP users that match your criteria is displayed.
LDAP users that are already in ALM Octane are not listed.

Tip: Up to 100 results are listed. If you get this many results, you may want to refine
your search criteria.
4. Select the users you want to include from the list of search results.
5. Click Include to add the users.
Update LDAP user and server properties (optional)

These instructions describe how to update ALM Octane after changing LDAP user or
LDAP server properties at any point after initial import.
When using ALM Octane with LDAP, ALM Octane does not manage user details other than the
user avatar. Instead, user details are managed by your LDAP server.
If you make any changes to users in your LDAP system after the initial import, do one of the
following:
l Re-import all LDAP users into ALM Octane. This is useful for batch operations when updates
to many users are needed.
l Update the relevant user attributes using the ALM Octane REST API. This is useful when you
have modifications to a few users. For details, see the Developer Help.
l If the changes involve adding new users, add them using the Include LDAP User feature in
ALM Octane Settings. For details, see "Set up LDAP (on-premises)" on page 502. This is useful
when you have a few new LDAP users to add.
Here are some scenarios which would necessitate that you make LDAP updates, and how to make
the updates by importing.
User These changes include changes to a specific user attribute, such as the user's last
attribute name.
changes
Notes:
l You cannot change the ALM Octane user ID (uid) because this is the
attribute by which ALM Octane identifies each user internally for
synchronization between ALM Octane and LDAP, including importing.
l You can change the logonName attribute, but make sure the logonName is
unique across all ALM Octane users.

To update user details:
1. Update the details in the LDAP configuration tool.
2. Re-export the users using a new .csv file, making sure the attributes are in
the exact order as in the octane.yml file.
3. Re-import the .csv file to ALM Octane.

LDAP server These changes include changes to a specific LDAP server attribute, such as the
changes LDAP server's ID or IP address.
If you update the LDAP server ID, you must also update your users in ALM
Octane. This is because the LDAP server details are included in the details for
each of the LDAP users.
To update LDAP server details:
1. Using your LDAP configuration tool on the new LDAP server, export the
users to a .csv file.
When you export user details, you must use the exact attributes listed in the
octane.yml file, and in the exact order the attributes are listed in the file.
2. In the octane.yml file, modify the details for the LDAP server. For details,
see the ALM Octane Installation Guide .
3. Restart your ALM Octane server. For details on how to restart your server,
see the ALM Octane Installation Guide .
4. In ALM Octane, re-import the .csv file. In the Import dialog, select the name
of the new LDAP server.
The details are updated for the users, including the server details.
See also:
l The octane.yml file. See how to configure other settings in the ALM Octane Installation
Guide.
l "Manage users" on page 524
Change passwords
Change your password or have an administrator change it for you.
In this topic:
l "Change your own password" below
l "Change another user's password (on-premises)" on the next page
Change your own password

This section describes how to change your own password on Saas and on-premises.

SaaS
Log into MyAccount and change your password in the user area.
On-premises
On-premises users can follow these instructions to change their own passwords.
Note: If the space admin is not assigned any other role, the space admin cannot change
his/her own password.
1. In the top banner, click .

2. Under your user details, click Change Password.
3. Enter your old password. If you do not remember your old password, ask your space admin
to change it for you.
4. Enter a new password and confirm it.
5. Passwords must be at least 8 characters long, and contain at least one capital letter, one
lower case letter, and one number or symbol.
Change another user's password (on-premises)

Shared space admins and workspace admins can follow these instructions to change another
user's password.
Note: As a space admin, you can change passwords for any user, but you cannot change
your own password if that is your only assigned role.
1. In Settings , click Spaces and select a space or workspace.

2. In the Users tab, click a row to select a user. You can change the password of only one user at
a time.
3. Click Change Password.
4. Enter a new password and confirm it.
Passwords must be at least 8 characters long, and contain at least one capital letter, one
lower case letter, and one number or symbol.
5. Click Change Password.

Space configuration
See also:
l MyAccount User Guide
l "Set up LDAP (on-premises)" on page 502
Space configuration
This section provides instructions that site admins, space admins, and workspace admins can use
to configure spaces.
In addition to the instructions below, space admins can also set configuration parameters for
relevant spaces. For details, see "Set configuration parameters (technical preview)" on page 479.
Topic Description
"Manage spaces" on the next Instructions for managing both shared and isolated spaces.
page
"Manage workspaces" on Instructions for managing workspaces.

page 519
"Manage users" on page 524 How to add users to spaces and workspaces, and delete them
or deactivate them when necessary.
"Assign roles and permissions" How to assign roles to users to give them specific permissions.
on page 529
"Set up a release" on page 535 How to set up releases in the relevant shared space or
workspace, and define its timeline and workforce.
"Manage teams" on page 540 How to create teams in each workspace, and assign the teams
to the releases on which they will work.
"Design forms" on page 543 How to choose which fields are included in a form, and design
the form’s layout.
"Customize fields" on How to create user-defined fields (UDFs), and change field
page 547 display names for both system fields and UDFs.
"Set up lists" on page 553 How to modify the values of system lists, and create your own
lists.
"Set up rules" on page 568 Instructions for designing rules that trigger actions in ALM
Octane when certain conditions are met.
"Set up workflow phases and How to set up your development workflow by defining
transitions" on page 557 phases and how to transition from phase to phase.

Space configuration
Manage spaces
In ALM Octane, there are different spaces, or contexts, within which you can work, depending on
your permissions. This topic discusses how to manage spaces.
In this topic:
l "About spaces" below
l "View spaces for a site (on-premises)" on page 516
l "Create a space (on-premises)" on page 516
l "Edit settings for a space" on page 517
l "Create workspaces" on page 517
l "Delete workspaces" on page 517
l "Manage storage" on page 519
l "Upgrade spaces (on-premises)" on page 519
l "See a space's background jobs (on-premises)" on page 519
About spaces
Spaces are the contexts in which an ALM Octane user can work, depending on permissions.
Spaces are containers for workspaces. For details on workspaces, see "Manage workspaces" on
page 519.
On-premises: Site admins can create spaces.

Space configuration
Space admins manage spaces. The space admin can associate workspaces to a space, define users,
and set API access. For details on the space admin's capabilities, see "Assign roles and permissions"
on page 529.
Some entities are defined on the space level. These include users, API keys, and so on.
The space admin can create the following types of spaces: Isolated and shared.
Isolated spaces
The space admin can define users and API access.
Each workspace associated with an isolated space has its own set of data, which only workspace
admins customize.
The icon indicates the space is isolated, and when displayed next to an entity, indicates that
the entity is not shared across workspaces.
Shared spaces
The space admin can define users and API access.
Additionally, the space admin can customize data to be shared across workspaces (Enterprise
Edition).
Shared entities includes releases, user-defined fields, forms, and so on.
The icon indicates the space is shared, and when displayed next to an entity, indicates that the
entity is shared across workspaces.
Some entities can be customized both for shared spaces (affecting all associated workspaces) and
also for individual workspaces. Only the workspace admin can customize entities for individual
workspaces.

Space configuration
Shared spaces
Customizable for
all workspaces associated
Customizable for shared with a shared space, and
spaces only, affecting all also for individual Customizable for individual
associated workspaces workspaces workspaces only
l List items l Releases and milestones l Teams
l API access l Forms
l Rules
l Users
l User-defined fields (UDFs)
l Workflow
Example
There are three development divisions in your company: Hardware, Software, and Internal.
The hardware, and its accompanying software, must be released on the same release schedule and
are made publicly available. Even though processes for these two divisions' deliverables might be
different, the release schedule is the same. Also, a subset of testers test both hardware and
software.
Internal development activities are on a different schedule and have nothing in common with the
other two divisions' activities.
l Create a workspace called Hardware, a workspace called Software, and a workspace called
Internal.
l Create a shared space called External_Deliverables. Add the Hardware and Software
workspaces to this shared space. These workspaces will share releases and users.
l Create an isolated space called Internal_Deliverables. Add the Internal workspace to this space.
The workspaces in this space will not share information with any other workspaces.
View spaces for a site (on-premises)

The site admin can view all the spaces for the site. For details, see "View spaces for a site" on
page 471.
Create a space (on-premises)

The site admin can create spaces for the site. For details, see "View spaces for a site" on page 471.

Space configuration
Edit settings for a space

Modify and customize settings for a space.
1. In Settings , select Spaces and then select the space.

2. Edit the space by adding users, and setting up API access.
If the space is shared , you can also add releases, teams, UDFs, forms, workflow, and rules.
Create workspaces
Space admins create workspaces. The workspace admin then manages them.
1. In Settings , select Spaces, and navigate to the relevant space.
2. Click Add Workspace in the left pane. Name the workspace, add a description, and assign
a workspace admin.
Workspace names are unique within a space.
3. Assign a workspace admin, workspace members, and users with other roles to the workspace.
For details, see "Assign or remove roles" on page 534.
Tip: If you need to edit the workspace settings, for example, to create releases, rules,
and so on, assign the workspace admin role to yourself.
Delete workspaces
Space admins can delete workspaces. This makes all workspace data inaccessible and cannot be
undone.
Every space has at least one active workspace. the default workspace. The original name of this
workspace is default_workspace. It can be renamed but it cannot be deleted.
If the workspace you last accessed is deleted, you are redirected to the another one.
In Settings -> Spaces, select the workspace and click .
Manage users
User management includes adding users, including existing users to workspaces, adding roles
to users, and so on.

Space configuration
1. In Settings , depending on your permissions, click Site or Spaces.

3. Add or edit users, depending on your role:
On-premises: Shared space Workspace
User management capability Site admin admin admin
Add users to the current context
(site, space, or workspace). For
details, see "Assign roles and
Add LDAP users to a space. For On-premises:

details, see "Include LDAP users in
ALM Octane (on-premises)" on
page 509.
Add existing users from the space

into the workspace. For details,
see "Include existing users into a
workspace" on page 527.
Remove roles from a workspace

user. For details, see "Assign or
remove roles" on page 534.
Choose the fields to display in the

user list, sort the list, and export
the list to Microsoft Excel.
On-premises: Set user passwords.
Assign additional roles to users.

For details, see "Assign or
unassign roles to existing users"
on page 534.
Assign the site admin role to other

users. For details, see "Assign the
site admin role to existing users
(on-premises)" on page 535.
Activate and deactivate users. For On-premises: SaaS: SaaS:


Space configuration

Delete a user. For details, see
"Delete a user" on page 470.
Manage storage
Available workspace storage is set on the space level, and not per workspace. This means the
amount of total available workspace storage is shared between the workspaces in the space.
On-premises: Site admins can set the maximum size for storage per space with the STORAGE_
MAX_SIZE configuration parameter. For details, see the information about setting the maximum
size for storage (STORAGE_MAX_SIZE) in the ALM Octane Installation Guide .
Upgrade spaces (on-premises)

The site admin can upgrade spaces for the site.
See a space's background jobs (on-premises)

Background jobs include processes that run after upgrading a space, among other activities. A
space is only fully upgraded after all background jobs have completed. The site admin can check
periodically to see when an upgraded space is ready.
For details, see "See a space's background jobs" on page 473.
Next steps:
l "Administer the site (on-premises)" on page 468
l "Manage workspaces" below
Manage workspaces
Workspaces are individual work areas. Each workspace represents a project, program, or product
managed on the same ALM Octane site. This topic discusses how to manage workspaces.
In this topic:
l "About workspaces" on the next page
l "Create a workspace" on page 522
l "Edit workspace settings" on page 522

Space configuration

l "Deleting workspaces" on page 523
l "Managing workspace storage" on page 523
About workspaces
Workspaces are individual work areas, each representing a project, program, or product managed
on the same ALM Octane site.
Workspaces are associated with spaces. For details on workspaces, see "Manage spaces" on
page 514.
Every space has at least one active workspace. the default workspace. The original name of this
workspace is default_workspace. It can be renamed but it cannot be deleted.
Who manages workspaces?

l Space admins create, rename, modify and delete workspaces. For details on the space admin's
capabilities, see "Assign roles and permissions" on page 529.
l Workspace admins manage the contents of workspaces. For details on the workspace admin's
capabilities, see "Assign roles and permissions" on page 529.
What data do workspaces contain?

Workspaces can contain data such as the backlog, application modules, tests, defects,
customization settings, and so on.

Space configuration
Can workspaces share data?

Spaces that are shared Spaces that are isolated
Enterprise Edition: Workspaces associated with isolated spaces

do not share data.
Workspaces associated with shared spaces
can share items, such as releases, rules, and so
on. These items are called shared entities.
To share data, define the entity for the
associated shared space, and not for any
specific workspace. For a list of entities that
can be shared, see "Shared spaces" on
page 516.
Define these entities in a specific workspace if
you want them available only in that
workspace.
You can define some entities, such as rules
and forms, both for an individual workspace
and for all workspaces associated with a
shared space. Space admins can define these
entities for the shared space, and the
workspace admin can define these entities for
an individual workspace.
Example: Working with spaces

There are three development divisions in your company: Hardware, Software, and Internal.
The hardware, and its accompanying software, must be released on the same release schedule and
are made publicly available. Even though processes for these two divisions' deliverables might be
different, the release schedule is the same. Also, a subset of testers test both hardware and
software.
Internal development activities are on a different schedule and have nothing in common with the
other two divisions' activities.
l Create a workspace called Hardware, a workspace called Software, and a workspace called
Internal.
l Create a shared space called External_Deliverables. Add the Hardware and Software
workspaces to this shared space. These workspaces will share releases and users.
l Create an isolated space called Internal_Deliverables. Add the Internal workspace to this space.
The workspaces in this space will not share information with any other workspaces.

Space configuration
Create a workspace
The space admin creates workspaces. For details, see "Create workspaces" on page 517.
Edit workspace settings

The workspace admin can modify workspace settings.
1. In Settings , select Spaces and then select a workspace in the tree.

2. Edit the workspace settings by changing the workspace name, adding or editing releases,
teams, DevOps settings*, rules, user-defined fields (UDFs), forms, and workflow phases.
*DevOps settings include CI servers, Testing Tools, test assignment rules, settings for
SCM integration, and Slack integration.
Note: If some of these workspace settings are not available, they are probably shared
across multiple workspaces. Your space admin can make these updates for you on the
corresponding shared space.
Manage users
From the spaces pane, a workspace admin can manage users for a workspace.


page 509.

Space configuration




on page 534.



Deleting workspaces
The space admin deletes workspaces. For details, see "Delete workspaces" on page 517.
Managing workspace storage

Available workspace storage is set on the space level, and not per workspace. This means the
amount of total available workspace storage is shared between the workspaces in the space.

Space configuration
On-premises: Site admins can set the maximum size for storage per space with the STORAGE_
MAX_SIZE configuration parameter. For details, see the information about setting the maximum
size for storage (STORAGE_MAX_SIZE) in the ALM Octane Installation Guide .
Next steps:
Manage users
When starting your project in ALM Octane, add users to spaces and workspaces.
After you create users, assign roles to them. For details, see "Assign roles and permissions" on
page 529.
In this topic:
l "About managing users" below

l "Ways to add users" on the next page
l "Sharing users between spaces (Enterprise Edition)" on page 526
l "Add a user" on page 526
l "Edit a user" on page 527
l "Include existing users into a workspace" on page 527
l "Activate or deactivate a user" on page 528
l "Delete a user" on page 528
l "Map ALM Octane users to SCM users" on page 529
About managing users

This section provides an overview of user-related tasks and in which who can perform them.


Space configuration

page 509.




on page 534.



Ways to add users

Add users to ALM Octane in the following ways:
l With ALM Octane's native user management system. For details, see "To add a user:" on the
next page.

Space configuration
l On-premises: Import users from an LDAP server. For details, see "Set up LDAP (on-premises)"
on page 502.
l Include existing users from a space into a workspace. For details, see "Include existing users into
a workspace" on the next page.
l Use the REST API. For details, see the information about POSTing (creating) users in the
Developer Help.
Tip: Set the ALLOW_WORKSPACE_USERS_CREATION configuration parameter to false

to prevent the workspace admin from adding and including users at the workspace level.
For details, see "ALLOW_WORKSPACE_USERS_CREATION" on page 481.
Sharing users between spaces (Enterprise Edition)

Users can be defined at the space level by the space admin and the workspace level by the
workspace admin.
The admin designates in which workspaces the user exists by explicitly defining the workspace
when adding or modifying the user.
Must user names and emails be unique?

Across all workspaces and spaces, login names and emails must be unique.
Add a user
Add users to your spaces and workspaces.
To add a user:
1. In Settings , click Spaces.
2. Choose a space or a workspace in the tree on the left.
3. In the Users tab, click +.
On-premises: If you use LDAP user management, the + button is disabled. In this case,
perform user management tasks in your LDAP server. For details, see "Set up LDAP (on-
premises)" on page 502.
Note: If you use LDAP authentication, you cannot use ALM Octane native user
management.
4. Enter the user information.

Space configuration
If you specify a Login name, the user uses this name to log into ALM Octane. If no login name
is specified, the email address is used.
You or the user can change the password at a later time. For details, see "Change passwords"
on page 511.
5. Assign roles to users.
l Space admins assign roles to the user by workspace.
l Workspace admin assign roles to the user for their workspace only.
For details, see "Assign roles and permissions" on page 529.

6. Click Add.
7. If you are a site admin, in the Site area, you can assign a user to be a site admin. Click the
user's ID and change the Site admin value to Yes.
Edit a user
An admin can click the ID of a user in the Users grid to modify an existing user's details, including
his own.
You cannot change your own Login name, but another admin can change that for you.
For details on assigning roles, see "Assign roles and permissions" on page 529.
For details on changing passwords, see "Change passwords" on page 511.
Include existing users into a workspace

Add users that are already defined in the space context to a workspace without having to reenter
user details. You can add native ALM Octane users or LDAP users (LDAP is supported for on-
premises only).
To include users from a space into a workspace:

1. In Settings , as a workspace admin, click Spaces.
2. Choose a workspace in the tree on the left.
3. In the Users tab, click .

4. LDAP: You can filter the list to refine your search. When filtering, you can enter the asterisk (*)
as a wildcard representing zero or more characters.
5. Select the users to include.
6. Click Add.

Space configuration
Activate or deactivate a user

Activating and deactivating a user controls whether that user can access ALM Octane and how
others interact with that user.
Activate a The user can log into ALM Octane.

user
Deactivate l The user cannot log into ALM Octane if they are not activated in at least one
a user workspace.
l Other cannot assign items to a deactivated user.
l ALM Octane cannot send emails to a deactivated user.
Deactivated users still exist in ALM Octane. In addition, references to these users
are retained.
We recommend that before you deactivate a user, check what entities assigned to
the user and update them as necessary.
If you reactivate a user, ALM Octane restores all existing settings for the user.
When you view the users in a shared space or workspace, the Status column in the grid shows you
activated users and deactivated users .
To activate or deactivate a user:

1. In Settings , depending on your permissions, click Site or Spaces, and then the relevant
space or workspace.
2. In the Users grid, select one or more users.
3. In the toolbar, click either or to activate or deactivate the user(s).

4. Click Yes to confirm.
Delete a user
Deleting a user removes the user from ALM Octane.
l On-premises: Site admins can delete a user. For details, see "Delete a user" on page 470.
l SaaS: Make sure to perform the following:
a. First, the SaaS account administrator either deletes the user from MyAccount or, if enabled,
removes ALM Octane from the user's list of allowed services.
b. Then, the ALM Octane space admin opens a support ticket to SaaS requesting that the
user be deleted in ALM Octane.

Space configuration
Map ALM Octane users to SCM users

For analysis of SCM commits, identify which users perform the commits and map their ALM
Octane user their SCM user. This enables you to analyze the commit information with ALM
Octane widgets, filters, and so on.
If you set up ALM Octane to integrate with a CI server that works with a Source Control
Management (SCM) system, ALM Octane tracks changes committed to the SCM system. For
details, see "Track changes committed to your Source Control Management system" on page 199.
If the email address defined for an SCM user is identical to the one defined for an ALM Octane
user, the users are mapped automatically when changes they commit are discovered.
Make sure that your SCM system is configured to share commit authors with your CI server. For
example, in the Jenkins GIT plugin, set the option User commit author in changelog.
Otherwise, map the users manually.
ALM Octane users can also map themselves to unmapped SCM users listed in the Commits tab.
This does not require admin permissions. For details, see "Use the Commits tab to track committed
changes" on page 202.
To map an ALM Octane user to an SCM user:

1. In Settings , click Spaces and select the space.
2. In the Users tab, click in the SCM users cell of a specific ALM Octane user.\
l Select from the list of SCM users known to ALM Octane from previous commits.
l Click Add New to add an SCM user. Provide the SCM user's username and email address
for identification.
See also:
l "Set up LDAP (on-premises)" on page 502
l "Assign roles and permissions" below
Assign roles and permissions

A role and its permissions determine what actions a user may perform or what areas of ALM
Octane they can view.

Space configuration
In this topic:
l "Sharing roles and permissions between spaces" below
l "Permissions" on the next page
l "Predefined roles" on page 533
l "View roles and permissions" on page 533
l "Create roles" on page 533
l "Assign or remove roles" on page 534
Overview
ALM Octane provides roles with predefined sets of permissions. For details, see "Predefined roles"
on page 533.
Example: A user with the leader role can:
l Perform any task that a team member can do.

l Manage items in the Quality module.
l Set team velocity and capacity.
l Rank features and epics.
If a user is assigned multiple roles, the user has the permissions of all the assigned roles. The space
admin can view the current permissions for each role.
Space admins can:
l Create new roles.
For details, see "Create roles" on page 533.
l Customize permissions, assigning different permissions for different items, such as defects,
phases, and so on.

For details, see "Edit permissions" on page 533.
Space admins and any users with Create User or Edit User permissions can assign roles when:
l Creating or editing users. For details, see "Manage users" on page 524 and "Assign or remove
roles" on page 534.
l Defining API access. For details, see "Set up API access" on page 305.
Sharing roles and permissions between spaces

Roles and permissions are defined at the space level. The roles and permissions are relevant for all
associated workspaces.
Roles cannot be modified on a workspace level.

Space configuration
Permissions
Permissions are assigned to roles, and are organized into functional categories, such as backlog,
administration, testing, and more.
To see the permissions available by role, select the Spaces > Permissions tab in Settings, and
select each role.
Permission categories
The following table lists the permissions available for each category. These permissions indicate:
l How users with the selected role can work with each item in the category.
l In some cases, whether a user with the selected role can perform additional actions related to
the category.
Category Description
Tests Permissions for working with all test types and also parameter tables.
Runs Permissions for working with runs for each type of test.
Backlog Permissions for working with work items and tasks.

Included in this category are permissions for ranking and planning.
Requirements Permissions for working with requirements and folders.
Application Permissions for working with application modules.

Modules
Release Permissions for working with releases, sprints, and milestones.

Management
Teams Permissions for working with teams.
Pipelines Permissions for working with pipelines and pipeline builds.

Included in this category are permissions for running pipelines.
Administration Permissions for customizing the workspace, such as customizing workflow,

phases, forms, rules, and so on.
DevOps Permissions for customizing pipelines, CI servers, collaboration tools, and so

Administration on.

Space configuration
Category Description
General Permissions for the actions in this category apply across all of ALM Octane
System and are not related to any one functional category. For example, you can set
Actions permissions for sending email, managing environments, and so on.
Module Permissions for the actions in this category let you customize which roles
Visibility have UI access to each ALM Octane module. This is for convenience, so users
only see areas that are relevant to them.
Module visibility permissions do not affect the user's ability to perform actions
for items in the module. For example, a user has full permissions for defects,
but no permission to view the Defects module. This user can still view, update,
and create defects using the REST API or from other modules, such as
Backlog or Quality.
Permissions
After choosing a role, you can assign permissions by item. Most items have the standard Create,
Update, and Delete permissions available for assignment.
"By author" permissions are permissions that are granted only to the item's creator. For example,
"Delete by author" permissions for a test enables the test's designer to delete the test. Delete by
author" permissions for a defect enables the user who detected the defect to delete it. In these
cases, the user designated in the Owner field cannot delete the test or the defect because this user
did not create the item.
Some actions are relevant to specific categories only.
Example:
l You can set the permissions for running a pipeline for the Pipelines category only.
l You can set the permissions for ranking work items in the Backlog category only.
Some items have additional permissions, such as managing relations between items, performing
certain actions, or the ability to access certain modules.
There are also permissions that include a combination of other permissions:
l If your role is assigned the Manage Relations set of permissions, you automatically have create,
edit, and delete permissions for relations.
l If your role is allowed to create an item, you also have the ability to edit any item you create.
l If your role is allowed to create releases, teams, administration items, and Devops items, you can
also edit items created by others.

Space configuration
Predefined roles
You can assign one or more of the following predefined roles to users: Site admin (on-premises),
Space admin, Workspace admin, DevOps admin, Leader, Team member, Tester, Viewer,
Synchronizer admin.
To view the default permissions of these roles, see "View roles and permissions" below.
You can customize the permissions of the following roles: Workspace admin, DevOps admin,
Leader, Team member, Tester, and Viewer. For details, see "Edit permissions" below.
* Space admins can customize the permissions for this role.
View roles and permissions

Space admins can check which permissions have been assigned to each role for each functional
category of ALM Octane.
1. In Settings , click Spaces and select a space.

2. In the Permissions tab, select a role from the drop-down list.
3. Click any of the functional categories. The permissions are displayed for each item.
Create roles
In addition to the predefined roles supplied with ALM Octane, space admins can create new roles
with customized permissions.

2. In the Permissions tab, click Add Role.
3. Enter a name for the new role.
4. Select an existing role on which to base this new role's permissions.
5. For each item, check or clear the permissions.
6. To rename a role, from the Role list, select the role you want to rename, click the Rename Role
button, and edit the role name.
You can rename only user-created roles.
Edit permissions
Space admins can edit permissions for user-defined roles and for the following predefined roles:
Workspace admin, DevOps admin, Leader, Team member, Tester, and Viewer.

Space configuration
To edit permissions:
2. In the Permissions tab, select the role from the Role list.
3. For each item, check or clear the permissions.
Assign or remove roles

Some admins can add and remove roles for existing users. Every ALM Octane user must be
assigned at least one role in each workspace to which he/she is assigned.
Assign or unassign roles to existing users

Assign and unassign roles at the space or workspace levels.
Workspace admins and space admins cannot unassign themselves from their roles. Other admins
can do this for them.
Note:
l To see all of a user's roles and workspaces, click the user ID. You may also assign or
unassign roles and workspaces in this view.
l The Maintenance Protocol and Micro Service Site Admin roles are used internally for
synchronization, to deploy the Synchronizer services. For details, refer to the
Synchronizer Installation Guide. Do not modify or delete these roles.
From the space level

2. In the Users tab, click a row to select a user. Shift-click to select additional users.
3. Click Assign to Roles/Workspaces or Unassign from Roles.
4. Select the roles and workspaces that you want to assign or remove.
l To add another role to the same user, click Add role to assign . You may assign roles to
multiple workspaces for a single user.

l To remove a role, click Unassign from Roles and select a role to unassign and the
workspaces from which to remove the role.

You cannot remove a user's last remaining role. Each user must be assigned to at least one
role in each workspace to which he/she is assigned.
5. Click Assign or Unassign.

Space configuration
From the workspace level

2. In the Users tab, click a row to select a user. Shift-click to select additional users.
3. Right-click and choose Bulk Update.
4. Select the Roles field.
5. Select the Roles to assign. If you want to unassign a role, make sure it is not selected.
6. Decide if you want the changes to overwrite the existing roles.
To unassign roles, you must choose Replace existing values.
7. Click Update.
Assign the site admin role to existing users (on-premises)

For details, see "Assign the site admin role to existing users" on page 469.
See also:
Set up a release
Set up releases in the relevant shared space or workspace, and define its timeline and workforce.
In this topic:
l "Sharing releases between spaces" on the next page

l "Add releases" on page 537
l "Update release information" on page 537
l "Set the current and default releases" on page 539
l "Deactivate a release" on page 540

Space configuration
Sharing releases between spaces

Releases can be defined for shared spaces and workspaces. This overview describes how to
work with shared and non-shared releases.
Isolated spaces
Releases cannot be defined at the space level when the space is isolated.
Instead, workspace admins can define releases in individual workspaces.
The releases are available in that individual workspace only.
Shared spaces (Enterprise Edition)

This table summarizes the actions admins can perform when defining releases in shared spaces
and associated workspaces.
Shared space Associated workspaces
The space admin can add and modify releases l For releases defined by the space admin in
defined in the shared space. the shared space:
The releases are available to all associated ALM Octane users working in a specific workspace
workspaces. can access both the releases defined for the
corresponding shared space and also the releases
defined specifically for that workspace. Shared
releases are displayed with the icon.
The workspace admin cannot modify shared

releases.
l For releases defined by the workspace
admin in a workspace:
The workspace admin can add and modify these
releases.
The releases are available to that individual
workspace only.
Must release names be unique?

Within a shared space or a workspace, release names must be unique.
However a shared release may have the same name as a release defined for an associated
workspace.

Space configuration
You can distinguish between the releases because ALM Octane displays the shared icon for
the shared releases.
Add releases
Add the necessary releases before defining the timeline.
To add a release:
1. In Settings , click Spaces and select the shared space or workspace where you want to
create a new release.
Releases can be defined on a shared space level and a workspace level. If defined on a
workspace level, the release is only available for that workspace.
2. In the Releases tab, click Add Release.

3. Provide an appropriate name for the release. You can also add a description and attach
documents.
4. Select the release type: Scrum or Kanban.
5. For Scrum releases, define start and end dates for the release and specify the duration of
sprints in days or weeks.
6. Click Add.
ALM Octane adds the release and its details to the Releases grid.
Tip: To set the release as the default release, in the toolbar click the Set as Default Release
button .
ALM Octane labels the default release as [Default] next to the release number in Backlog
release filters, dashboard grids, and so forth. This lets you set rules to help you fill values
according to a default.
Update release information

After adding releases, edit the details of the release.
To update release details:

1. In Settings , click Spaces and select the shared space or workspace for the release. Then.
click the release ID link to open the release.
2. Update the necessary details:

Space configuration
Edit In the Details tab of the release, change any of the following:
global l Start and end dates of the release
release
l Release descriptions
details
If you change the start or end dates of a release, ALM Octane adjust the
release's existing sprints. ALM Octane updates sprint dates so the sprints run
consecutively from the beginning of the release. ALM Octane also removes
extra sprints are removed.
Add and In the Timelines tab, update details on the sprints.

edit When you open the Timeline tab for the first time, ALM Octane displays
sprints sprints based on the sprint length you specified when creating the release.
l To create another sprint, in the toolbar, click . Then, in the Add

Sprint dialog box, provide the sprint name, and start/end dates for the
sprint.
If you are adding another sprint after the end of the release, make sure to
select the Add as a last sprint (expand release) check box. This adds the
sprint to the end of the timeline and adjusts the release calendar.
l To edit sprint start and end dates, select a sprint block in the timeline and
click . In the Sprint details box, update the name, sprint
start/end dates, and the assigned teams for that sprint.
Add and A milestone is a significant date that occurs during the release timeline. This
edit can include things such as Code Freeze, Regression End, and so on. Adding
milestones milestones lets you see where these dates fall relative to your sprints.
To add a milestone, click and provide the milestone name and

date. To edit milestone details, select the milestone in the timeline and click

Space configuration
Add and a. In the Teams tab, click Assign teams.

edit teams b. Select the teams to assign and click Add.
By default, when you assign a team to a release, ALM Octane assigns the
team to all the release's sprints.
If you later need to update the list of teams assigned to a sprint:
a. In the Timeline tab, select a sprint and click in the toolbar.

b. In the Sprint details dialog box, in the Teams drop-down list, select the
teams.
Note: You can select only teams that are already assigned to this
sprint's release.
Enter the For each team, you should enter the estimated velocity. Velocity is the
estimated number of story points you expect each team to finish during a sprint.
velocity a. In the Teams tab of a release, click the numerical ID link for a team. The
for a team team details open for that team.
b. In the Details tab the team, in the estimated velocity field, enter the
estimated number of story points.
Note: This change is reflected for all releases for the team.
c. Click Save.
ALM Octane displays the updated velocity in the Estimated velocity column
of the Teams tab. ALM Octane also displays the number for the velocity in
the Release Expected Capacity table in the Timeline tab.
Set the current and default releases

In addition to using release names or numbers, you can use the idea of the current or default
release.
ALM Octane defines the current release based on the dates you enter for each release.
Set the default release automatically or manually:
l By default, ALM Octane sets the default release as the current release.
l To override the default release from the current release, set the default in the release list. For
example, if you have a favorite created to monitor all defects from the default release, at the
end of a release timeline - when your developers have moved on to working on the next release

Space configuration
- you can override the default release to view details from the previous release instead of the
current one.
In filters, ALM Octane displays the default release with brackets as [Default release].
Deactivate a release
When you finish working on a release, you can deactivate it. Deactivated releases no longer
appear on lists of data entry, such as assigning content to a release. However they do appear in
filters, so you can see which content was assigned to obsolete releases.
Select one or more releases in the Releases grid, and click Deactivate Release .
See also:
l "Manage teams" below
l "Plan your release" on page 107
Manage teams
Workspace admins can create teams in workspaces, and assign the teams to the releases on which
they will work.
Tip: Are you going to manage ALM Octane users using LDAP? If so, we recommend that
you export LDAP users into ALM Octane before continuing. For details, see "Set up LDAP
In this topic:
l "Overview" below
l "Sharing teams between spaces" on the next page
l "Create teams" on the next page
l "Assign a team to releases" on the next page
l "Edit a team's details" on page 542
l "Adjust a team's capacity per sprint" on page 542
Overview
Create teams in each workspace, and assign the teams to the releases on which they will work.
Then estimate a velocity at which the team is expected to work, in story points. This determines
the capacity of your release—how much functionality you can deliver according to the release
timeline and the teams working on it.

Space configuration
ALM Octane assumes that each team member works 6 hours each day. This determines the
capacity of your team—how many tasks your team can handle in a sprint.
Once teams are created, you can assign backlog items in ALM Octane to specific teams. This
indicates who is responsible for the different items.
You define a workspace team's settings, and users can track the team's performance across
releases.
Sharing teams between spaces

Teams cannot be shared.
Workspace admins can define teams for individual workspaces.
Space admins cannot define teams for isolated or shared spaces.
Create teams
1. In Settings , click Spaces and select the workspace where you want to create a team.
2. In the Teams tab, click + to add a team.
3. Enter values for the team, such as name and estimated velocity, and select a team leader for
this team.
Tip: The expected velocity is the number of story points that you expect the team to
deliver in each sprint, based on the team performance over time.
4. Click Add to complete the team creation.
Assign a team to releases

1. In Settings , click Spaces and select the workspace where you want to assign the team.
2. In the Teams tab, click the team ID link to open the team you want to edit.
3. In the Details tab, in the Releases field, click the down arrow and select one or more releases.
4. To automatically assign this team to all releases that will be created from now on, do one of
the following:
l In the details page: Select Assign to new releases
l In the grid: Select Yes in the Assign to new releases column.

Space configuration
Edit a team's details

You can edit team member details in one of the following ways:
In the Workspace
1. In Settings , click select the workspace where you want to edit the
Settings team.
2. In the Teams tab, click the team ID link to open the team you want to
edit.
3. In the Details tab, set the Team lead.
4. In the Members tab, select members from the list of ALM Octane
users and add them to the team.
5. To remove a member from the team, hover over the list of team
members and click the X next to the relevant name.
Tip: When you remove a member from the team:
l The member is removed from the team but the user

remains in the list of ALM Octane users.
l Any backlog items assigned to this team member remain
assigned.
In the Team 1. In the Team buckets area, with a release and sprint selected in the
Backlog module filter, click the Edit button above the buckets:
2. In the Team Management dialog, select the Members tab.

3. In the Members tab, click Assign members select members from the
list of ALM Octane users and add them to the team.
Adjust a team's capacity per sprint

1. In Settings , click Spaces and select the workspace where you want to set the capacity.
2. In the Teams tab, click the team ID link to open the team you want to edit.

Space configuration
Tip: If the relevant field's column is not displayed in the grid, click and add the
column to the grid.
3. In the Velocity tab, fine-tune the team's expected capacity per sprint in each release.
l Select a release.
l Specify the sprints in which the team is available.
l For each sprint, enter an Expected velocity. This is the number of story points that the
you except the team deliver in each sprint.
Tip: The Velocity grid also displays an Actual Velocity column that reports the
actual velocity achieved in a sprint so you can get a realistic view of what the team
is achieving for each sprint.
The updated capacity information is reflected in the Backlog and Team Backlog modules.
Note: For any given sprint, the expected capacity may not be the same as the expected
velocity entered in the Details tab for the team.
See also:
l "Set up a release" on page 535
l "Plan your release" on page 107
Design forms
Forms are the pages in which users create and edit entities in ALM Octane. Admins can choose
which fields are included in a form, and design the form’s layout.
In this topic:
l "Sharing forms between spaces" on the next page
l "Predefined forms" on page 545
l "Design forms" above
l "Working with forms" on page 546

Space configuration
Overview
Admins can:
l Create or modify forms so that users see only what they need.
l Create rules so that ALM Octane uses the relevant forms. For details, see "Set up rules" on
page 568.
Use the form designer to create and edit your forms. The form designer has a form management
area and a design area.
Note: Name and Type fields cannot be accessed in the form designer.
You can design different forms for the same entity type:
l You can design different forms based on context. For example, you can design a form for use
when creating a new user story and another form for editing a user story. These forms include
different fields.
l You can also create forms for users with different roles. For example, a dev team manager is
interested in different fields than a tester.
Tip: Non-admin users can add and remove fields to forms when creating or editing an
entity. For details, see " Edit forms" on page 83.
Sharing forms between spaces

Forms can be defined for shared spaces and workspaces. This overview describes how to work
with shared and non-shared forms.
Isolated spaces
Forms cannot be defined at the space level when the space is isolated.
Instead, workspace admins can define forms in individual workspaces.
The forms are available in that individual workspace only.

Space configuration

This table summarizes the actions admins can perform when defining forms in shared spaces and
The space admin can add and modify forms defined l For forms defined by the space admin in
in the shared space. the shared space:
The forms are available to all associated workspaces. ALM Octane users working in a specific workspace
can access both the forms defined for the
corresponding shared space and also the forms
forms are displayed with the icon.
The workspace admin cannot modify shared forms.

l For forms defined by the workspace admin
in a workspace:
forms.
The forms are available to that individual
workspace only.
Must form names be unique?

Within a shared space or a workspace, form names must be unique.
However a shared form may have the same name as a form defined for an associated workspaces.
You can distinguish between the forms because ALM Octane displays the shared icon for the
shared forms.
Predefined forms
For each entity type, ALM Octane provides predefined forms. ALM Octane uses these forms by
default when you create and edit entities.
l Default form for Edit
l Default form for New
Note: Some entities do not have a Default form for New.
You can make other forms the default forms instead of these.
You can modify these forms, but you cannot rename them.

Space configuration
Working with forms

This section describes how to create, and work with, forms.
Forms can be defined on a space level and a workspace level.
Before working with forms, define any custom fields you need. For details, see "Customize fields"
on the next page.
1. In Settings , click Spaces and select the shared space or workspace where you want to
create a new form.
2. Click Entities and select an item.
3. Click Forms. The form designer is divided into the management area and the design area.
4. In the management area, modify the attributes for each field or section using the design area
toolbar.
You can also duplicate a form, rename a form, and reset a form's layout.
5. In the design area, do one of the following:
l Choose the relevant section, and the item before which you want to add a field, and click
Add field.
l Choose the section before which you want to add a section, and click Add section.
Choose either Regular or Full in the Size drop-down to determine if the field takes up an
entire row or if ALM Octane can put it on a row with other fields.
When finished adding fields, click outside the list to close the list.
Note: Required fields must be on the form, ALM Octane automatically adds them. You

Space configuration
can move them but you cannot delete them.
6. Click Set as default if you want to use this form as the default.
Next steps:
l "Set up rules" on page 568
l "Customize fields" below
Customize fields
This topic describes how to work with both system-defined fields and user-defined fields (UDFs).
This includes creating user-defined fields (UDFs), and changing field display labels.
In this topic:
l "Sharing UDFs between spaces" below
l "Change field display labels" on page 552
l "Add a user-defined field" on page 549
l "Set attributes for the user-defined field" on page 551
l "Customize fields" above
l "Delete a user-defined field" on page 551
Sharing UDFs between spaces

UDFs can be defined for shared spaces and workspaces. This overview describes how to work
with shared and non-shared UDFs.
Isolated spaces
UDFs cannot be defined at the space level when the space is isolated.
Instead, workspace admins can define UDFs in individual workspaces.
The UDFs are available in that individual workspace only.

Space configuration

This table summarizes the actions admins can perform when defining UDFs in shared spaces and
The space admin can add and modify UDFs defined l For UDFs defined by the space admin in
in the shared space. the shared space:
The UDFs are available to all associated workspaces. ALM Octane users working in a specific workspace
can access both the UDFs defined for the
corresponding shared space and also the UDFs
UDFs are displayed with the icon.
The workspace admin cannot modify shared UDFs.

l For UDFs defined by the workspace admin
in a workspace:
UDFs.
The UDFs are available to that individual
workspace only.
Must UDF names and labels be unique?

If a UDF is defined for a shared space, you cannot create a UDF, or define a label, with the same
name in the associated workspaces:

Space configuration
If a UDF is defined for an individual workspace, you cannot create a UDF, or define a label, with
the same name in the associated shared space. You can create a UDF, or define a label, with the
same name in other workspaces.
Add a user-defined field

1. In Settings , click Spaces and select the shared space or the workspace where you want to
create user-defined fields.
2. Click the Entities tab.
3. In the Entities list on the left side of the pane, select the item (such as user story, manual test,
epic, and so on) for which you want to create your own fields.
4. Click the Fields tab.
5. Click + to add a user-defined field.
6. Enter the following:
Name Description
Name A unique name that APIs will use to access this field. No uppercase letters
or punctuation allowed.
ALM Octane automatically adds the suffix _udf to the name of the field.
Label A unique name for the field as you want it displayed in the UI. You can
enter English, non-English, and special characters.
Field type Select the field type from the drop-down.

Space configuration
Name Description
Description Enter a description for the user-defined field.
Limitations: UDFs can only be defined in English even if ALM Octane has been localized for a
specific language.
Limits on the number of UDFs you can define per workspace

Field type Maximum no. of UDFs allowed per workspace
String and A total of 100 between the two types.

Boolean Note: String fields can contain up to 255 characters.
Number 50
Date and 20
time
List Unlimited
User Unlimited
Release Unlimited
Team Unlimited
Long 5
string Note: Long string fields can contain up to 1500 characters.
Memo 30
Note: You can modify this value by setting the MEMO_UDFS_LIMIT
configuration parameter "MEMO_UDFS_LIMIT" on page 497.
7. If you are adding a user-defined field of list type:

l Select the list to use for the field.
For details on creating your own lists, see "Set up lists" on page 553.
l If you want the user-defined field to select multiple value, check the Allow multiple values
check box.
8. If you are adding a user-defined field of user, release, or team type, select the reference field
on which to base the new field's value.
9. To add the user-defined field to existing forms, select the forms from the Add to form drop-
down list.
10. Click Add.
UDFs are available in ALM Octane like other predefined system fields.

Space configuration
Set attributes for the user-defined field

You can set attributes for the user-defined field, such as making the field mandatory, by creating
rules for entity types. For details, see "Set up rules" on page 568.
If a user-defined field is Required, but the default Smart View form for adding an item does not
display the new user-defined field, ALM Octane still prompts you for a value in the Other Required
and Invalid Fields section. This section displays only when needed.
Delete a user-defined field

If a user-defined field (UDF) is no longer relevant, you can delete it.
In your entity, select the user-defined field in the grid, and in the toolbar, click the Delete button X.
The deleted field is handled accordingly:
Entity Forms Fields are cleared from a form the next time the form is opened.
Rules A warning is displayed. All rules containing the field are invalid and
deactivated.
Graphs The field is no longer available as an option. Additionally,

l For current status graphs, a message is displayed that the graph
configuration is no longer valid. Modify the existing configuration as
needed.
Delete the widget if you cannot modify the existing configuration.
l For trend-based graphs, the field remains in graph data.
Filters/ Fields in filters are cleared with a message. Reset the filters (either in the
Group By filters grid or in the dashboard configuration) as needed.
Sorting order The field is cleared from the sorting with a message.
Grid displays The field is removed from the grid display without a message.
Favorites Fields in a favorite are cleared without a message.

Space configuration
Change field display labels

You can change the display names of both UDFs and system fields.
To change field labels:

1. In Settings , click Spaces and select a shared space or workspace.
2. Click Entities > Fields, and select a field.
3. Modify the Label field and click Save.
Troubleshooting: After I modify a field label, users do not see the new label in grids.
Some grids list multiple entities in a combined view. To display correctly, the field labels for all the
entities have to match.
Backlog grid Includes defects, user stories, and quality stories.
Test grid Includes manual tests, Gherkin tests, test suites, and automated tests.
Run grid Includes manual test runs and automated test runs for test suites.
Solution: In Settings, change the label for the field for all relevant entities.
Example
1. Defects, quality stories, and user stories have an Author field.

2. You want to change the label from Author to Creator.
3. In Settings, modify the Author field label to Creator three times, once for each of the
three entities separately: Defects, quality stories, and user stories.
4. The combined Backlog grid in ALM Octane displays the Creator label correctly.
Limitation: If a field is not available for all entities in the combined grid, ALM Octane does not
display the new label.
See also:
l "Design forms" on page 543
l "Set up lists" on the next page

Space configuration
Set up lists
ALM Octane provides default lists of values for system fields.
Space admins and workspace admins can modify values for many system lists, and create lists.
Admins without Administration > List > Manage permissions can view the Lists area in Settings,
but cannot make any updates.
In this topic:
l "Sharing lists between spaces" below
l "Create a user-defined list" on the next page
l "Modify a system list" on page 555
l "Delete a user-defined list" on page 556
Overview
All lists and list values have the following types of names:
l Names, which are displayed in the ALM Octane UI.
l Logical names, for use with the REST API, such as when filtering.
When creating user-defined lists and list values, logical names are automatically generated, but
can be modified. You cannot modify a logical name after it is created.
For details on working with lists in the REST API, see Create custom lists (on-premises).
Sharing lists between spaces

Lists can be defined for shared spaces and workspaces. This overview describes how to work
with shared and non-shared lists.
Isolated spaces
Lists cannot be defined at the space level when the space is isolated.
Instead, workspace admins can define lists in individual workspaces.
The lists are available in that individual workspace only.

Space configuration

This table summarizes the actions admins can perform when defining lists in shared spaces and
The space admin can add and modify lists defined in l For lists defined by the space admin in the
the shared space. shared space:
The lists are available to all associated workspaces. ALM Octane users working in a specific workspace
can access the lists defined for the corresponding
shared space. Shared lists are displayed with the
icon.
The workspace admin cannot modify shared lists.

l Lists cannot be defined by the workspace
admin in a workspace.
Create a user-defined list

After a space admin or a workspace admin creates a user-defined list, the list can be added in your
forms and rules can be created that access the lists.
To create a user-defined list:

1. In Settings , select Spaces and select a shared space or a workspace.
2. Click Lists, and then + to add a list.
3. Name the list. The list is automatically assigned a logical name.
Each list is automatically assigned a logical name for REST API purposes, which you can
modify when initially creating the list. Logical names must be lowercase English letters and
numbers. You may also enter one underscore character between letters. The suffix _ln (with a
lowercase "l" for "logical name") is automatically added to the list's logical name. Do not delete
this suffix. After creating the value, you can no longer change the logical name.

Space configuration
4. You can perform the following operations on your lists:

Click... To...
Name Rename the list.
text
box
List Rename a list item.

item's
text
box
Add a value to the list.

Logical names: Each value is automatically assigned a logical name for
REST API purposes, which you can modify when initially adding the value to the
list. Logical names must be lowercase English letters and numbers. You may also
enter one underscore character between letters. The suffix _In (with a lowercase
"l" for "logical name") is automatically added to the value. Do not delete this
suffix. After creating the value, you can no longer change the logical name.
Toggle sorting the items in the list in ascending and descending order.
Deactivate an the item in the list.

Deactivated items are no longer displayed in the list. However, they are not
removed from existing lists.
You cannot reactivate an item in the list once the list is saved. Alternatively, you
can create a new list item with the same name.
Restore While editing a list, you can restore the values until you Save. Values are reset to
their original values when you started editing the list.
5. Click Add.
Modify a system list

The space admin or the workspace admin can modify some of the default system lists that are
provided with ALM Octane.
To modify a system list:

2. Click Lists.

Space configuration
All lists are displayed. However, you can modify only user-defined lists and certain system
lists. To determine if, and to what extent, lists are editable, see the IS MODIFIABLE and IS
RENAME ONLY columns.
3. Click the link to the list you want to modify.
4. Modify the list.
Not all lists support full editing. For example, Severity and Priority fields only support
renaming of list items.
Click... To...
Name Rename the list.

text
box
List Rename a list item.

item's
text
box
Add a value to the list.

Logical names: Each value is automatically assigned a logical name for
REST API purposes, which you can modify when initially adding the value to the
list. Logical names must be lowercase English letters and numbers. You may also
enter one underscore character between letters. The suffix _In (with a lowercase
"l" for "logical name") is automatically added to the value. Do not delete this
suffix. After creating the value, you can no longer change the logical name.
Toggle sorting the items in the list in ascending and descending order.
Deactivate an the item in the list.

Deactivated items are no longer displayed in the list. However, they are not
removed from existing lists.
You cannot reactivate an item in the list once the list is saved. Alternatively, you
can create a new list item with the same name.
Restore While editing a list, you can restore the values until you Save. Values are reset to
their original values when you started editing the list.
5. Click Save.
Delete a user-defined list

If a list is no longer in use by any user-defined fields (UDFs) or rules, the space admin or
workspace admin can delete the list.

Space configuration
To delete a user-defined

2. Click Lists.
3. Select the list you want to delete.
4. Click .
See also:
l "Set up lists" on page 553
l "Customize fields" on page 547
Set up workflow phases and transitions

This topic describes how to set up your development workflow by defining phases and how to
transition from phase to phase.
In this topic:
l "Overview" below
l "Sharing phases and workflows between spaces" below
l "The workflow diagram" on page 559
l "Sample workflows" on page 561
l "Set up workflows" on page 563
l "Create workflow rules" on page 565
Overview
ALM Octane uses phases to represent the status of an entity.
For every entity, you can customize a workflow, indicating the phases through which the entity
advances as it is being developed.
Workflow is supported for any entity which proceeds through development, such as
requirements, defects, tests, and so on.
Sharing phases and workflows between spaces
Isolated spaces
Workflows cannot be customized at the space level when the space is isolated.

Space configuration
Instead, workspace admins can customize workflows in individual workspaces.

Only entities in each individual workspace advance through the customized workflow phases for
that workspace.
Shared spaces
This table summarizes the actions admins can perform when customizing workflows in shared
spaces and associated workspaces.
The space admin can customize an entity's workflow l For workflows defined by workspace admin
in the shared space by creating, renaming, and in the workspace:
deleting phases and transitions. The workspace admin can modify these workflows.
When customized in a shared space, a workflow and Only entities in the workspace advance through the
its phases are available for the entity in all associated modified workflow phases.
workspaces.
l For workflows defined by space admin in
the shared space:
Phases in a shared workflow are displayed with the
icon.
The workspace admin can customize these shared

workflows for the current workspace. Customization
includes renaming phases and adding phases.
Transitions are added automatically. For examples,
see "Shared workflows" on page 562.
The workflow is still shared, but the changes made
at the workspace level are available only to the one
workspace where the changes are made. Only the
workspace admin can access the changes made to
the shared workflow.
For details, see "Shared workflows and cross-
workspace reporting (Enterprise Edition)" below.
Shared workflows and cross-workspace reporting (Enterprise Edition)

Shared spaces enable you to create widgets that report on information across workspaces. The
resulting information is called a cross-workspace graph. Any entity that meets the widget's filter
criteria is included in the graph, regardless of workspace.
Cross-workspace graphs in the dashboard can display only information that is available to all the
relevant workspaces. This means that any changes made in a workspace to a shared workflow are
not visible in the cross-workspace graphs.

Space configuration
Even if a shared workflow has been customized for a workspace, any entities whose phases were
defined in the customized parts of the shared workflow are included in the graph.
Limitation: If the cross-workspace widget configuration includes phases as the x-axis value, ALM
Octane ignores entities whose phases were customized in a workspace. They are not included in
the graph.
For details on cross-workspace widgets using the dashboard, see "Workspace " on page 291.
The workflow diagram

The workflow diagram contains the following entities.
l "Phases" below
l "Transitions" on the next page
Phases
The phase represents a status of an entity.
Phase Different entities have different sets of phases. For example, backlog item
phases include New, Deferred, Opened, Fixed, Proposed closed, Duplicate, Closed,
and Rejected.
Indicated by a rectangle:
If working in a workspace, an icon indicates that the phase is part of a shared

workflow and defined in the shared space.
You can customize the phases for each entity. For details, see "Set up lists" on
page 553.
Start When you create a workflow, the first phase in the workflow is the Start phase.
phase
Indicated by a green rectangle:
Every workflow has only one Start phase.

Space configuration
Metaphase Inside each workflow are Metaphases.
Indicated by a label over the relevant phases in the diagram:

A metaphase lets you categorize the phases logically.
Metaphases are provided by default and cannot be modified.
Within the metaphases, you can change the order and flow of the phases or add
additional phases.
Metaphases are also used in the dashboard to simplify and categorize charts and
graphs.
The metaphases for backlog entities and their default phases are:
l Phases for the New metaphase include: New, Deferred
l Phases for the In progress metaphase include: Opened
l Phases for the Done metaphase include: Duplicate, Closed, Rejected
Master If you select a phase in a shared workflow from within a workspace, the master
phase phase field displays the original phase in the shared workflow on which changes
were based. You can see the master phase field in the PROPERTIES pane on the
right.
l If you rename a shared workflow phase in a workspace, the master phase
displays the original name of the phase in the shared space.
l When adding phases in a workspace to a shared workflow, you add the phases
relative to an original phase. The original phase is the master phase for any of
these newly-added phases.
For examples, see "Shared workflows" on page 562.
Transitions
Workflow phases are connected by transition arrows.
Primary A primary transition is the main workflow for the entity. Most entities will pass
transition through the phases of the primary path as the entities are being developed.
Indicated by a solid arrow:

Each workflow has one primary transition.

Space configuration
Secondary, Transitions that are alternate workflow paths. These transitions are not
or alternate, essential to the primary logic of the workflow. Under certain circumstances, an
transition entity will follow the alternate path.
Indicated by a dotted arrow:
Example: Most New defects follow the primary path to the Opened phase.
However, a New defect may be Deferred if there are not enough resources to
handle it.
Sample workflows
Here are some sample workflows that demonstrate the use of phases and transitions.
User stories
Gherkin tests
Defects

Space configuration
Shared workflows
Here we demonstrate how to work with shared workflows. The examples below are based on the
following scenario:
Our site has a shared space for a clothing division. This shared space has four workspaces
associated with it:
Workspace admin adds several phases to a shared workflow for tasks

Here is a sample workflow for the task entity in the Clothing Division shared space:
The workspace admin modifies the workflow for the Men's Clothing workspace. The workspace
admin adds two phases before this phase (Researching and In Design) and two phases after this
phase (In Review and Testing). Because the changes are based on the In Progress phase, In
Progress is the master phase.

Space configuration
Only workspace users for that workspace can see these changes. To these workspace users, there
are now five phases between New and Completed.
Each of these five phases has the same master phase, In Progress. We can see this in the
PROPERTIES pane at the right:
The master phase, and any new phases directly or indirectly added to it, are handled as one unit in
the shared space and in cross-workspace graphs. In this example, Researching, In Design, In
Progress, In Review, and Testing are considered one unit based on the master phase, In Progress.
If a shared space graph counts the number of tasks that are In Progress, the total includes the
number of tasks in these five phases.
Set up workflows
1. In Settings , click Spaces and select a shared space or workspace.
2. Click Entities and select the entity for which you want to set up the workflow.
3. Click Workflow. The existing workflow phases display graphically.
4. Modify the workflow as needed. Select a phase, and then:
Rename a Enter a name in the PROPERTIES pane.
phase

Space configuration
Assign a Enter a different metaphase in the PROPERTIES pane. In the display, the
phase to a phase moves to the newly-assigned metaphase.
different
metaphase
Describe a View the read-only description in the PROPERTIES pane.

phase
Add a Right-click the phase before which you want to add a new phase. Select Add
phase Phase.
Tip: If you add phases with similar meanings to defect and user story
workflows, use the same name for the phase in both workflows. This is
because, in the Backlog module, the Backlog Items tab displays defects and
user stories together. The phase filter for this tab includes all workflow
phases for defects and user stories. Phases with the same name are listed
only once in the filter.
Indicate Click the Start Phase check box in the PROPERTIES pane.
the phase
is a start
phase
Indicate Click the Primary Transition check box in the PROPERTIES pane.
the
transition
is a
primary
transition
Add a Right-click the phase before which you want to add a new phase. Select Add
transition Transition. Enter the name of the target phase to which the transition
should point.

Space configuration
Delete a Right-click the phase or transition, and select the delete option.
phase or a l You cannot delete a phase if it has outgoing transitions, so delete those
transition transitions first.
l You cannot delete a transition if it is the only incoming transition to a
phase.
l If you delete a transition that is the primary transition, it is best to clear
the Primary Transition check box before deleting it and to select a

different transition as the primary one.
Only space admins can delete phases defined on the shared space level.
Workspace admins cannot delete or modify transitions created from the
workspace on a shared space workflow.
As you modify the workflow, it is refreshed automatically.

5. Click Save for the workflow.
Create workflow rules

You can create rules to customize workflow from the workflow diagram and also from the Rules
settings area.
In this section:
l "Define workflow rules in the workflow diagram" below
l "Define workflow rules in Rules settings area" on the next page
l "Sharing workflow rules between spaces" on the next page
Define workflow rules in the workflow diagram

You can define workflow rules for the currently-selected phase or the currently-selected
transition.
1. In the RULES pane on the right, click + to add a rule.
The RULES pane on the right displays rules for the currently-selected phase or transition
only.
2. Define the rule.

Space configuration
For details, see "Set up rules" on page 568.

3. Click Save in the RULES pane.
Define workflow rules in Rules settings area

If you click the Rules tab at the top (not from the Rule panel), you see the rules defined for the
currently-selected entity, including the rules you just created from workflow.
You can add more workflow rules and modify existing workflow rules.
The Phase column in the grid shows the phases for which you created the rule. These rules do not
run for any other phase.
For details, see "Set up rules" on page 568.
Sharing workflow rules between spaces

This section explains how workflow rules can be shared across workspaces and be customized for
individual workspaces.
l Workflow rules defined in a workspace are only available to that workspace.
l Workflow rules defined for shared workflows are available to associated workspaces.
l Workflow rules defined for a shared workflow can be customized for individual workspaces.
Here we demonstrate how ALM Octane handles shared workflow rules and their customization.
The scenario
A shared space has the following workflow for quality stories.
New > In Progress > Done
The space admin defined a Block Transition rule that does not allow team members to advance
the phase of a defect from In Progress to Done. Only QA testers are allowed to do this.

Space configuration
A workspace admin wants to customize this shared workflow. After adding the In Testing phase
before the Done master phase, the customized shared workflow in the workspace looks like this:
New > In Progress > In Testing > Done
Block Transition workflow rules

Rules with the Block Transition action prevent users from transitioning from one phase to a
specific phase, even though the transition is generally permitted in the workflow for the entity.
When the Block Transition rule runs for the workspace, it runs only on the first phase in the unit.
As a result, team members cannot advance the phase of the defect from In Progress to In Testing.
Other workflow rules

Added phases and their master phase are handled together by ALM Octane.
When workflow rules, such as Make required or Make read-only, run for the workspace, the
actions are applied to each added phase and the master phase.
If the space admin makes the Done phase required in the shared workflow, both the In Testing
and Done phases become required at the workspace level.
Note: This is not true of Block Transition rules. In this case, actions are applied only to the
first phase in the unit. For details, see "Block Transition workflow rules" above.
Next steps:
l "Set up rules" on the next page
l The information about drafts in the Developer Help
l "Set up lists" on page 553
l "Workspace " on page 291

Space configuration
Set up rules
You can set up rules that trigger actions in ALM Octane when certain conditions are met.
In this topic:
l "Overview" below
l "Accessing rules" below
l "Sharing rules between spaces" below
l "Define rules" on the next page
l "Examples" on page 576
Overview
Rules contain an action and usually a condition.
You set the action that should occur when the condition is true.
l Actions
Examples of actions include making fields required, making fields read-only, setting a default
value for a field, and so on.
l Conditions
When conditions are met, the rule's action is performed. For example, a rule can make the Fixed
in Release field required if the Status field is changed to Fixed. Status=Fixed is the condition.
If you don't specify a condition, the rule's action is always performed. For example, you may
want a field to always be required.
Accessing rules
Space admins and workspace admins can modify values for rules.
Admins without Administration > Rule > Manage permissions can view the Rules area in Settings,
but cannot make any updates.
Sharing rules between spaces

Rules can be defined for shared spaces and workspaces.
Isolated spaces
Rules cannot be defined at the space level when the space is isolated.
Instead, workspace admins define rules in individual workspaces.
The rules are applied in that individual workspace only.

Space configuration

This table summarizes the actions admins can perform when defining rules in shared spaces and
The space admin can add and modify rules defined in l For rules defined by the space admin in
the shared space. the shared space:
The rules run in all associated workspaces. Rules run in all associated workspaces.
The workspace admin cannot modify shared rules.
l For rules defined by the workspace admin
in a workspace:
rules.
The rules run for that individual workspace only.
Which rules run first?
Individual workspace rules run first, and then shared space rules. For details, see "Do shared
space rules or workspace rules take precedence?" on page 581.
Define rules
Rules can be defined for shared spaces and workspaces.
Create a rule
1. Plan ahead.
Depending on the rule you are defining, there may be some preliminary steps to take before
starting.
For example, if you are creating a rule with the Trigger Webhook action, you may want to
define credentials before creating the rule.
2. In Settings , click Spaces and select a space or a workspace.
3. Click Entities and select the item for which you want to create a rule.
4. Click Rules.
5. You can create a new rule or use an existing one as a basis:
l Click + to create a new rule.
l Select a rule and click Duplicate Rule.

Space configuration
Define an action
Click Action and choose the action for the rule to perform.
Enter the relevant values for that action.
Actions
Action Description
Make Make fields mandatory.

Required
Example
Make Make fields read-only.

Read-
only
Modify Change the values for lists to a subset of the list.

Lookup
Enter the name of the list you want to use. For details on creating lists, see "Set up
List
lists" on page 553.
Example
Use Form Enable users to select different form layouts for adding and editing entities.
The form layout must be pre-defined in Customization > Forms.
Example
Set Field You can either:

Value
l Set a default value for a field when creating or changing an entity.
l Set a value for a field if the value of another field changes.
Timing is the trigger that causes a value to be set. The timing can be:
l When an entity is created.
l When an entity field is changed.
The value can be a new value, empty, or a copy of another field's value.
Example

Space configuration
Action Description
Trigger ALM Octane supports webhooks for integrating with other applications.
Webhook Configure the webhooks by creating a rule with the Trigger Webhook action.
Configure the following:
l The events that call the URL

Events trigger the Trigger webhook mechanism to send HTTP or HTTPS
requests.
Specify the events using the Submission mode field. Valid events are: New,
Update, Delete.
l The connection to the URL

The URL of the service application that will receive the webhook. Enter a valid,
accessible URL.
Click Test Connection to verify the connection is successful.
l Credentials
Trigger Webhook rules support basic authentication. You can set credentials in
the Trigger Webhook rule and each Trigger Webhook request will include the
basic authentication header.
Credentials is the user name and password that ALM Octane can use to
authenticate the request, typically using basic authentication.
For details, see "Set up credentials" on page 309.
Note: Credentials are supported only when not using an integration bridge.
When using an integration bridge, the credential field is disabled.
Click Test Connection to verify the connection is successful.
l The request payload

By default, ALM Octane POSTS the following fields in the payload:
l ID
l Type
l Modified fields, including the original and changed values
Use Fields to select additional fields to send in the request payload.

Example
For details, see "Understand the webhook request payload format" on
page 583.
l Advanced settings for connecting to the URL (optional)

Space configuration
Action Description
l If the URL is publicly available to the ALM Octane server, no additional
actions are necessary.
l If the URL is not publicly available, choose Advanced settings to select an
integration bridge. For details, see "Set up the Integration Bridge Agent" on
page 311.
Note: When using an integration bridge, credentials are not supported. The
credentials field is disabled.
For end-to-end instructions on working with Trigger Webhook rules, review
"Trigger webhooks for other applications" on page 581.
Send Send an email if an entity is created, changed, or deleted.

Email
Submission mode is the trigger that causes the email to be sent.
Email recipients can be users defined in the project or users whose names appear
in fields' lookup lists.
The body of the email is generated automatically by ALM Octane.
Alert User If an entity matches the rule condition, an error dialog is opened with a message
you define. The entity cannot be saved until the user modifies the entity and the
entity no longer matches the rule condition.
Note: The condition should contain criteria that are not desirable. We want the
rule to alert users with an error dialog box only if there is a problem. The condition
specifies a problematic scenario, not a legitimate one.
You can have the rule alert users when an entity is created, changed, or deleted.
Submission mode is the trigger that causes the rule to run.
Tip: You can use this rule action to prevent a user with a certain role from
performing an action under certain circumstances. For example, if a rule action for
creating a user story is Alert User, and the rule condition indicates the release that
the user is not allowed to work in, if the condition is true, the user cannot work in
that specific release—even if generally, the user has permissions to do so for other
releases.
Example
Add Add a comment to the entity when an entity is created or updated.

Comment
Submission mode is the trigger that causes the comment to be added.

Space configuration
Action Description
Assign to Adds an item in the My Work module for the user assigned to the selected type
Users (author, detected by, owner, QA owner).
Block Prevent users from transitioning from one phase to a specific phase, even though
Transition the transition is generally permitted in the workflow for the entity.
Tip: To define phase-dependent rules, click the Workflow tab, select a phase or
transition for which you want to create a rule, and click the Rules tab.
Define a condition
A condition is made up of a field, an operator and a value.
1. Click Condition to start creating the condition.
Only one condition can be defined for each rule. But the condition can be a complex
condition: This means that you can have one condition with several parts, separated by And
and Or operators.
Select a field
Select a field on which to base the condition, or a special circumstance.
Special circumstances include:
Edit The condition is based on whether the current entity existed already and is
Mode now being edited, or if the current entity is new.
To check if new: Edit mode = New
To check if existing: Not(Edit mode = New)
Current The condition is based on whether a user is assigned a specific role.

User role

Space configuration
< The condition is based on how many related items of a certain type exist.
entity
> count Examples
l Counts
Find features not associated with any application modules:
i. Select the feature entity.
ii. Select Application module count for the Field value.
iii. Select the = operator.
iv. Enter the value 0.
v. Click OK.
l Counts of items related to other entities
Find features with tags that I created:
i. Select the feature entity.
ii. Select Tags count for the Field value.
iii. Click and then Add FIlter.
Tip: If no exists, another way to get a relative count is to select the

Filter operator. For details, see "Filter operators" on the next page.
iv. Select Author > Equal to > Me.
v. Select the > operator.
vi. Enter the value 0.
vii. Click OK twice.
Select an operator
Depending on the selected field or special circumstance, different operators are available. For
example, date fields display different operators than text fields.
In addition to typical operators (=, <, >, and so on), some fields support special operators,
such as:
contains Checks if the field contains the values you select from a list.
include Checks if the current user role includes the roles you select from a list.
Available only for the circumstance Current User Role.
is empty Checks if the field is empty.

Space configuration
is Checks if the field is modified from its original value. This operator is not
modified available for new entities.
Current You can set conditions that assess the original value of a field (when the
and entity was first accessed) or the current value of a field (because you may
Original have changed the field value since the entity was initially accessed).
operators l To base the condition on the original value, select an operator under the
heading Original in the operator drop-down list.

l To base the condition on the current value, select an operator under the
heading Current in the operator drop-down list.
Filter Available for count fields:

operators You can set conditions that count items related to the current item. For
example, you can count all features that have tests that I own.
a. Select the feature entity.
b. In the list of operators, scroll down and select an operator under Filter.
c. Select an operator, such as =.
d. Define a filter. For example, you can define a filter for Owner > Equal to
> Me.
e. Click Save.
Tip: If no Filter operators exist, you can filter the count by selecting the
icon. For details, see "Counts of items related to other entities" on the previous
page.
Set a value
In the next box, enter a value. You can enter a value or select one or more values from a list. If
you select multiple values, they are connected with an Or statement.
For user fields, you can enter [Current User] as a value. If necessary, add AND/OR expressions
to the condition.
If necessary, add AND/OR expressions to the condition.
As you build the condition, a textual representation of the condition is displayed in the
Description box.
Note: Conditions can evaluate to false if ALM Octane encounters a field in a rule
definition that it cannot process because the field does not exist. Sometimes this is
because a field was removed from the project. There are situations where this is not
an error, but part of the logic necessary to implement your organization's policy.

Space configuration
By default, rules are activated. For details, see "Understand rule activation and performance"
on page 578.
After you save the rules, ALM Octane automatically runs them.
Examples
Examples of creating rules are listed below.
Setting a subset of a Lookup list

Depending on the current team, certain item origins for defects are not available. For example, if a
certain team only works with ALM and ALM Octane, the item origins for that team's defects
cannot be Service Anywhere or JIRA. You can create a rule that makes only a sub-list of the
current lookup list available, based on the team.
Condition: If the Team field is a specific value...
Action: Select the Item Origin values that are relevant to that team.
Making fields required

Make the testing tool type required to prevent empty values for automated tests.
Condition: If the Testing tool type field Is Empty...
Action: The Testing tool type field is required.
Setting default field values

To make sure each manual test is assigned to an application module, set the Application modules
field value to a default application module for all empty statuses.
Condition: If the Edit mode for the test is New, it means the test was just created and...
Action: Set the Application modules field to General .
Triggering webhooks (calling a URL)

For webhook integration with another application when an entity is created, deleted or updated,
you can use a Trigger Webhook rule to POST a request to an endpoint URL. The service at the
URL receives the call and processes the request.
Condition: <None >
Actionable upon: New, Update, Delete
Action: POST ALM Octane entity information to the endpoint URL:
http://myServer:8081/myAPI.
For details on setting up Trigger Webhook rules to POST information to endpoint URLs as a
result of an event, see "Trigger webhooks for other applications" on page 581.

Space configuration
Switching forms
When a tester creates a defect to report a bug, organizational policy dictates that the tester be
able to view and edit the following fields: Description, and Severity.
Similarly, when a developer starts fixing a defect, the developer must be able to view and edit the
following fields: Fixed on, Fixed in Build, and Owner.
Define two rules:
l Rule 1: Sets a form for developers.
Condition: If the team is the Developer team...
Action: The form for developers is used.
l Rule 2: Sets a form for testers.
Condition: If the team is the Tester team...
Action: The form for testers is used.
Send an email when a item's attribute's are updated

When a user story, defect, or other item changes its status, you may want to be notified that such
an item has been updated.
To do this, you define it in one the following ways:
l If you want to be notified of any change in a specific field - such as the phase of an item - select
Is Modified as the operator for the field.
l If you want to be notified of a change in specified field to specific value - such as a defect
moving from Opened to Fixed - set the Original = field to the previous value and the regular
operator to = for a new value.
Prevent developers from closing a defect, while all other users can.
Developers should not be able to close defects, so we can create a workflow rule that blocks this
transition.
We recommend you create the rule from the Workflow tab for the entity. This way, the From and
To phases for the transition are already entered for you. Select the transition between Proposed
Closed and Closed, and add a rule using the Rules panel.
Condition: If the Current User Role includes Team Member...
Action: Block transition from Proposed Closed to Closed.
Allow testers to open defects on some releases but not others.

Testers work on different releases.

Space configuration
First, ask your space admin to make sure that the tester role has create/edit permissions for
defects. For details, see "Assign roles and permissions" on page 529.
Then we add an Alert User rule with a condition that lists the releases for which the tester cannot
update defects.
If the condition in the rule evaluates to true, the rule alerts the user that the updates violate the
specified condition and prevents all updates to the defect.
Action: Alert the user when creating, modifying or deleting a defect if the condition indicates a
problem (meaning, the condition evaluates to true).
Condition: If the Current User Role includes Tester, and Release equals a forbidden release, the
condition evaluates to true. The user is alerted and updates are prevented.
Next steps:
l "Understand rule activation and performance" below
l "Troubleshoot rules " on page 595
l "Create workflow rules" on page 565
Understand rule activation and performance

This section describes how ALM Octane decides which rule actions to perform and when to
perform them. It also discusses the significance of the order of the rules in the grid.
In this topic:
l "When are conditions evaluated and actions performed? " below
l "Does the order affect how the rules run? " on page 580
l "My organization has many rules. Any tips on how to list them in the grid? " on page 580
l "Do shared space rules or workspace rules take precedence?" on page 581
When are conditions evaluated and actions performed?

Most rules are evaluated on an ongoing basis and their actions are performed when necessary.
Other rules are evaluated after certain events occur.
ALM Octane evaluates rule conditions and performs rule actions in one of two ways:
l As users work, on an ongoing basis. ALM Octane checks to see if the conditions for activated
rules are being met. When conditions are met, rule actions are performed. Most rules fall into
this category (Make Read-only rules, Use Form rules, and so on).
l If certain events occur. In addition to evaluating the conditions of activated rules to make sure

Space configuration
the conditions are met, certain events must also occur for these rules' actions to be performed.
These events include the creation of a new entity, deletion of an existing entity, or changing an
existing entity.
Note: You do not have to specify a condition when defining this type of rule. The rules'
actions can be performed when the event occurs without any other constraints.
Examples include:
l Set Field Value rules. These rules change the value of a field as an entity is created or
changed. These rules' actions occur as soon as the operation is initiated.
l Send Email rules. These rules send an email if an entity is created, changed, or deleted.
These rules' actions are performed after the user clicks Add or Save.
l Alert User rules. These rules validate an entity when it is created, changed, or deleted, and
after the user clicks Add or Save. These rules' actions are performed after the user clicks Add
or Save.
The entity/context is considered valid if the condition is false. No alerts are sent.
If the condition is true, the user is alerted and updates are prevented.
Note: Moving an entity in the tree is not considered a change to the entity.
Activating and deactivating rules

By default, rules are activated when they are defined. To deactivate a rule after it is defined, select
the rule in the Rule list and click OFF.
When creating rules that determine if a field is required or read-only, only one rule can be
activated for a specific field.
For example, you cannot activate two rules on the field Priority, one making the field Priority
mandatory and the other making the field Priority optional, at the same time. Both rules can exist,
but they cannot both be activated.

Space configuration
Does the order affect how the rules run?

If an entity meets the conditions of several rules, each of the rules' actions are performed on that
entity in the order the rules are listed in the grid.
Example:
A rule checks if a defect is new (Edit mode=New) and if so, sets the input form to
TheAddForm. This form lets users enter the basic information for a defect, without getting
into details that are generally only known at a later time.
The next rule in the list checks if a defect is already in existence and being edited ( Not
(Edit mode=New) ). In this case, the rule sets the input form to TheEditForm.
A third rule checks if the Priority for the defect is 1-Critical and if so, sets the form to
TheCriticalForm. This form forces the specification of additional fields for explaining why
this defect is critical. This rule contradicts the setting of the second rule, because as it is the
last to run, its result is the one that is retained—even if the defect is not new.
My organization has many rules. Any tips on how to list them in the grid?
If your organization has many rules, organizing them a certain way can help you see what's
defined. You may find it helpful to organize your rule list according to how ALM Octane processes
rules. This has no impact on when rule actions run, but it may help you see the big picture.
This order also most resembles the way ALM Octane processes the rules "behind the scenes."
1. List the rules that occur after a certain event:
a. Rules that change field values as an entity is being created.
b. Rules that change field values when an entity is changed or deleted.
c. Rules that send emails.
d. Alert User rules, which validate an entity and alert a user if there is a problem.
2. List all other rules. These are the rules that are evaluated and performed on an ongoing basis.
Tip: You are likely to have many rules that set different lookup lists and sub-lists to
cover all scenarios. It's easier to read if these are grouped together at the end.

Space configuration
Do shared space rules or workspace rules take precedence?

If you have rules defined for a shared space, and rules defined for workspaces associated with the
shared space, it is important to understand which rules take precedence.
Workspace rules run first, before shared space rules run. If a shared space rule contradicts
the actions defined in a workspace rule, the shared space rule takes precedence because it is run
last.
Trigger webhooks for other applications

ALM Octane supports webhooks for integrating with other applications. Configure the webhooks
by creating a rule with the Trigger Webhook action. This topic provides end-to-end instructions
for setting up webhooks.
In this topic:
l "Overview" below
l "Configure proxies" below
l "Customize Trigger Webhook rules" on the next page
l "Set up credentials" on the next page
l "Install an integration bridge (on-premises)" on the next page
l "Understand the webhook request payload format" on page 583
l "Set up a web service at the endpoint" on page 588
l "As you work in ALM Octane, webhooks are triggered " on page 589
Overview
The webhook mechanism supports advanced workflow use case scenarios and enables
integration with other applications.
Trigger webhook rules send an HTTP/S request, with a payload in JSON format, to an endpoint
URL when an event occurs in ALM Octane, such as entity creation, deletion, or update.
At the endpoint URL, an application receives the requests and processes the information.
Configure proxies
On-premises: You may have to ask the site admin to configure your organization's proxy so that
outgoing requests are not blocked.
Proxies are set by modifying an octane.yml file and restarting the ALM Octane server. For details,
see the information about configuring other settings in the ALM Octane Installation Guide .

Space configuration
Customize Trigger Webhook rules

Admins can customize how ALM Octane accesses the endpoint URL with configuration
parameters.
You can customize:
l Whether ALM Octane sends outgoing request over HTTP or HTTPS, with WEBHOOK_
ALLOW_HTTP.
When using HTTP, use only the standard port 80 for outgoing requests,
l On-premises: At what point the HTTP/S request times out, with WEBHOOK_REQUEST_
TIMEOUT.
For details, see "Configuration parameters" on page 480.
Set up credentials
You may have to ask an admin to define credentials to be used for authenticating the request.
Trigger webhook rules support basic authentication. When you set credentials in the Trigger
webhook rule, each webhook request includes a basic authentication header.
For details, see "Set up credentials" on page 309.
Install an integration bridge (on-premises)

If the endpoint URL cannot be accessed by the ALM Octane server, install an integration bridge.
See "Set up the Integration Bridge Agent" on page 311.

Space configuration
Understand the webhook request payload format

When processing a rule with the Trigger webhook action, ALM Octane performs an HTTP/S
POST request to the endpoint URL. The POST includes a JSON request payload.
Tip: Use the alm-octane-webhooks-listener tool to simulate the web service and to see the
structure of the request payload. For details, see "Listen for ALM Octane webhooks" on
page 589 and this video:
Different payloads are sent depending on which event triggered the webhook.
Event Request payload

Create By default, the Trigger webhook action includes only basic fields, such as ID and
entity type.
Delete By default, the Trigger webhook action includes only basic fields, such as ID and
entity type.
Update By default, in addition to the basic fields, such as ID and type, the Trigger
entity webhook action includes a set of "before/after" changes.

Space configuration
When creating the Trigger webhook rule, you can select additional fields to include in the request
payload by specifying Fields.
Payload format example

Sample payload for an update event
Parts of the payload
The payload for an update event consists of the following parts:
Part Description
Header Sent with every Trigger webhook rule, and consists of:
information
l server_url
l event_type
l username
l sharedspace_id
l workspace_id
Basic Fields that are sent with every Trigger webhook rule. These fields include:
information
l id
l type
Additional Additional fields that you can add to the request payload, using Fields when
information setting up the Trigger webhook rule.
Changes If the event_type is update, the changes field is included in the request
payload.
The changes field includes the set of changes, including the values before and
after the update.

Space configuration
Sample payload, highlighting usage of various field types

Field
type Sample snippets
Primitive Basic system fields, such as id, type, last_modified.
"changes": {
"last_modified": {
"oldValue": "2017-12-26T15:51:22Z",
"newValue": "2017-12-26T15:49:22Z"
}
}
User User information.

"detected_by": {
"id": 1991,
"type": "workspace_user",
"email": "MyEmail@MyCompany.com"
}
"changes": {
"detected_by": {
"oldValue": null,
"newValue": {
"id": 1002,
"email": "YourEmail@YourCompany.com"
}
}
}

Space configuration
Field
List node Object of type and ID, such as phases.
"phase": {
"type": "phase",
"id": "phase.defect.new"
}
"changes": {
"phase": {
"oldValue": {
"type": "phase",
"id": "phase.test_manual.new"
},
"newValue": {
"type": "phase",
"id": "phase.test_manual.planned"
}
}
}

Space configuration
Field
Multi-list Total count in addition to the array of list nodes, such as the list of test types.
nodes
"test_type": {
"total_count": 2,
"data": [
{
"type": "list_node",
"id": "list_node.test_type.performance"
},
{
"id": "list_node.test_type.regression"
}
]
}
"changes": {
"test_type": {
"oldValue": [
{
},
{
"id": "list_node.test_type.regression"
}
],
"newValue": [
{
}
]
}
}
Reference Object of type and id, such as release.

"release": {
"type": "release",
"id": "2002"
}

Space configuration
Field
Multi- Total count in addition to the array of reference entities, such as application
reference modules (previously known as product areas).
"application_modules": {
"total_count": 2,
"data": [
{
"type": "application_module",
"id": "2002"
},
{
"id": "2001"
}
]
}
"changes": {
"application_modules": {
"oldValue": [
{
"id": 1001,
"type": "application_module"
}
],
"newValue": [
{
"id": 1002
}
]
}
}
Set up a web service at the endpoint

Set up and run a service at the endpoint that receives the requests and processes the information.
We recommend that you use an HTTP client tool like Postman or Telerik Fiddler for developing
and testing the web service.
When setting up the web service, follow these guidelines to ensure that the webhooks are
triggered:
l The service sends an HTTP/S response quickly so that ALM Octane does not misinterpret the
delay as a failure and keep retrying.

Space configuration
l The service must return a valid HTTP/S response so that ALM Octane does not misinterpret
the response as a failure of the webhook itself.
To avoid potential abuse, ALM Octane provides a protection mechanism that blocks URLs if the
above guidelines are not followed.
Tip: Use the alm-octane-webhooks-listener tool to simulate the web service. For details,
see "Listen for ALM Octane webhooks" below.
As you work in ALM Octane, webhooks are triggered

After configuring the items and settings described above, your work in ALM Octane triggers the
webhook rules you created in ALM Octane Settings.
See also:
l "Access and credentials" on page 305
l "Set up the Integration Bridge Agent" on page 311
l "Configuration parameters" on page 480
l "Listen for ALM Octane webhooks" below
Listen for ALM Octane webhooks

ALM Octane provides a tool for learning how the ALM Octane webhook mechanism works. This
topic describes how to use this tool to help develop your own services for integration with ALM
Octane.
In this topic:
l "Overview" below
l "Install the listener" on the next page
l "Run the listener" on page 591
l "Update the Trigger Webhook rule to call the listener" on page 592
l "Trigger the webhook" on page 592
Overview
The alm-octane-webhooks-listener tool helps facilitate your understanding of how ALM Octane
webhooks work.
The tool simulates how a server application would listen for webhook requests.

Space configuration
Using this tool, you can:

l Test out the triggers for your Trigger Webhook rules.
l See the structure (payload) of the ALM Octane webhook request as it will look when sent to
your server.
l See notifications in the alm-octane-webhooks-listener console.
l Use it as a basis for developing your own services.
Basic authentication is supported.
Install the listener

1. Prerequisites:
l Enable the http protocol for Trigger Webhook rules by setting the WEBHOOK_ALLOW_
HTTP configuration parameter. For details, see "Configuration parameters" on page 480.

l Install Node.js version 7.10.1 or later.
2. Clone or download the repository locally: https://github.com/MicroFocus/alm-octane-

webhooks-listener
3. Start node.js.
4. In the node.js command window, navigate to the alm-octane-webhooks-listener directory.
5. Run: npm install

Space configuration
Run the listener

In the alm-octane-webhooks-listener directory, run:
node app [options]
Option Description
--port Port to use.
Default: 8080
--rcode Response status code.

Default: 200
-u Username for basic authentication.

Default: none
-p Password for basic authentication.

Default: none
--verbose Print request headers and body.

Default: no
--help Print help and exit.
Example: node app --port=8090 --verbose -u user@domain -p secret
You can now see notifications in the alm-octane-webhooks-listener console.
Example: Getting the listener's URL

Generally, if your ALM Octane installation is on-premises within the same corporate LAN as the
node.js, you can use the IP address from the alm-octane-webhooks-listener console as the URL
for your Trigger Webhook rule.
If you are using ALM Octane as SaaS, make sure your alm-octane-webhooks-listener is accessible
from the internet. In this case the IP address may be different from those proposed by alm-
octane-webhooks-listener. Contact your network admin for the URL.
Command
node app --verbose
Response

Space configuration
Starting up the alm-octane-webhooks-listener.
Available on:
http://12.34.56.78:8081 (Ethernet)
http://87.65.43.21:8081 (internal)
Press Ctrl-C to stop the server
Example: Starting the listener with credentials
node app --port=8090 --verbose -u user@domain -p secret
Update the Trigger Webhook rule to call the listener

In the Trigger Webhook rule, update the rule action with the URL of the listener.
To get the URL of the listener, see "Example: Getting the listener's URL" on the previous page.
After entering the URL, you can click TEST CONNECTION.
Upon success:
l The message Connection succeeded is displayed in ALM Octane Settings.
l A notification similar to the following displays in the alm-octane-webhooks-listener console:
[18-Mar-2019 13:18:06.352] POST /?test=true "Apache-HttpClient/4.5.2

(Java/1.8.0_161)"
Received headers:
{
"content-type": "application/json",
"content-length": "0",
"host": "12.34.56.78:8081",
"connection": "Keep-Alive",
"user-agent": "Apache-HttpClient/4.5.2 (Java/1.8.0_161)",
"accept-encoding": "gzip,deflate"
}
Received empty body.
Trigger the webhook

Each time the webhook is triggered, a notification displays in the alm-octane-webhooks-listener
console.
Review the notifications and the payload and use this information to develop the service.

Space configuration
Example: Sample notification after adding a defect

If the Trigger Webhook rule has a Submission mode of New, and the Fields are set to Defect type,
Description, Detected in release, and Name, a sample response would be:
Received empty body.

[18-Mar-2019 13:28:38.570] POST / "Apache-HttpClient/4.5.2 (Java/1.8.0_161)"
Received headers:
{
"host": "12.34.56.78:8081",
}
Received body:
{
"server_url": "http://my-octane-server.net:8081",
"event_type": "create",
"sharedspace_id": 1001,
"workspace_id": 1002,
"username": {
"id": 1001,
"email": "josephine@TheCompany.com"
},
"data": [
{
"entity": {
"type": "defect",
"name": "My New Defect",
"description": "<html><body>This is my new defect. My listener will
find it when added.\n</body></html>",
"id": "2846",
"detected_in_release": {
"type": "release",
"id": "2001"
},
"defect_type": {
"id": "list_node.defect_type.Escaped"
}
}
}
]
}

Space configuration
Example: Sample notification after updating a defect

If the Trigger Webhook rule has a Submission mode of Update, and the Fields are set to Defect
type, Description, Detected in release, and Name, a sample response would be:
[18-Mar-2019 13:35:54.892] POST / "Apache-HttpClient/4.5.2 (Java/1.8.0_161)"

Received headers:
{
"host": "12.34.56.78:8081",
}
Received body:
{
"server_url": "http://my-octane-server.net:8081",
"event_type": "update",
"sharedspace_id": 1001,
"workspace_id": 1002,
"username": {
"id": 1001,
"email": "josephine@TheCompany.org"
},
"data": [
{
"entity": {
"type": "defect",
"severity": {
"id": "list_node.severity.urgent"
},
"name": "My New Defect",
"id": "2846",
"defect_type": {
"id": "list_node.defect_type.Escaped"
}
},
"changes": {
"severity": {
"oldValue": {
"id": "list_node.severity.medium",
"type": "list_node"
},

Space configuration
"newValue": {
"id": "list_node.severity.urgent",
"type": "list_node"
}
},
"last_modified": {
"oldValue": "2019-03-18T11:28:29Z",
"newValue": "2019-03-18T11:35:44Z"
}
}
}
]
}
See also:
Troubleshoot rules
This section contains troubleshooting suggestions for issues relating to the ALM Octane rules.
In this topic:
l "Rules that validate (Alert User rules) do not seem to run. For example, entities with blank
required fields are created." below
Rules that validate (Alert User rules) do not seem to run. For example, entities with
blank required fields are created.
When using the REST API, work items (epics, features, user stories, and defects) can be created as
drafts. This means that ALM Octane bypasses validation rules to enable quick creation (POST) of
a work item. Later, when editing (or PUTting using the REST API), the validation rules are
enforced. For details on creating drafts and turning on/off the draft feature, see the information
about drafts in the Developer Help.
Next steps:
l The information about drafts in the Developer Help

Space configuration

Send Us Feedback
Let us know how we can improve your experience with the ALM Octane User Guide.
Send your email to: docteam@microfocus.com

ALM Octane User Guide PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ALM Octane User Guide PDF

Загружено:

Авторское право:

Доступные форматы

ALM Octane

Software Version: 12.60.4

ALM Octane User Guide

Go to HELP CENTER ONLINE

Restricted Rights Legend

Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.

UNIX® is a registered trademark of The Open Group.

ALM Octane (12.60.4) Page 2 of 598

Welcome to ALM Octane 22

ALM Octane (12.60.4) Page 3 of 598

Track build quality 36

ALM Octane (12.60.4) Page 4 of 598

Attach files to items 75

ALM Octane (12.60.4) Page 5 of 598

Define a requirement in Manage mode 98

ALM Octane (12.60.4) Page 6 of 598

Plan release and sprint backlogs 125

ALM Octane (12.60.4) Page 7 of 598

Create and run tests 154

ALM Octane (12.60.4) Page 8 of 598

ALM Octane (12.60.4) Page 9 of 598

Test Development 225

ALM Octane (12.60.4) Page 10 of 598

Assign statuses to test steps 253

ALM Octane (12.60.4) Page 11 of 598

Analyze automated test run results 278

ALM Octane (12.60.4) Page 12 of 598

ALM Octane (12.60.4) Page 13 of 598

ALM Octane (12.60.4) Page 14 of 598

ALM Octane (12.60.4) Page 15 of 598

Plugin overview 407

ALM Octane (12.60.4) Page 16 of 598

ALM Octane (12.60.4) Page 17 of 598

View sessions 473

ALM Octane (12.60.4) Page 18 of 598

About managing users 524

ALM Octane (12.60.4) Page 19 of 598

Set up lists 553

ALM Octane (12.60.4) Page 20 of 598

Send Us Feedback 597

ALM Octane (12.60.4) Page 21 of 598

ALM Octane (12.60.4) Page 22 of 598

• Set your language 62

Introducing ALM Octane

How do I use ALM Octane?

To understand how to use ALM Octane, read about the common

ALM Octane (12.60.4) Page 23 of 598

Set up the environment

Administrators should have a basic understanding of shared spaces and

On-premises Installation Software Version

ALM 12.55 CP5 12.55.8

ALM 12.55 CP4 12.55.4

ALM 12.53 CP3 12.53.20

Micro Focus DevOps Suite

ALM Octane (12.60.4) Page 24 of 598

What's new in 12.60.4

Roles and permissions

ALM Octane (12.60.4) Page 25 of 598

StormRunner When analysing results of automated StormRunner Functional tests, you

Pipelines and CI servers

Improved automated test assignment rules

Expanded TFS support

ALM Octane (12.60.4) Page 26 of 598