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

4

Hi,
I am also struggling with this topic,
Did you already made some progress?
I was thinking about 3 other scenario’s:

  1. It would be nice if the ‘Test Plan Reference’ Step, and the ‘Reference Plan’ file variable can except an output parameter from another step. However unfortunately it seems not possible. Maybe it is a nice feature for future updates.
  2. You can already parameterize the mentioned ‘Reference Plan’ file variable to it’s parent. Isn’t it possible to make a sequence step that is able to scan your QR code and translate it to deal with the logic of composing your file path. Maybe something is possible in that area.
  3. I see the ‘Test Plan Reference’ step is supporting Mixins, is’t it possible to make a mixin which translate your QR code into the mentioned file path.
5

Hello @e.huijben ,

In my case, I ended up settling on a top level test plan and included all the different DUT type tests as “Test Plan Reference” steps that are enabled or disabled based on settings which are populated by an initial step that handles the DUT selection via a drop down list. The drop down list in turn can be automatically set by a QR code scan which I handle the same as regular keyboard input (i.e. no special serial device, etc.).

For the scenarios you mention:
I think the problem is that the test plan reference loading only happens at test plan load time or when manually refreshed. I’m afraid I don’t know all underlying details, but I imagine once the test plan reference is loaded, it is treated exactly as if the steps it contains were present in the top level test plan. Once the test run starts, this can’t change so I imagine allowing the test plan reference path to accept an output or be modified in any way after test run start wouldn’t work without significant change to how and when the test plan is parsed.

So the problem I was running into wasn’t really related to modifying the path using the QR code scan. The problem seemed to be that the test plan run seemed to require all the steps to be present at test run start and could not be modified after wards.

I may be wrong, but I think that is still the case.

Thanks,
Wittrock