I have found some discussion on this, but not sure I have found a "best practice" answer. I'll keep issue brief for now, but I'm sure the first comment will be "need more details". My quick version of the question is how do we in safest / cleanest way, keep the test # or step # from changing, then we update our PXI and code. I am the system engineer trying to do this best way, but we have some SW folks were are doing the TestStand / LabWindows side of this. More details below.....
We have a TestStand report from an automated test equipment that we are updating from many years ago. Here is a tiny excerpt of the report:
No. Test Name Unit Cmpr LL Result UL P/F
-------------------------------------------------------
1 SetFunctionalTest D
2 Init D
3 Res Meas 1 Ohm GE 2e+006 9.9e+037 P
...
xyz Not needed Meas # Ohm GELE 100 0 1000 Skip
...
abc Res Meas ### Ohm GE 2e+006 9.9e+037 P
...
pdq Cleanup D
We have some PXI modules that have gone obsolete, and need to be replaced with current modules. The old coder just retired, the new coder wants to make various tweaks and updates to the multiple parts of the SW - as well as eliminating all the "obsolete" measurements that are no longer applicable to the product being tested (at one time, the product had extra features that needed testing). The new coder warns us these updates would result in changing the reported test / step number in column 1. For a given still valid test, the customer does not want those numbers to change, they have used those test / step numbers as a "Unique ID" in their database of the test results for nearly 20 years. The customer seems to prefer that we get rid of the extraneous data in file we send them (e.g. the "skip" data from the no longer valid features / testing), but this could shift the column 1 numbering, too. This must be a fairly common config management issue that others have, too?!
Any suggestions for the "best practice" way to do this? I have come up with various possible ways, both inside and outside of TestStand / SW (e.g. post-processing the report, but some worry that could call into question the integrity of the report) ..... As I like to say for some many of the issues encounter, "I can't be the only person who has run into this".
Thanks!