ALM Octane - The Basics for Developers

The Developer license enables backlog management, defect management, DevOps pipeline management, and manual testing execution. The Developer license is a named license that is added on top of a core Pro or Enterprise license.

Includes the following:

Assigned items. User stories, defects, quality stories, or tasks in the New, In Progress, or In Testing metaphases.

To see items from other metaphases, create a rule to display the items included in these phases. For details, see Design business rules.

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.

Other user items. Any other item that you explicitly added to your My Work.

Right-click an item in the Backlog module and select Add to My Work.

ALM Octane integrations overview

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.

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.

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.

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

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

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.

Use cases for tracking commits Here are a few ways that you can use commit tracking information:

Note: Most roles can be customized. Roles and their permissions might be different for your organization.

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. As a dev team leader, view the team members' commits and how they relate to the items in the team backlog. As a developer or DevOps engineer, match build failures to specific changed files and specific backlog items.

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

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. As a project manager or PMO, identify features with risky commits and consider increasing testing on these features, or postponing their release.

Track pull requests in your SCM system If your Jenkins server works with a Source Control Management (SCM) system using pull requests, ALM Octane can help you track pull requests that are related to your backlog items. For example, if QA wants to verify that a feature is complete, they can check that all pull requests were merged and there are no open pull requests.

Prerequisites

• Make sure a pipeline was created on a CI server that works with an SCM system. For details, see Create and configure pipelines.

• When committing a change to your SCM system, the commit message should include one of the patterns defined on the DevOps > SCM Change Patterns settings page.

• You can modify the default commit message patterns using Java regular expressions. For details, see Customize SCM change patterns.

  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.

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.

Integrate your testing framework as part of the pipeline into ALM Octane.

The Testing Tool can be such as Selenium, Cucumber, etc.

If your CI server job is parameterized, you can define different sets of parameter values that can be used when running the pipeline job. Each pipeline can have multiple sets of parameter values.

For example, suppose you run a job on one deployed environment, and other times on another. You can create one data set (Set 1) using the default URL and port, and another (Set 2) with a different URL and port. You can then run the pipeline a few times using different settings.

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.