When it comes ALM Octane--Micro Focus' comprehensive lifecycle management platform for high-quality application delivery--the concept of Application Modules is one of the fundamental concepts and most powerful tools, if used wisely. So it’s important to model and use them correctly.

What are application modules?

The application module tree represents the timeless functional breakdown of the product that is being developed and tested.  Tip: If you previously used ALM/QC, you may have modeled application modules without knowing it! For example, a Test Plan tree (or a subtree) in ALM or a module/area/topic user defined field in defects, could represent an application module. Below, is an example of an application module tree for a messaging app:

The main way to look at application modules is through the Quality module, but any other module can be filtered according to application modules.

Use the Quality module to see:

• Detailed quality status for each application module
• Manual, Gherkin and automated tests in a certain module
• Defects assigned to the module
• Features being developed related to the module

Tip: If you’re only interested in specific areas, you can select them and hide the rest from the tree. Also, by clicking the Include Children button in the toolbar, you can switch between seeing the directly related items, and all items (meaning the items related to sub modules).

You can use the out-of-the-box widget, Quality by Application Module, in the main dashboard to see an overview of all modules and quickly identify those that need attention. The widget is configurable, so that you can decide which areas are red (need attention). For example, you can decide that the size of the area is according to the story points developed in a certain release and an area appears as red if there are Critical open defects, low automation or risky commits.

Understanding traceability to application modules - Common Flows

To understand test traceability, let’s look at the following, typical, examples:

Manual test

• The backlog owner creates a new feature and assigns it to an application module.
• A tester creates a manual acceptance test for the feature (or one of its user stories) in the Backlog module. The test automatically inherits the feature’s application module
• Now the test can be seen from the feature to understand feature coverage and also from the application module to understand the area coverage.

Automated test

• A new, automated test is created by the developer.
• A test is being run in the CI and results are injected into ALM Octane.
• The test appears under the Unassigned application module.
• The DevOps admin adds a test assignment rule to assign all tests from the same package and class to a certain application module.
• The automated test is now assigned to an application module. All new tests from the same class will be automatically assigned, too.

Regression suite

• A test lead creates a test suite to cover a certain area.
• The test lead assigns the test suite to the application module and adds the relevant tests.

Building and maintaining the application module tree

The application module tree is usually managed by the Quality Owner persona. Sometimes, it might take several iterations until everyone is happy with the tree structure and granularity. 

Tip: During this phase, use drag and drop to easily restructure the tree: drag application modules in the tree, drag items from the grid to the tree.

Tip: At some point, you may want to consider making the Application Modules field required for features (using a business rule). This way you get the most out of the traceability-based insights that Octane can provide and most of the tests created in Octane will inherit the correct modules from the features and user stories. 

Confused as to if something should NOT be an application module? Think about this: If you run into a situation where you need to duplicate application modules, tests or suites, there's generally a better solution. Rather than copying a suite, see if you can reuse the same suite. Suites in ALM Octane are intended to be reused. Create a suite once, and plan multiple suite runs to represent testing events for different releases and sprints.

Tip: Once you plan a suite run, you can edit the planned runs. You can delete runs that are not relevant and duplicate runs you want to run on different environments.
Tip: If you would like to add a test to a suite run after it was already planned, use the context menu of the test in the suite and select “Add to Existing Suite Run.”

If you find that you need to copy a test, see if you can reuse the same test! Manual and Gherkin tests in ALM Octane support versioning. Each time you make changes to a test, a new version is saved. You can also label certain versions and assign them to releases. You can run different versions of the same test against different releases.

Need to copy an application module? See if you can use another way to label the tests. You can use user tags and user defined fields to add different properties to tests.

If you have a name of a specific application version or release inside the application module tree, it’s usually a sign that there could be a better way to structure it. Note that application modules should be timeless. The same application module contains features and backlog items from multiple releases. A test that belongs to an application module has a status in each release you select.

ALM Octane has a mechanism for managing testing configurations called, Environments. Environments are assigned to manual and automated runs and also to defects.

Tip: Use the right pane filter to quickly see the status of selected tests on a certain Browser/OS/etc.
Tip: The Quality Owner is usually responsible for managing Environments. You can do this from the Settings menu in the masthead, under the Management section, using Environment list.

FAQs

Q: My epics look the same as the application modules? Is one of them redundant?
A: When you first start using ALM Octane, in the first release you manage, odds are there will be a lot of similarity between your backlog high level items (epics, features) and application modules. But as you go forward, in each new release you will create less and less new application modules, until the tree stabilizes; whereas lots of new features will be created for each release. Each release targets only specific epics whereas application modules are timeless and you will need to spot any regressions in areas that were not directly changed in a certain release.

Q: Tests are everywhere – Quality module, Backlog, Requirements, Team Backlog, Pipelines…Which one should I use to manage my tests?
A: Use the backlog or team backlog to create acceptance tests and track coverage for new content. Use the Quality module to manage all tests, plan regression events and track quality per area. Use the Pipelines module to track the status of pipelines in the CI and analyze automated test failures. Use the My Work view to see, for example, the test runs assigned to you for execution or the tests that are ready for automation.

Q: Where did Test Plan and Test Lab go? How do I see the status of the tests?
A: In ALM Octane, we no longer have the separation between a test repository and a test execution area. You can create your test anywhere in the relevant context (e.g. under a user story) and run it anywhere (e.g. as part of a regression suite). To see the status of the test, look at the Last Runs. The Last Runs bar is dependent on the context, so if you select a release and a subset of environments, you will see the status of the test for that release and for those environments.

Q: We are actually managing multiple applications or products in the same workspace. How should we build the application module tree?
A: We are considering several solutions for this issue. Meanwhile, assuming that there are a lot of items shared between the teams and you decided everyone works in the same workspace, it is recommended to create a top level application module per application. If in doubt regarding the proper way to structure your projects, consult your Micro Focus representative

Q: Why are there only three levels in the tree?
A: We believe three levels are enough in most cases. Too many levels may make the tree hard to maintain. However, if your product is super complex and you require additional levels, we are planning to add the option for administrators to configure the number of levels.

Q: I am fully Agile. Why would I need anything beyond the backlog to manage tests?
A: Even if you’re fully Agile, DevOps, full automation you probably have a need to understand which areas in the application are affected by a certain test failure or defect

Q: Can I link a test/defect/story/feature to more than one application module?
A: Sure! For example, the same test can cover different areas.

Q: What if I’m not using the backlog and I use Requirements?
A: Same concepts described in this post apply. Use the Requirements module to create acceptance tests and track test coverage, instead of the Backlog.

I hope you enjoyed this blog post! You can delve into all things ALM Octane on our webpage. We have features, resources, a free trial, and more! Check us out for Enterprise Agile Delivery!