Kovair Integrated Test Management Framework at “Step-In-Summit 2014: Testing Now”, Bangalore, June 26, 2014

by admin

Dear Friends of Kovair:

Kovair participated in the “STEP-IN SUMMIT 2014: Testing Now” Conference and Show at Bangalore, India June 26 to 27, 2014 with a presence of five of us. There were exciting guest speakers at this year’s summit. The focus of this summit was mainly on the current trends of testing within the emerging world of DevOps, Mobile, Big Data, and Agile. Different methodologies of testing like acceptance testing, exploratory testing were discussed along with how the role of today’s testers is changing.

Kovair Gold Sponsor at STeP-IN SUMMIT

At the conference, we noticed that one of the biggest pains in today’s entire delivery lifecycle is the lack of having an integrated test environment, where testers won’t need to work in silos or maintain things in offline mediums like MS Excel and can work in a collaborative manner with other cross-functional team members. Disparate technologies, developers, and deployment topologies have made today’s development environment even more challenging.

Bipin Shah at STeP-IN SUMMIT

We are happy that we could present our Integrated ALM solution as a fit to this burning problem. Bipin Shah, our CEO & Chairman gave a brief presentation to discuss the Integrated Test Management Framework offering from Kovair.

Kovair with its integration with 50+ multi-vendor ALM including Test and IT tools comprising of legacy, open source, and best-of-the breed enterprise class tools facilitates the developers and testers adopting a new testing strategy so that they can successfully manage change and deliver excellent quality. Kovair has developed a very light-weight but functionally-rich built-in Test Management capability which supports both manual and automated testing. Kovair’s Integrated ALM Framework helps organizations to achieve automation for all phases of the lifecycle from Conception to Development to Testing to Build and Deployment, thus facilitating today’s philosophy of Continuous Delivery.

Today, the demands of developing   bug free and well-performing product in short time frames have changed the entire model of delivery. Agility and the approach towards DevOps are the key aspects of software delivery model. Unlike the testing methodology that was followed in waterfall model, today, testing is introduced much earlier in the lifecycle. The testers are no more confined to work in silos and are becoming an integral part of the entire lifecycle.

Kovair has developed the solution of integrated ALM to help in effectively managing the entire lifecycle process. With Kovair, all cross functional teams can work in a collaborative manner without replacing any of their existing tools. Management can track the software quality through real-time reports generated out of data coming from different tools used for both manual and automated testing. Kovair with its Omnibus integration engine also bridges the gap between operations and development teams, thus helps organizations in adopting DevOps methodology.

We had a great conference with attendees showing considerable interest on our integrated platform that helps in creating a very synchronized and unified product delivery environment for globally distributed teams and facilitates real time collaboration, significant productivity and quality gains. We continue to pursue our goal to enhance your development environment without asking you to replace your existing tool set.

Thanks for your time to read this!


Amit Dasgupta

Director, Product Development

For accessing our PPT presentation at the Summit, please click on the following link: www.slideshare.net/Kovair/kovair-at-qsit-summit-presentation

To learn more about Integrated Test Management Framework offering from Kovair, download this document - Kovair Test Management : An Overview

Risk Mitigation During ALM Implementation

by Soumanil Chowdhury

Every organization managing projects is liable to face risks. It is a well-known fact that major risk elements are always involved in every phase of a project development and execution. Risks can be broadly classified into two major categories – predictable and unpredictable. Most of the project management teams remain prepared to address only the predictable risks, but often fail to address the unpredictable ones during ALM Implementation. Nevertheless, these unknown risks have a critical impact on the schedule, cost and delivery of the project.

It is understandable that not all risks can be defined and managed in time.  Project managers try to prepare Risk Management Plan for ALM  by efficiently elaborating the requirements and  then execute them. This is to ensure that most of the risks are predicted and controllable measures could be taken to prevent project failure. .

Requirements management for ALM is quite a challenging task for most of the organizations. Teams managing requirements have to face a lot of questions on a daily basis such as -

  • Are the customers’ requirements properly understood and prioritized?
  • Is the Project Planning being properly estimated with respect to schedule and cost?
  • How often rework is done by the development team due to the lack of clear understanding of the requirements?
  • Are the requested changes properly accommodated and impacts are analyzed and propagated to the correct levels?


