Welcome to the new Ranorex Support Portal

Ranorex
Try DesignWise with Ranorex
Help Center › User Guide › Ranorex DesignWise › Test Design Principles and Helpful Tips
User Forum

DesignWise Process – Sharing & Maintenance

Tips and best practices for the long-term management of DesignWise assets.

When teams start exploring DesignWise, they are often unsure what will happen to the models after the initial release – will they have long-term value, where is traceability with execution, how to conduct maintenance, etc. ? In this article, we have consolidated the “cheat sheet” from the information available in our feature-focused documents and provided additional insights gained from client projects.

Part 1. Collaboration and review

As you design DesignWise models, it is always a good idea to work together with other SMEs, bounce ideas off business analysts and developers, and eventually review the draft models with the key stakeholders. To assist in that process, DesignWise provides several features:
DesignWise assets can be shared at the project level by separately including email addresses or sharing the secret link with the group. You can choose one of 3 permission levels for each colleague. If you do not want some models to be seen, you can move them from the project state to the private one by editing in “My Test Models” dialog.

Sharing also ensures that assets do not get lost when people transition to different roles or move to other job opportunities.

While sharing enables the most interactive access to DesignWise capabilities, sometimes export is more practical. Some of the most popular collaboration formats include mind maps, Excel, and feature files.

Notes can be used to keep track of your design ideas, to post questions to your collaborators, or to mark outstanding actions to complete the model.

Revisions (accessed from the dropdown near the model name) provide version control capabilities where you can see your colleagues’ actions and, if necessary, return the model to the previous state.

Part 2. Release preparation and ongoing maintenance

Once you have created the optimal model and confirmed it with the stakeholders, it is time to move the test suite to execution. Many of the downstream actions are typically performed in test management tools (e.g. Micro Focus ALM / QC, JIRA Xray, etc.) or in automation frameworks (e.g. Cucumber). We will focus on the steps that have direct impact on the DesignWise models.

Freezing

When your scenario suite is finalized, it can be a good idea to ensure test data consistency with the help of “freezing”.

To clarify, freezing makes the italicized values (red rectangle highlight above) constant by saving all scenarios as Forced Interactions. Italic type means that DesignWise has already covered all n-way interactions for that parameter and now randomly selects a value from the available list. Therefore, without freezing, there is a chance the value will change on suite re-generation. This could pose a challenge with test data preparation if, for example, distinct accounts need to be set up to represent each of the scenarios.

Ongoing maintenance

While we recommend unfreezing the test suite before incorporating new information into the model, in some cases the updates can be made on top of the preserved scenarios. You have to keep in mind that frozen test cases will often prevent DesignWIse from finding the most efficient way of including changes, which leads to the avoidable growth of the test suite.

We will focus on the situation where the test suite can be re-generated completely. Regarding sources of information, new requirements are the one mentioned most often, but you should not overlook execution and defect reports. While DesignWise does not execute your tests, establishing the feedback loop and ensuring your DesignWise model includes the interactions that have caused issues in the system is critical for the long-term value of the tool.

Simple Changes

This category includes renaming values, adding/removing values that do not affect constraints, and changing the script.

  • To avoid unnecessary complications when you just want to rename an individual Value, we recommend that you do that by clicking on the actual Value, not on the parameter name.
  • Adding or removing values can be done via Edit, Bulk Edit, or Mind Map modes – depending on the number and format of changes.
  • Within Auto-scripts, you can edit the content of each step and its position in the overall script by hovering over and clicking the pencil/arrow icons:
Complex Changes

We will take a look at 2 examples: significant updates to the constraint logic and merging ideas from multiple models.

Example 1: When the input set is constant and the constraint logic is changing, you have to either delete relevant constraints 1-by-1 or, if the updates are drastic, bulk delete them and start from scratch.

  • You can leverage the browser search to identify constraints for the necessary values:
When the parameter set is changing and that affects the constraint logic, the warnings will appear as you adjust the content on the first DesignWise tab. Please read through the impacted constraints and make sure the change you are making is the correct & efficient one. If you see a banner appear about “No possible values”, refer to another article in this category.
Example 2: When you need to incorporate ideas from multiple DesignWise models into one, you need to select the core model which has the highest amount of complexity (constraints, auto-scripts, etc.). You will copy it as a whole through the “My Test Models” dialog and then add content from the other assets.

  • You can add parameters via copy-paste in Bulk Edit or via parameter lookup in the “New Parameter” dialog (note: parameter lookup works at the project level):
  • You can add constraints via copy-paste in Advanced Mode
  • Depending on the elements of each model, it may be more efficient to merge 3 exports in Excel and create a new asset from Excel import:
  • If you are dealing with the integration testing, we often recommend decreasing the level of detail – in other words, do not merge all parameters & values from multiple models, but instead reevaluate which are the crucial ones from the integration perspective and abstract the rest.