@bweinberg Thank you!
In 2016 we concluded that our characterization test software had critical scalability limitations, and sought an overhaul. We tried, but ultimately didn’t have the available software dev resources in-house. Then in May of 2017, the Keysight team (Audrey Kwan, @brennen_direnzo, @jeff.dralla) visited to pitch TAP. I hadn’t considered an external solution until that moment, but it seemed like it could address our problems.
The main technical challenge was refactoring our spaghetti code, or more like an entire Olive Garden. But each incremental change was beneficial, which kept the ball rolling. The next and ongoing challenge has been gaining user adoption. Many users have jumped on board, but some are resistant. A key issue is I haven’t provided good training resources. The Keysight training course is good, but of course doesn’t cover our internal plugins and usage model.
Sure. A big question of mine when I got started was: how much functionality should I pack into each test step? I’ve arrived at a couple basic philosophies:
- Test Steps should be designed to be as lightweight as practical.
For example, let’s say you need to send a digital signal, then measure a DC current. Those should be two separate steps, not combined into one step. This results in greater flexibility.
My rule of thumb is this: make each test step as small as it can get, without it having to awkwardly pass data to another step. Sometimes steps will need to be rather large in order to satisfy that rule, but most often they can be pretty lightweight. Which brings me to my second point:
- Test steps should not be secretly passing data to each other
I’ve often been tempted to have steps share data with each behind the scenes, using static variables. But I believe this is outside the general paradigm of OpenTAP, as it results in less flexibility, and strange dependencies between different steps. With a little more thought, I typically find that a better solution exists.