No-code integration platform for rich bi-directional sync
Zero downtime migration to tool of your choice
Keep Historical Data, Without Slowing Down Your Tools
Migrate or restructure Azure DevOps Instances
Real-time, context-rich data lake for AI or analytics
By Role
Accelerate delivery with clear insights
Transform smarter with a connected digital thread
Confident transitions for every enterprise change
By Initiative
Modernize and move to cloud without disruption
Build a compliant digital thread for complex environments
Build the foundation for smarter AI
By Domain
No-code integration across teams & systems
Enable collaboration between IT, support & business teams
Connect PLM & engineering teams for smarter products
Ensure regulatory compliance from start to release
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
The defense industry is entering a pivotal phase with the introduction of DoDI 5000.97, mandating the shift to Digital Engineering (DE). This article examines the challenges, including tool interoperability and data governance, and how suppliers can adapt through Intelligent Federation and integration platforms like OpsHub.
Eliminate siloes and collaborate effectively to scale agile practices by integrating Jama Connect with Micro Focus ALM (Also known as Micro Focus ALM / QC and Micro Focus ALM Octane). OIM fosters better team coordination and full traceability of requirements across the product delivery life cycle by integrating Jama Connect and Micro Focus ALM. Watch the demo video to learn how the integration of Jama Connect with Micro Focus ALM using OpsHub Integration Manager (OIM) enables product and business teams to get complete traceability of requirements throughout the ALM chain while development and QA teams gain the full context of customer requirements and priorities right inside Micro Focus ALM.
Schedule a 30-minute live demo with our integration experts
Let’s begin with the demo where the product team in Jama creates a feature under an existing portfolio, Epic. They will add the feature as a related item to the Epic, give it a name, set a description with some details of how the feature should exactly look like, set the priority, and save it. Next, we go to Jira, which is the development tool being used by the team, and the feature that was added by the product team in JAMA is synchronized to Jira also. Let’s go into the feature to ensure all the required details are visible. We have the feature title, feature description, a reference to the Jama ID, and a direct link to it. Its priority is set to “High”.
Next, let’s go to the QA tool, OpenText ALM (Formerly known as Micro Focus ALM, HP ALM) where the QA team also gets instant visibility into the newly added feature. All three teams can start working on it quickly. The QA team has some clarifying questions, which they add as comments, asking what the expected behavior is if the login fails three consecutive times. After saving, we return to Jira, where the development team is also reviewing the feature to ensure they understand it completely. While working on it, they see the comment from the QA team asking for more details. The development team would also add their comment for clarification by the product team.
Meanwhile, back in Jama, the product team is reviewing the feature and sees both the comments from the QA team and the development team. They reply with comments to address all the queries. Once all questions are answered, the product team transitions the feature to the “Approved” state. This “Approved” state will be reflected in both Jira and OpenText ALM, signifying the end of the first phase—requirement refinement. We go back to Jira to see the updated status, where the feature has moved to the approved status, and the development team can now start elaborating on it further.
We quickly check in QA, where the feature is also marked as approved, allowing the QA team to start writing the test cases. Returning to Jira, the development team begins creating stories for the given feature. They give the story a name and description with all the details of what they plan to develop and link it to the feature integrated from Jama. The development team continues to break the feature into smaller stories, providing a summary, description, and priority. Upon refreshing the feature in Jira, it is now divided into two stories.
Back in the QA tool, both stories created by the development team are visible, allowing the QA team to begin working on test cases. Similarly, in Jama, both stories are available under the feature. The QA team will now switch to the Test Plan module of OpenText ALM to start building test cases. They give each test case a name, description, and save it. Then, they add design steps to the test case, outlining the steps to be executed, along with the expected results. They repeat this process for another test step, specifying the description and expected results. The QA team then associates the first test case with the user story, “login through password.”
Once the first test case is ready, the QA team creates another test case for the second user story. They save the test case details as done for the first one, add design steps for the second test case, and link it to the second user story, “login through OTP.” Both test cases are now ready and saved. In Jama, the product team starts gaining complete visibility into the test cases as they are being written. The first test case, written to test an invalid password, appears in Jama with the test case name, description, and test steps, just as entered in OpenText ALM. The same is true for the second test case.
The product team in Jama now has full visibility into what stories are being developed for the feature, what tests are being done for it, whether all stories are tested, the test coverage, and the current test results. While the QA team continues working on test cases, the development team completes the development of the “login through password” user story and commits the changes in GitHub. They specify which file changes correspond to the Jira story and commit it.
Upon returning to Jira, the commit traceability is synchronized, and the development lead gains complete visibility into which files were modified, when the commit was made, and who made it. This traceability is also reflected in the product tool for the user story. Additionally, the commit message specifies that the changes for the story are completed, and the story is automatically resolved in Jira due to the GitHub-Jira integration. We return to the feature in Jama and manually resolve the next story, marking the work as completed in Q2.
The QA team notices that both stories are resolved and begins executing the test cases. Once the test cases are executed, their status is updated in OpenText ALM. Both test cases are marked as passed, and this information is synced back to Jama. The product team in Jama gains visibility that the stories are resolved, and the test cases have passed. The development team then resolves the feature, marking the completion of execution. This resolved status is integrated back into Jama and OpenText ALM to indicate that both the product and QA teams are aware that the implementation for the feature is completed.
In Jama, the feature is marked as “Resolved”, and upon returning to OpenText ALM, the QA team sees that the feature has been successfully resolved. Thanks
Schedule a 30-minute live demo with our integration experts