Risk Management Techniques in Kovair

Fig: Risk Management Process for ALM in Kovair


The fact is that gathering and managing requirements efficiently is an absolute critical factor in developing all kinds of software applications and systems. Requirements are the basis of what needs to be produced that are requested by the customers and developed by the software development organizations. Many believe that requirements are actually the primary source of most of the project risks and defects. According to the researches done, a major percentage of rework effort is spent on rectifying the requirements related issues and the least is spent on fixing the code related defects.

Researchers have found that the cost to fix a defect increases if it is allowed to propagate through the software cycle. Moreover, surveys indicate that a post-production defect takes much longer time to fix with respect to the one being found in any of the pre-production stages.

Business Analyst Role in Risk Mitigation during ALM Implementation

In many instances, analysts start a project without having a defined set of requirements from the customer. Absence of such requirements specification documents can be highly risky for the project team as they remain confused about what is to be done and when to start the project related activities.

Here I will discuss some of the business cases that lead the project towards risk and how an analyst can play an important role in mitigating the risk by taking proper corrective actions.

1. Unavailability of Requirements Management Plan during ALM Implementation

The analysts must derive smaller plans for Requirements Management like Requirements Traceability, Requirements Impact Analysis and Propagation and Requirement Deliverables.

2. Changes in Baselined Requirements in implementation phase, after Sign off

Customers often send requests during the implementation phase to change even the baselined requirements and that too after the Business Requirements have been signed off.  However, not all change requests corresponding to the requirements in the baseline need to be included. Every change has to be placed to the Change Review Board for approval. After understanding and identifying the risks, if any, in implementing the change requests; those are to be taken forward for implementation in the current or future releases. Analysts can use a model to assess the risks and be ready to answer the degree of impact for the change.

3. Stakeholders are unable to communicate their actual needs

It is difficult for an analyst to be present in all the project meetings that are being held simultaneously by different stakeholders belonging to different groups. So the analyst should assign specific users who would be responsible for each of the elicitations and act as coordinator between the customer representatives and the project engineering team. The users would interpret the customers’ actual needs and convert those to functional requirements to the project team. If a proper documentation is not received from the customer, then this would lead to further confusion. The analyst would also escalate it as a project risk, if it resides as an issue during the project.

4. Contract and Scope Undefined for the Project

Once the project is formally declared to be started, the first step for the analyst would be to focus on reviewing the requirements and define the boundary scope. In the second step,  the analyst should clarify the original understandings and set the customer expectations, if there were any changes being requested through the Change Management procedure.

5. No Defined Prioritizations for Requested Enhancements

If you as an analyst are coordinating a project implementation, you should first pay attention to what the client needs now.  Most of the clients are unable to define their priorities correctly and often seek for what they ‘want’ rather than what they actually ‘need’. This may risk the project to a great extent.

An analyst has a very important role to play in this situation. Through regular meetings, he or she needs to negotiate with the client to define the priority list and segregate their requirements into various categories like Urgent, Very High, High, Medium and Low.This would help to set the customer expectation on one hand and the engineering team to deliver the items as per the priority on the other.

Project risks mostly occur due to unidentified risks during the Requirements gathering, analysis and planning phases. These can be mitigated if the analysts identify these early, and preventive measures are taken promptly.

Risk Management for ALM in Kovair


Kovair’s risk management solution simplifies the process of identifying, evaluating, managing, prioritizing and mitigating risks by allowing cataloging and responding to risks from a centralized repository. Its mouse click configuration allows organizations to configure specific project or business solutions as per defined risk mitigation strategies.

Kovair also helps automate all the phases of reviewing and monitoring risks on a regular basis and then continuously updates the risk plans. Kovair’s task based workflow automation reduces manual intervention in risk identification and monitoring, thus optimizes resources without compromising on risk management efficiency. Click here to learn more about risk management techniques in Kovair.

Multi Tool Process Automation for Integrated ALM

by Sayak Roy

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.

Process Automation between HPQC and RRC

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.

Traceability Relationships: What to Look for in a Requirements Management Tool

