3 Test Tips For A Successful Product Transition

Illustrations of the main three steps to a succesful product transition: 1. Read those docs, 2. Decide on YOUR dealbreakers, and 3. Test with a plan

Familiar product being phased out? Here is our best advice on testing and planning to avoid being left without a solution when a supplier says “end of life”.

When a favorite product is being phased out by the vendor, or a new project requires a completely new solution, there’s a lot of planning and testing to do. Here is some sound advice on how to get started with and not least finish this process, so that you are not left without a solution when the supplier says “end of life”.

There are many possible reasons for testing a new product. Some of the most common reasons involve:

  • Needing to replace an existing product because it is out of date or being phased out
  • Wanting to replace an existing product that you are less than happy with
  • Trying out new products for a new, defined application/scenario
  • Trying a new product without having a clear scenario, to see if you can use it for something

Most of this article should be relevant regardless of your reasons for testing, but we primarily assume that you either have an existing product that you want to replace, or a fairly clearly defined scenario where you need a new product.

1. Know What You Are Testing

Yes, this sounds obvious, but it is often less straightforward than it looks, so we will say it anyway: Read the documentation.

For a brand new product there is often just a product datasheet and barely that, but this should at least give you a basic idea of what functionality the product can be expected to support. This can, for example, save you time trying to test configurations that are not supported in the first place.

Remember that manufacturers can be wildly inconsistent in terms of product and feature naming, model designations, and how the same functionality is described across models and versions.

Therefore, be careful not to make assumptions about functionality that is not clearly documented. It is better to ask too many questions than too few. We are happy to help!

2. Define Your Dealbreakers in Advance–Not Along the Way

We do not recommend creating a very long list of functionality that must exist in any product to be considered.

However, you will make life much easier for yourself by knowing where you are going before you get started.

It is normal to make some adjustments once you have seen the product in action, but without a clear starting point, you are shooting towards a moving target. The risk is great that you will never finish or be happy with your results.

Create a simple, prioritized overview of:

  • What is absolutely necessary to have.
  • What might be good to have.
  • What might be left to supplementary systems or equipment.

Also check whether there is something you can take off your list. If you are going to replace an older product, it will probably support some things that you strictly speaking no longer need. Do not make feature parity automatic requirement.

For example:

  • If your customers need VoIP, there is little point in testing a gateway that does not support this.
  • If you want to offer high-end Wi-Fi, however, bad or missing Wi-Fi support in a gateway is not necessarily an issue, if you are supplementing the gateway with a mesh network.

3. Follow a Test Plan / Checklist, and Save it for Next Time

Once you know what has to and should work, create a test plan/checklist If you don’t already have one.

If you’re replacing existing products, you might have a test plan from the previous implementation that you can use for comparison and as a starting point.

And if you make a plan now, it will also come in handy the next time there are questions surrounding the product, or when this product is being supplemented or replaced.

Bonus tip: Don’t Let Yourself Get Stuck, Ping Us!

Are you stuck in testing, or are you struggling to get started? Please contact usand share your test plan and criteria.

This makes it much easier for us to help find the right products and overall solution for their scenario. We may also be able to make concrete suggestions for further testing.

Article by Linda Firveld, Geir Arne Rimala, and Jorunn Danielsen