Listen to this article
With the way the ALM business scenario has evolved over the years, there are two aspects of Application Lifecycle Management which have grown to attain a significant importance. Over the years, it has been seen that these factors have played a primary role in determining the efficiency of the entire ALM process. The factors that we are referring to are:
- Using best of the breed disparate tools for different aspects of the ALM Lifecycle.
- Integrating these multi-vendor tools, and automating the lifecycle process to the maximum extent possible with process workflows.
However, the stiffest of challenges has been to combine the above mentioned factors, and reaching to a desirable solution. Experts of the ALM domain have always considered it difficult to find a potential solution, which would contain the best of both worlds and address both the limitations.
The limitation of using best-of-breed tools is that, they are generally from various vendors and hence isolated silos. For example, an organization might choose to use Rational Requirements Composer for Requirements Management, Quality Center from HP for Test Management and JIRA from Atlassian for Defect Management. These are all one of the best available tools in their respective ALM domain, but the only problem while working on them together is to get them connected throughout the product lifecycle.
How does a tester working on HP QC know, pertaining to which Requirement from Rational Requirements Composer he is creating a test case? He will have to go back and forth between Rational Requirements Composer and HP Quality Center to get an idea of what he is doing. So these tools need to be connected to each other to ensure that everybody working in the ALM Domain is updated about the latest happenings of the ongoing project.
The other aspect which decreases efficiency of the ALM lifecycle process is human intervention. The need of the hour is to introduce automation in different phases of the ALM lifecycle. However, the question is, how do we do that? A technically feasible solution would be to strike a perfect balance between human effort and automation.
So, how does Kovair Omnibus address all these limitations and provide a clear view of everything happening around during the development lifecycle? To get an absolutely clear understanding of the same, let us look into a sample scenario and understand how Kovair Omnibus can increase the efficiency of an ALM lifecycle to a greater degree.
A Sample Scenario:
An organization uses Rational Requirements Composer (RRC) for Requirements Management. Once the Requirement is submitted in the RRC instance, the Requirement immediately gets reflected in the HP QC tool instance as a Test Requirement. So the first and foremost condition of the two disparate tools being in sync is achieved.
The benefit of using Kovair Omnibus is the fact that it can introduce a certain degree of automation to ALM processes. With the help of Kovair Omnibus, a user has the provision to define business rules. A similar rule can be defined by virtue of which Kovair Omnibus would automatically create a Test Lab and a Test Case with respect to the Requirement submitted in RRC. These Test artifact items would get inserted into HP QC. Additionally, to enhance traceability, the links between the Requirement and Test Plan and Test Lab and Test Plan are also established in HP Quality Center.
Now all that a tester needs to do is to create appropriate design steps pertaining to the Test Scenario already created in HP QC. Once that is done the test run can be executed in HP QC, to complete the testing process. However, the automation with Kovair Omnibus doesn’t stop here. HPQC doesn’t have the provision to automatically log a defect based on the result of the executed test run. A business rule can be defined with the help of Kovair Omnibus which will automatically create a defect based on the result of the Test Run. Thus a complete traceability from Requirements to Defect can be viewed from either of the tools. Moreover, every stakeholder is now aware of what is happening around between the tools and why. .
Furthermore, another step of automation can be introduced as a result of the defect resolution process. A business rule can be defined with the help of Kovair Omnibus which automatically updates the Requirement status in either tool to ‘Implemented’ on the defect being resolved.
The Cutting Edge:
From the above sample scenario it can be very well understood where Kovair Omnibus stands out amongst its competitors. The capability of Kovair Omnibus to define customizable business rules, in various stages of the ALM lifecycle domain, sets it apart from the rest. The advantage of being able to define this business rules or logic is the fact that it enables you to introduce a certain degree of automation, which is otherwise difficult in a multi-vendor tool environment. With tool integration gaining importance in the ALM scenario with every passing day, newer tools or platforms having integration capabilities are coming up thick and fast. However, an Integration platform having this ability to automate would always stay miles ahead of the competition.
Kovair Omnibus effectively reduces manual effort in similar scenarios, and achieves a greater degree of automation. This in turn increases the efficiency of the entire ALM lifecycle manifold. The advantage of using Kovair Omnibus lies in the fact, that apart from synchronizing different best-of-breed multi-vendor tools, it also allows you to enhance the efficiency of the ALM lifecycle by inducting above mentioned or similar scenarios in the ALM lifecycle process. There can be nothing better than synchronized tools working in tandem coupled with multiple automated scenarios. Kovair Omnibus ensures exactly that.