by Sanat Singha

Change is inevitable—especially in business requirements during software development. One can never stop change, but only view it, analyze its impact, and then learn how to cope with it. Unless you get complete visibility of the change items during requirements or build a strong traceability relationship between change records across steps, you cannot drive changes in a positive direction.

The immediate challenge to most development managers is not how to draw traceability relationships between artifacts. Instead, it is how to configure and optimize the relationships in simple mouse clicks that yield maximum return. Configurability; flexibility; and the ability to define relationship types, attributes, and levels play a vital role here.

Traceability Relationships

Fig: Traceability Relationship View

Many project owners fail in these disciplines because of ignorance, lack of proper guidance, and traceabilty limitations. To make the most out of a traceability relationship, you need to set new objectives and relate them to your current capabilities. Here are some guidelines about what to look for when you’re shopping around for vendor products.

Think beyond “Out-of-the-Box” Relationships

One size does not fit all. The business requirements of an organization may contain several different types and complexity levels. You must have the freedom to define relationships between any artifacts across different ALM tools, and without writing any code.

Customization is Key

The creation of new custom entities or artifacts is a continuous process in any development activity. Are you able to create a new relation field for a new entity and establish a relationship with an existing artifact in a few mouse clicks?

Relate Anything, Any Way, and to Any Extent

A big relationship tree can have many branches. Unless you can map each of those connections in all possible cardinalities, getting a complete traceability view is not possible. Ensure that you can relate business requirements to use cases, or vice versa, in any of the given combinations—one to one, one to many, many to one, and many to many.

View and Monitor Impacts Beforehand

Data make decisions. Wouldn’t it be great if you could see impacts both before and after changes occur? This is possible only when you can view and control what particular changes will create an impact. Automated user notifications for such events is a must.

Maintain Attribute Records of Artifacts

Attribute values of a record keep changing from time to time. Are you able to capture or maintain the snapshot value of attributes for artifacts in a relationship?

The bottom line is that if  you do not know what you need, you will never get it. List all the flexibilities you require in a traceability relationship and meet your vendor like a pro.

Do you think there’s anything I left out? Please leave a comment. 

Kovair’s ITSM Expert Ashok Srivastava Interviewed by Sophie Danby of SysAid

by admin

Sophie Danby, the Director of Online Communications, SysAid – a leading IT Service Management Company has recently interviewed Ashok Srivastava, the Senior Manager- Solutions and Services, Kovair on his ITSM views. Kovair thanks Sophie for conducting this interview session and is pleased to share the news with you all.


Ashok Srivastava

What exactly is your job?

I’m the Senior Manager – Solutions & Services at Kovair Software and work mainly on out-of-box solution creation and large customer implementations.

I’ve implemented fully customized solutions for both ITSM (IT Service Management) and ALM (Application Lifecycle Management) domains for large organizations. Typically I get involved at the inception of a project and capture the details of customer requirements and processes that they want implemented. I then prepare a plan and work towards implementing customers’ requirements and process workflows through codeless configurations capabilities; train organizational users and help them go live with the product.

I try to enhance our ITSM solution by implementing new features and ideas that I come across while interacting with customers or prospects. The internet also helps me keep abreast of everything that is happening around the ITSM world.

What is the best thing about working in IT Service Management?

The best thing about working in the IT Service Management domain is the opportunity to work with large enterprises. They usually have different requirements both in terms of fields / forms and process workflow definition. I specifically like brainstorming sessions on defining process workflows for IT Service Management process areas with client’s personnel, and contributing by sharing my knowledge and experience gained from earlier implementations. In the process I also learn a lot from client-specific requirements.

What do you think is the most important element missing from traditional ITSM? And why?

The global and distributed outlook is missing in the traditional ITSM industry.

Traditional IT Service Management System relies more on organization’s in-house expertise and is offered as a centralized service based on internal capabilities and people (roles). The processes here are defined exactly the way they are required by the organization with lesser chance of configurability and customization.

However, the modern IT Service Management system is more process oriented. It provides the catalogue of services and has built-in best practice processes and templates. This helps organizations to manage their IT Service Management operations in a better way. Moreover, modern ITSM practices help the industry to gain maturity and standardize the offerings.

