Versions Compared

Old Version 2

changes.mady.by.user Ana Duarte

Saved on

compared with

New Version Current

changes.mady.by.user Ivan Filippov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Only seven Tests are required to achieve our desired coverage.


This means that every Test condition was used at least once. This, however, does not guarantee that any parameter values were tested together. In other words, a parameter value merely appearing in this Test set is satisfactory as far as the Xray Test Case Designer is concerned. That’s not particularly thorough.

...

UI Steps
UI Step

On the Scenarios screen, click the Freeze these Scenarios button (Figure 8 - 1).

Figure 8 - Freeze

Figure 8 - Freeze

UI Step

You will see a warning message (Figure 9) reminding you that freezing your Test cases should only be done when there is a valid reason to do so.

To proceed, click the Freeze button (Figure 9 - 1).

Figure 9 - Freeze

Figure 9 - Freeze

UI Step

Once you click Freeze (Figure 9 - 1), your existing Test cases will be “frozen” as Forced Interactions.

Here’s what that looks like now (Figure 10): all of our Tests have been “frozen” as the combinations of forced parameter values.

Figure 10 - Frozen

Figure 10 - Frozen

UI Step

Let’s add another parameter: Amount of luggage (Figure 11 - 1). At this point, we may have already run some of these scenarios, so we don’t want to have to redo any of them, even if Xray Test Case Designer could reduce the total number of scenarios. By freezing the previous 11 Tests, Xray Test Case Designer will keep them as they are, and simply add a couple of scenarios to pair all of the new values – the numbers of luggage – with every other value.

UI Step

Here are the new Tests (Figure 11). Note that the initial 11 scenarios are still present. We’ve simply added a few more.

Figure 11 - Tests

Figure 11 - Tests


Here’s what the differences could have looked like if we had not frozen our initial 11 Tests. 

Notice how Test Case 3 contained the following while frozen:

  • USA.
  • India.
  • Coach.
  • Selected.
  • 1.
  • More than 1.
  • 2 or more.

If we unfroze, Test Case 3 could contain the following:

  • USA.
  • India.
  • First.
  • Selected.
  • 1.
  • 0.
  • 2 or more.

Therefore, we would have needed to rerun our initial scenarios. If we still want to unfreeze, we can do so by navigating to the Forced Interactions screen, and simply clicking the Unfreeze button in the top left.


“Optimized” compute option


Key points:

  • Selective Activation:

    • The "optimized" compute option will not affect existing computations automatically.

    • Users can select the "optimized" option from a dropdown menu on the Scenarios screen.

    • To activate, users must not only select “optimized”, but also fill in a text field with the word “optimize” and confirm it. This intentional extra step ensures that the optimized compute is used sensibly.

  • Enhanced Computation Process:

    • The "optimized" scenario option runs the computation on the same engine 50 times with a single click.

    • It selects the outcome with the least number of tests, often resulting in slightly reduced scenario counts compared to the standard option.

    • The non-deterministic variation is crucial for achieving this optimization.

  • Cache Management:

    • Switching between standard and optimized options does reset the cache. For example, if you calculate using the standard option, switch to optimized, and then back to standard, a new data table will be generated, therefore, creating a new set of scenarios.

    • Staying with the same compute option does not reset the cache. For instance, if you calculate using the optimized option, switch to another screen without making any cache-resetting edits, and then return to optimized, the same table will be retrieved.

  • Recommended Workflow:

    • Utilize the standard scenario computation while the model is undergoing edits.

    • Utilize the optimized scenario computation when you are ready to export the final results to include in test executions.


The examples of model actions that do break cache:

  • Adding/Removing parameters

  • Adding/Removing values

  • Adding/Removing/Editing constraints

  • Adding/Removing/Editing forced interactions

  • Copying the model/reverting to a different version of the model


The examples of model actions that do not break cache:

  • Editing value expansions

  • Renaming values

  • Navigating between tabs

  • Adding notes

  • Editing scripts



Expand
titleSupport/Troubleshooting

If you have questions or technical issues, please contact the Support team via the Customer Portal (Jira service management) or send us a message using the in-app chat.