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:
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.
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!
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:
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.
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.
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 D. Newth