What do you think is the biggest mistake that people can make in ITSM, and how can it be avoided?

I think the main mistake that organizations make is not properly documenting their requirements. With this, I mean to say that in the absence of proper relevant data and process definition, it’s unwise to expect any system to generate reports and dashboards as per organization’s requirements. Let me explain this with an example. An organization,that has customers located at different geographical locations across the globe wants SLA ‘s to have the facility to calculate time as per customer’s business hours. Now, if time zone and business hours are not captured in a master database, then implementing this requirement will not be possible. I’m therefore of the view that all requirements and use cases irrespective of criticality should be documented. This is to ensure that one can verify that all the requirements mentioned by the organization are taken care of and that a solution is being implemented.

What one piece of practical advice would you give to somebody working on the service desk?

My advice to service desk personnel is to focus on individual tasks, and work as per task based instructions and guidelines.They should also use the knowledgebase to find information about similar types of tickets and resolutions details that are logged in the knowledgebase. This helps in providing quick resolution.

What one piece of practical advice would you give to the CIO of a company with regards to ITSM?

My advice to the CIO of a company is to understand that automation in IT Service Management operations is important to keep track of process workflows that are implemented for managing different process areas of the organization. The efficiency level of those processes should be measured and analyzed on a regular basis. Continuous improvement and modification should also be part of the process workflow definitions based on the metrics data generated from process automation. Since processes mature with usage and time, it is crucial that changes in processes definitions are easily implementable in ITSM tools.

If you could change one thing about the ITSM industry as a whole, what would it be and why?

I would like OGC (The Office of Government Commerce) and itSMF (IT Service Management Forum) to introduce some sort of standardization for the ITSM industry. ITIL provides a generic framework and allows organizations to customize it as per their requirements. The standards should be in line with ISO Standards with properties of ITIL framework. The standardization would help in creating ITSM compliance requirements which would be beneficial for both the ITSM Industry and practitioners.They would have a clear idea on what needs to be done to achieve compliance, thus, both industry experts and practitioners would speak the same language (which would help in increasing productivity). ITSM standards would complement the existing ITIL framework,which would further help the ITSM industry to standardize its product offerings. The ultimate gainers would be the organizations using ITSM.

What do you think the ITSM trend to watch will be in 2014? And why?

The ITSM market will keep on growing and its focus will be on adoption of new technologies and integration with third party tools and smartphones / mobile devices. The reason is that,more and more users are now using new technologies and new devices. This motivates organizations to promote their BYOD (Bring your own Device) concept. In 2014, in my opinion this trend will drive ITSM solution providers to offer solutions accessible from these new platforms. I also feel that because of long term benefits and better ROI, organizations will prefer customized ITSM implementation over out-of-the-box standard solutions.

Where do you see the IT Service Management industry in 10 years time?

The industry will work towards consolidating more on the integration aspect of IT Service Management. Integrations are required to keep processes in sync with technological advancements. Therefore, the ITSM Industry should invest more in the development of people and process maturity models.

Finally, what would be your 5 tips for success in ITSM?

In my opinion, success starts at the beginning with implementation of your service desk tool. Therefore, my 5 tips for a successful ITSM Implementation are:

1 – Document all your business requirements (fields / attributes / forms), roles and access groups upfront. This will help in defining the solution framework and also pre-defined access rights and privileges to the users logging into ITSM application.

2 – Define process workflow requirements clearly for important ITSM process areas such as service request, incident, problem and change. This is effective when processes are being implemented in ITSM. This also helps when process audit are done to ensure that process workflows are as per documented requirements.

3 – Identify business rules and logic for important areas such as SLAs, priority calculation, threshold limits, escalation mechanisms and notifications.The business rules and logic requirements documentation helps in verification and validation of use cases when a solution is implemented.

4 – List out reports and dashboards required for different user groups / roles.The reports and dashboard requirements definitions are very important. It crosschecks that required information (data) is available in a solution being implemented in an organization. If some information is not available then there is a need to make a provision to capture the data.
5 – Ensure that you select the right ITSM tool for your specific business requirements.