What do you do when your test system is running an old version of TestStand, and you are not entirely comfortable simply transferring the code to the latest version of TestStand? Here are five tips for upgrading your test system.
Should you change a test system if it is not broken? Most people would probably say no, which is why test stations are often allowed to run for many years without being touched. Because it works—most of the time. But there comes a point when upgrading the system can no longer be postponed due to, for example, external requirements, compatibility issues, or internal pressure.
The system has fallen behind development, and there are likely several versions up to the latest release of TestStand. It can be tempting to just move up one version to keep things afloat, but the most future-proof solution is to upgrade to the latest version of TestStand.
It may seem like an overwhelming task, and you may worry that the test system will no longer work in the new version of TestStand. The good news, however, is that in 99% of cases there will be no errors. The old software is fully compatible with, for example, TS2019, and you could simply move your sequences and code modules directly into the new development environment (unless you are working in TS 4.2.1 or older, in which case you must manually migrate your sequences and configuration files, etc. (see here). However, that would simply leave the latent issues in the code as they are, and you would not gain any real benefit from upgrading TestStand. Therefore, here are a handful of good tips to get the most out of upgrading TestStand:
- Explore new features
Before you begin the upgrade, set aside some time to review which features have been added. Go through the documentation on NI’s website, and feel free to look at some of the examples published by NI’s application engineers. Perhaps some features have been implemented that solve challenges you have struggled with yourself—and perhaps only found a partial solution to.
- Do not reuse old code uncritically
Make sure you have a clear understanding of what you are reusing and why you can reuse it. As a rule, you cannot reuse it until proven otherwise. Was the code written according to best practices? This is a concept that may also have changed since the code was originally written.
- Pay down the “technical debt”
Take the opportunity to clean up what, over time, was simply the easiest way to get something working quickly. Typically, some corners were cut, and the problem may only have been half solved. Many of these actions will, over time, add up to a large amount of what we call technical debt.
- Review your own process
How do things work in practice? Is it an optimal process? Would we actually prefer to do it differently? Often, one of the biggest issues can be the company culture and overcoming the “this-is-how-we’ve-always-done-it” paradigm.
- Involve the people who will use the system
It is also important to involve not only the test developers in the upgrade, but also operators and other people who use the system day to day. Perhaps some of the new features address the pain points they live with in their working day.
All in all, think of it as a service check. And honestly—when will you get the opportunity to change the system again? Take advantage of the chance to get ahead again, so the task does not become even harder in a couple of years’ time.
If you have any unresolved questions, please do not hesitate to contact us. We have experience with every part of the process: upskilling employees to the latest version of TestStand, code reviews, and best practices for code development and maintenance.
