When two companies merge, they try to get rid of common products with duplicate functionalities. Also there is an attempt to make the acquired products compliant with the whole suite so that the customers get the same look and feel. Unfortunately, this is not always as easy as it may sound. In most cases the architecture, design, and coding are already complete and the product is in a beta stage. There is no time or budget for a complete overhaul of the acquired products. So, we have two sets of products, which are partially or completely different, adhering to two different standards of their parent companies. In most cases, there is also a lack of appropriate design and requirements documentation. These situations become extremely difficult for the developers to handle. They become a complete nightmare for the QA team.

Plan How to Handle Support
Even before we start to add or strip functionalities and enhance the new products, we are faced with the problem of providing support to the existing customers. It is a good idea to get some training organized for the support and the project team on the acquired product. The support staff is the first point of contact for the customers who do not have much knowledge of the acquired product. To solve this issue, we can get the support group and the QA team to work together when customer calls come through. This reduces the turn around time, and gives the QA team more insight into the product. If a patch is required, the developers should be involved, so that the whole team can benefit from this process.

Retain QA Staff
Almost all mergers and acquisitions are cost-cutting measures to sustain the business. A careful analysis should be conducted to ascertain which staff members should be retained. Usually, the key members of the QA team have excellent product knowledge acquired over the years. It is easier and cheaper to retain these staff members, rather than training other test analysts. This is a major risk-reduction step and can achieve a very smooth transition.

Establish and Follow the Change Process
Change control is the main key to these kinds of product transitions. If there is no change control process in place-or if what exists does not agree with the requirements of the product transition-time should be allocated to put a proper change control process plan in place. The introduction of this process paves the way for further maintenance and enhancement projects in the future. This information will give some insight to the QA team on the extent of regression testing that should be conducted.

Cover the Information Gap
Under most of these circumstances, the QA team does not have access to well-documented system requirements or relevant design documentation for the new product. The only reference they have is the system in front of them. The team begins work with primarily exploratory efforts, while creating some test scripts in the process. It is a tedious exercise and involves a lot of trial and error. One key step is to capture the acquired knowledge so the whole team can share the knowledge. There is no point in reinventing the wheel. So a small time taken to document the newly acquired information will take the form of requirements, which can be used across the board, even by the developers. This documentation can be refined and used as a baseline for further enhancements to the product.

Be Careful when Removing Duplicate Functionalities
Even though duplicate functionalities may reside within a product, stripping the acquired product of these functionalities is a very risky business. Both sets of products come from different parent companies and were built to different standards. Something that may be regarded as very obvious in one product may not be so for the other. The problem grows exponentially when the acquired product has "spaghetti code." The problems that could arise from removing these duplicate functionalities should be discussed in detail before any removal action is taken. The team should implement rigorous regression testing and maintain very careful attention to detail to ensure a smooth product transition.

Usability Considerations
The purpose of acquiring a product is to give it a look and feel similar to an existing suite. The members of the QA team who are already familiar with the existing suite, familiarize themselves with the new product through the exploratory efforts. Instead of going through a formal round of usability testing to consider enhancements, conducting an informal brainstorming session to change the user interface can often yield the desired results.

Run Requirements Development and Testing Parallel
It is always a great idea to involve the QA team in the requirements gathering phase of any project. The reality, however, is that it rarely happens. For enhancements to a third party product, this becomes a very critical issue. At times, the creation of test cases during the user-interview sessions can uncover confusion, ambiguity, and avoid misrepresentation of the system. When the entire project team is fairly new to the product, extensive teamwork will be highly beneficial.

Analyze the Impact of Enhancements on System Performance
One important point is that the customers already have the product, and the users are already used to it. They take the performance of the existing system as the baseline and will not be thrilled if performance goes down when the enhancements or changes in the UI (for suite compliance) are implemented. Customer expectation of the product should be considered when enhancements or changes are planned. System enhancements should not have a negative impact on the system's performance, response time, reliability, efficiency, integrity, or other attributes. Keeping these tips in mind when contemplating product upgrades or eliminations of duplicate functionalities can lead to fewer headaches for you and your project team. A systematic approach by the QA team, coupled with commitment from management, can solve many of these problems and reduce the risks of transition.