Changing methods in Application Development

Atlassian Jira has become the de-facto tool for developers for managing their backlog over the last decade.  However, testers and quality assurance engineers have largely remained with their traditional tools or have had to fit their processes in with what the developers have given them.  For many Micro Focus (HP/HPE) Application Lifecycle Management or Quality Center was the go-to tool to manage manual as well as automatic testing.  Many companies are reaching the conclusion that large enterprise-grade applications such as ALM are becoming less cost-effective meaning that testers are having to find alternatives within Jira (through plugins which themselves have additional costs) or elsewhere.

Leveraging ALM Octane in the modern development ecosystem

Micro Focus has invested heavily over the last few years in the next generation of Enterprise Quality Management with the creation of ALM Octane.  Octane does not replace ALM/QC, but it does it give a leaner, more modern interface and capability for today’s more agile processes including full automation and DevOps.

ALM Octane was designed from the ground-up to be able to be integrated with almost any third-party tool by providing non-proprietary REST APIs and using the best-of-breed third-party tools to do what they do best.  For example, instead of running automation tests itself Octane uses Continuous Integration (CI) servers such as Jenkins or Bamboo.  Micro Focus’ expertise over the years has always been in producing the best Quality and Lifecycle Management solutions and that is what Octane focuses on.

Testers, Quality Assurance and Automation Engineers can use Octane to fully integrate with Atlassian Jira to make sure that the entire development lifecycle is covered and tested as well as producing deep analytics and insights through Octane’s dashboards.

Connecting the pieces

There are two integral parts of the puzzle that need to be set up to ensure that Octane and Jira work together seamlessly.

1. Synchronization

   For Epics, Features, Requirements, Stories and other entities to be fully covered and tested they need to be exposed in Octane.  This can be done using any synchronization tool that supports Octane and Jira, but we recommend Micro Focus Connect that has full support for Backlog and Requirement synchronization between the tools.

2. ALM Octane Jira Quality Insight Plugin

   Not only do testers need to know what they are testing but developers and other users of Jira need to know what has been tested and its status.  We would obviously encourage them to open Octane and get the information from there, but the reality is that people like to remain in their comfort zone and stay with what they recognize.  We have therefore created this Jira plugin that exposes the test status of the entity.

Creating the Relationships

Now that the four basic parts have been installed and connected, we can now begin to think about how Octane’s functionality can be utilized.

When thinking about synchronizing between Jira and Octane the first instinct might be to synchronize all backlog entities bi-directionally.  However, in most cases this is not beneficial and can even add complexity to the system.  Generally, there are two or three levels of hierarchy in the development backlog:

1. Epics
2. Features
3. User Stories / Defects / Quality Stories / Requirements
4. Tasks

Epics

Epics are defined to be broad statements of work that can span many iterations and teams.   It is not always the case that they can or even need to be tested using traditional manual or automatic tests.  Obviously, your mileage could vary but, in many cases, there is no need to bring Epics that have been defined in Jira into Octane for testing.  They don’t contain any relevant information for testers and just add noise to the system.

Features

Features should be testable and are therefore a better candidate for synchronizing to Octane.  Even though they cover a large scope Features define functionality that should be tested for regressions, integrations with other features as well to ensure that the end-result matches the authors intent.  The paradigm of Behavior Driven Design (BDD) for example has become extremely useful to cover these types of general testing.  The feature can be written in Jira, automatically synced to Octane and within Octane BDD scenarios can be written and then tested.  The result will then be exposed in Jira so that the stakeholders know that the feature has been implementated correctly.

Backlog Items

Stories are generally more centered on the specific use-case and are therefore more suited for automation testing.  Manual testing does play a role, but a developer should create a suite of automatic tests that cover the functionality defined in this entity.  These could be Unit Tests to check the code or Automatic Functional Testing.  When a defect is found a test is written to ensure that the defect has been fixed and does not regress at a later stage.

Tasks and Sub-tasks

Tasks and sub-tasks are generally small units of work that are only relevant at the time of development.  A test or suite of tests are generally written to cover the enclosing entity and its functionality.  The granularity that tasks expose is generally not relevant to be synchronized between the two systems.  They exist in both Octane and Jira and should be used but we do recommend not to synchronize them.    

Matching the hierarchies

