What to do when your test system is running on an obsolete version of TestStand and you are not all confident transferring the code to the newest version of TestStand? Here are five advices on how to upgrade your test system.
Should you change a test system if it is not broken? Most people would probably answer no, and therefore many test stations are left untouched for many years. Because it works. Mostly. But there comes a time where upgrading the system cannot be postponed any longer. Maybe due to externally imposed requirements, compatibility issues or internal pressure, but something must be done.
The system is disconnected from the progress, and the current TestStand is probably several versions away. It is tempting to just crank the version one level up to keep the train running. That said, the future-proof solution is to upgrade to the current version of TestStand.
It can seem like an unmanageable task, and you might fear that the test system no longer will work in the new version of TestStand. The goods, however, is that in 99 cases out of 100, there will be no errors. The old software will be completely compatible with e.g. TS2019, and you could just move your sequences and code modules straight into the new IDE (unless you’re dealing with TS 4.2.1 or older versions, then you will have to manually migrate your sequences and configuration files etc. (see here). However, the latent problems would remain in the code, and you would have no real benefit of upgrading TestStand. In order to make the most of a TestStand upgrade, five advices:
1) Research new features
Before you start upgrading, take the time to review what new features have been added to TestStand. Browse through the documentation on NI’s website, and preferably have a look at the examples being published by NI’s application engineers. Maybe new features have been implemented that solve the challenges you have been struggling with previously – and perhaps only found half a solution.
2) Do not reuse old code uncritically
Be absolutely confident about what you reuse and why you can reuse it. As a default, you cannot reuse anything until the opposite has been proved. Is the code developed using best practices? What was best practice when the code was developed, might not be the case anymore.
3) Pay the “technical debt”
Use the opportunity to clean up in what at the time was the easiest solution to get something to work in a hurry. Typically, some very short shortcuts were taken, and therefore maybe only solved a problem partially. Over time, many of these solutions will add up to a large quantity of what we call technical debt.
4) Examine your own process
How do things work in practice? Is it the optimal process? Would we actually rather do things in a different way? Often, one of the biggest problems can be the culture in the company and overcoming the “that’s the way we use to do it” paradigm.
5) Involve the people that will use the system
It is also important not only to involve test developers in the upgrade, but also operators and any other person that may use the system in their everyday. Maybe some of the new features would solve the nuisances the experience during their workday. In the end, consider it an inspection, because honestly, when will you get the opportunity to change the system again? Seize the chance to get back to the cutting edge, such that the task will not be even more difficult in a couple of years.
In case you have any unanswered questions, do not hesitate to contact us. We are experienced with all parts of the process: Training co-workers in the newest version of TestStand, code review, and best practices in development and maintenance of code.
