Dynamically loading testplan from teststep

1

I am currently using EditorX on Linux as the operator user interface (i.e. I don’t currently use the API myself to build/load/run TestPlans.

I have a number of different DUTs that are tested using a number of unrelated TapPlans.

I am trying to find alternatives to having the user manually opening the correct test plan based on the DUT they are testing.

Previous to this, the DUTs I was testing and the TestPlans were related and only differed in parameters (i.e. number of channels, tolerance limits, etc.) In this case I had conditional steps that just ran the parts of the TapPlan that were needed for the specific DUT so did not need to consider loading different TapPlans.
The first step in the TapPlan notified the user to scan a QR code on the DUT, and I modifed the parameters as needed.

With a larger number of unrelated DUTs, the above becomes impractical.

Some approaches I have considered:

  1. Write my own simple GUI for the operator interface and use the API to build/load/run TapPlans. Probably the best approach, but the one I am trying to avoid at the moment.

  2. Have a top level TapPlan with a bunch of ‘Test Plan Reference’ steps and only run the appropriate one based on a condition step similar to what I have already done. The downside to this is that all the TapPlans have to be loaded when the top level plan is loaded. It’s also a bit confusing for the operator to see all the unrelated steps in addition to the ones that apply to the selected DUT. I don’t believe there is any way for me to dynamically expand/hide steps.

  3. Something similar to what is described in this by @justin_c_i.
    As a quick test of this, I sub-classed the existing ‘Test Plan Reference’ step to make the HideSteps property accessible.The downside is the operators would like to see the test step execution and this would not show those.

  4. Use one EditorX instance to run a top level plan that launches a second instance loading the correct TapPlan for the DUT selected in the top level TapPlan. It works but I would rather not and I can see the operators confusion already.

I appreciate any suggestions from anyone who has faced a similar situation.
My hunch is that option 1) is best long term and I may have to live with option 2) short term.

Thanks,
Wittrock

2

Hello, :wave:

As per my knowledge, building your own GUI is probably the best long-term solution. It would give you control over which TestPlan is loaded, making it easier for operators.

It might get confusing for the operators since they’d see all the unrelated steps. If you can manage the training and documentation, it could be a temporary fix until you’re ready to build the custom interface.

I hope this will help you!

Respected community member :blush:

3

Thanks @nisha02 ,

Short term, I am just including all the test plans using “Test Plan Reference” steps.
It’s not the best but is workable for now.

Since I need to run on Linux, the custom GUI part is a bit more complicated.
I have been looking into using Avalonia.

Thanks,
Wittrock