By default, Jira does not have the concept of “Features” but only “Epics” and child Backlog Items such as Stories and Defects.  Features can also be customized to be on this level adding to the complication.  This causes a discrepancy between Octane and Jira since Octane has three levels: Epics, Features and Backlog Items.  We recommend that the synchronization should be configured as follows:

This can lead to confusion since the concept of Epics and Features take on different meanings.  A good solution is to use Octane’s white-labeling feature that can be used to rename Octane’s Features to Epics and the original Epics to something else; Themes for example.  The features that have been synchronized from Jira (Epics there) are added directly to Octane’s backlog.

Synchronization Direction

Notice that Jira’s Epics and Stories (and other equivalent entities) are synchronized one-way to Octane but Defects are bi-directional.  Epics and Stories are normally created and managed in Jira.  This includes cycling through the lifecycle phases (New, Open, Closed, etc.). Since the management is done in Jira these entities should be read-only in Octane.  The entities are synchronized to Octane in order to create the test coverage.  An exception to this can be when the entities have the testing phases as part of the lifecycle.  For example, “Ready for Testing,” “Testing” and “Tested”.  In this case it would be ideal that the testers update those phases in Octane only as that section is being managed specifically there.  The phase changes should be synchronized back to Jira (and perhaps made read-only in Jira for that section).  MF Connect can be configured to ensure that only these phases can be altered in Jira through synchronization and nothing else. 

Defect Synchronization

Defects, however, are part of the testing and quality assurance process.  Let’s look at typical development flow (some phases of the lifecycle have been omitted for brevity):

1. Story is created in Jira
2. Story is synchronized to Octane
3. Tester creates a test and then runs the test (manually or automatically) in Octane
4. Test fails and Tester opens a defect in Octane
5. Defect synchronized back to Jira
6. Defect is fixed and marked as such in Jira
7. The Defect is synchronized back to Octane
8. Tester tests that the defect has been fixed in Octane

Defects can be created by the developers or testers so they should have full visibility in both environments. 

The relationship between the opened defect and the feature or user story that it is connected to is essential.  When a Defect is opened in Octane or Jira the user can connect it to an existing entity ensuring coverage.  This relationship is also synchronized to ensure that the developer understands the context of the opened defect, and in Octane coverage can be gained into which stories and features have had defects opened and their subsequent coverage.

Octane Quality Insight Plugin for Jira

Now that the relationship between Jira and Octane has been created Octane can be utilized for its superior testing and reporting capabilities.  These will be covered elsewhere (hopefully…) since they are agnostic to the Jira integration.  However, we can delve a bit more into the information that the Quality Insight Plugin gives.

The plugin does not rely on synchronization per se but does need some way of connecting the connected Jira and Octane entities.  This is normally done by adding a User Defined Field (UDF) in Octane that contains the original Jira ID.  The plugin can then perform a lookup between the Jira entity and the corresponding mapped Octane entity.  As we have seen this is normally created by synchronizing the entities between the two but there are some use-cases where the entities are updated in Octane using different methods.  In any case when the Jira developer looks at an entity in Jira, she can see immediately its quality status.  She does not need to know how or where the entities have been tested but knows that her work is covered, and that she is getting the correct feedback necessary to move the phase to Done.  In the best case she will click on the link that will take her to Octane and she can begin to discover the fantastic capabilities that Octane can provide to her as well!

DevOps Insights in Octane

Octane offers deep insights into the status of development and testing which is increasingly relevant as the trend moves towards DevOps.  Octane enables actual work done to be connected to its commits in the Source Code Management (SCM).  Users can see exactly how their commits influence code stability.  Build or Test Failures can be accurately pinned down and corrected easily.  This is done using commit messages that contain the ID of the entity that is being worked on.  If developers are using Jira to manage their backlog, then they are far more likely to use Jira’s entity IDs.  This is not a problem for Octane since it can parse the Jira pattern and connect it to the synced entity even though it is using Jira’s ID.  This means that Octane’s advanced DevOps capabilities such as Log parsing, Defect Fixing Rates and Build Failure Analysis can be useful even to developers and managers.

Conclusion

We have seen that testers and QA Engineers do not have to be an afterthought when it comes to modern application development.  By connecting Jira and Octane, testing and quality can be brought into the modern era whilst keeping developers happy with the tools that they are used to.

Jira and Octane – better together!