What is our primary use case?
ALM Octane is used to manage our software delivery. Currently, we are running the hybrid mode. We use traditional waterfall delivery as well as agile.
- For waterfall delivery, it is managed completely. Then, we have our requirements and our test cases to cover those requirements as well as the defects.
- For agile, we currently have only one team. So, all team activity happens in ALM Octane. Their backlog is broken down into user stories tasks, then covered by the test coverage.
We have installed it on a Windows Server on our systems.
How has it helped my organization?
ALM Octane natively supports waterfall, hybrid, and agile software development perfectly at an enterprise scale.
- If you look at the Requirement module, then we see all the defects and test cases related to waterfall.
- If we look at the Backlog module, we see what the agile team works on.
- If you want to see it at the component level, then imagine that we have a CRM system where a release project of waterfall makes a delivery and the agile team also makes a delivery on that component.
- We come to the Quality module, where if you select that component, then both streams would be represented there.
- If you select in the Quality module components, then we could see that, "Okay, this is linked to the defects from this source and that source. These are test cases covering that."
This was one of the key aspects of why we took ALM Octane.
With ALM Octane supporting agile, this reduces complexity and the need to manage multiple tools. We are still working on some automation that would further make us more efficient. So, we are building in-house tools to reduce the manual work.
Our user experience has been greatly improved.
In the current organizational structure, our development teams and testing teams are separate. With this transformation, I think the collaboration will increase, and we are on our way to put these teams closer.
We are very much moving towards DevOps in certain parts of the application. We are starting to develop these microservices and running a proof of concept where we want to integrate our Jenkins pipeline, which builds and deploys the application into Octane. For example, if there is a defect in the content, then what defects are being deployed through this pipeline? Octane really supports DevOps with the Pipeline module using the comment information in the items, along with integration from the IDEs. So, once our PoC is done, then we will utilize the DevOps features.
What is most valuable?
Currently, we have our hybrid delivery model, where waterfall still is a big part. So, if I look at ALM Octane from the module perspective, we are utilizing this requirement module. We took our day-to-day, grouping them by releases. Our requirements are stored in Confluence and ALM Octane. So, our project managers draw their requirements in Confluence, then we have a synchronization where requirements are brought into ALM Octane. Therefore, from the module perspective, the most valuable feature would be the Requirements module.
We utilize dashboards for all their reporting capabilities to see where our software is from a quality point of view: test progress, defect trends, and so on.
We are big fans of the Pipeline module, where we have our automated tests running on Jenkins and our pipeline is integrated into ALM Octane.
Octane provides multiple plugins and integration with IDEs, so developers don't even need to log into ALM Octane, for certain scenarios. They only need to install the plugin into their development environment, i.e., Eclipse, Visual Studio, or IntelliJ. Then, they can sync their work items to this IDE where they can easily see what defects or user story is assigned to them. They can work directly from there by adding comments, changing the status, or even committing the code. This also applies to the pipeline for Jenkins.
There are a lot of predefined reports. We can attach additional reports for users, like who worked on what defect and when, as well as what is the status of the release compared to the previous release. It is really endless. All the data is really linked together. Then, if all the data is linked together, there is an option to prepare reports out of it. We are very impressed with its reporting capabilities.
They provide all data integration. So if you have an edge use case, which you cannot do with what the tool provides, then you can set your data through all the protocols and even prepare it for the reports. I think they are very strong in this area.
On a team level, it is really good. We have received only positive feedback from our teams. It is visual, so there are different ways for teams to see their backlog. If they wish, it can be viewed like a list and a board, where you can look at the content per screen, release, or for the whole backlog.
The tool is very intuitive. However, it is still new, so you still need to learn and explore it, but that is a standard thing. Initially, we did receive some questions from teams, "How do I do this?" and, "How do I do that?" However, in very recent times, since it has been up and running, teams have enjoyed the fast, modern, new platform.
For the PoC, we have ALM Octane integrating with our CI server for continuous integration and delivery. We have it integrated with Jenkins. We haven't integrated our other server yet. We are still exploring the solution.
What needs improvement?
ALM Octane is working to soon provide comment information, so we would really be able to see what piece of code was committed for a user story or feature. We are really looking forward to this, because it's going to give us a bit more traceability and transparency.
They don't support all IDEs yet. We have Visual Studio code, which is not supported, and loved by our developers. This integration is missing. We also had to do our own in-house integration with the Confluence. That is also something that they could add.
There are small things, like hiding different columns when it comes to the board. Currently, whatever workflow items you have defined in the board, you can collapse them, but a collapse line still appears. These small things would make a difference.
In certain areas, ALM Octane has a limitation how many items can be displayed. So, if I group something, then I'm limited to the number of items which I can see. Also, if I want to export in Excel, there is a limitation onis lines. I know it's 5000. Maybe the number is quite high, but if they could improve on those limits, that would be good.
For how long have I used the solution?
We did a migration around Midsummer. That was about six months ago.
What do I think about the stability of the solution?
It is very stable. With our current setup, we haven't seen any performance issues.
Very little maintenance is needed. No one does it full-time. We have five people who have the admin rights, then two people who act as a backup but don't really do anything.
What do I think about the scalability of the solution?
It is scalable. We can add additional nodes without a lot of effort, if it is required. There is an option to scale from a license point of view. From a hardware point of view, we can also add multiple nodes to support additional loads.
We have about 1,000 users.
How are customer service and technical support?
We have an excellent guy who helped us with the whole migration project. We have already built a good relationship with him, so much that we don't always go through the official channels. He still takes our questions via email if we need the clarification on certain things. Additionally, the official Micro Focus support channels are also good. We raised a couple of incidents, which were addressed by the team.
Which solution did I use previously and why did I switch?
In the past, we had ALM Quality Center to manage our waterfall deliveries. Once the company took the decision to do the transformation to agile, we needed a tool that could support both waterfall and agile, but not compromise functionality. This was a key factor why we took on ALM Octane. We knew that the transition to agile would not happen overnight and that we might be in the hybrid model for a while, which is the exact reason why we took on ALM Octane.
It is very much integratable. This was a piece that was critical for us because ALM Quality Center was used by our company for more than 10 years, and it was very easy to integrate. Before we could migrate to ALM Octane, we needed the integration to be in place for a new tool. There are different ways to integrate, through the REST API, plugins, or the MF Connect tool, which also comes with ALM Octane.
Because we were coming from a very old Quality Center version, we have become more efficient because the work can be done faster.
How was the initial setup?
The deployment was straightforward. The documentation clearly states the requirements regarding what hardware is required. Additionally, all the installation and deployment guides are good.
The deployment went through phases. First, we installed the system, which was pretty fast. After that, we migrated all the data from Quality Center, which was an additional task.
The upgrade was super fast. We were so impressed. We ran a test first, but after that, it took maybe 90 minutes altogether. That includes the backup of systems. Before the upgrade, we backed up our Elasticsearch because ALM Octane comes with Elasticsearch, and in our case, it runs on Unix machines. So, we backed up Elasticsearch, the data repository for all the attachments, etc., then took a snapshot of the database and the Windows machine, which was the longest part. Some of the snapshots, we did in advance, and some of the snapshots we did just prior to the upgrade.
We did two upgrades at once because we missed the previous one. The upgrade to 15.1.20 took about 10 minutes, then we did some checks and everything was working fine. We then did the further upgrade to 15.1.40, which was another 10 minutes.
What about the implementation team?
One person with a bit of hardware knowledge can do the deployment. Because we did a migration project, we had a team of four from release management, but this wasn't our full-time task.
We also had support from Micro Focus.
What was our ROI?
The testing team has said that can work more efficiently and that the setup of the testing at the beginning of the release is faster.
Which other solutions did I evaluate?
We already had Jira in-house, but its testing capabilities were insufficient and not scalable enough for our needs.
What other advice do I have?
Define the process which fits your organization best. Explore the features in the test management and test execution area, then define the process that is best for you because there are a lot of options. Also, when you do create your data, make sure that you connect it to the right items. Because once you put the correct data into the tool, then you can build strong reports. However, the reports are only as strong as the data behind them.
MF Connect, which is a separate tool from Micro Focus, provides additional data synchronization. With MF Connect, you can synchronize ALM Octane with Excel, Jira, and other tools. We use it for synchronization with Jira. Then, if this doesn't support your needs, there is also the REST API. We use that quite a lot as well. Through the REST API, we connect with things in different solutions.
While our manual testing time has been reduced, it is necessarily true because of ALM Octane. It is more due to a bigger initiative where we have automated our test cases. ALM Octane supports our automation initiative. With the pipelines, we can execute test cases through Jenkins, then the analytics in the pipelines give us a trend to see. For example, are certain test cases constantly failing? Or, do we have a problematic area where we need to strengthen the automated test focus?
ALM Octane would give us information on what exactly went into which release and what exactly needs to be rolled out. For all our test cases that need to be executed for the release, or on the release night, we would hold information within ALM Octane.
We are planning to increase usage in the future. Currently, our other agile teams use Jira. The goal is that if we do not migrate those teams to Jira, then we should at least integrate both those tools together. We would then manage all the agile work within ALM Octane. Also, our organization recently got acquired by another organization, so we are in the process of merging two companies. Therefore, there potentially will be a lot of additional users going forward.
I would rate it as a nine (out of 10).
Which deployment model are you using for this solution?
Which version of this solution are you currently using?