When teams start exploring Test Case Designer, 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.
As you design TCD 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, TCD provides several features:
1. TCD models 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 the “Your Test Models” dialog.
| Sharing also ensures that models do not get lost when people transition to different roles or move to other job opportunities. |
2. While sharing enables the most interactive access to TCD capabilities, sometimes export is more practical. Some of the most popular collaboration formats include mind maps, Excel, and feature files.
3. 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.
4. 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.
Once you have created the optimal model and confirmed it with the stakeholders, it is time to move the test suite to execution. Many downstream actions are typically performed in test management tools (e.g., Xray) or automation frameworks (e.g., Ranorex Studio). We will focus on the steps that have a direct impact on the Test Case Designer models.
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 highlighted above) constant by saving all scenarios as Forced Interactions. Italic type means that TCD 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 must be set up to represent each scenario.
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 remember that frozen test cases will often prevent TCD 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 ones mentioned most often, but you should not overlook execution and defect reports. While TCD does not execute your tests, establishing the feedback loop and ensuring your TCD model includes the interactions that have caused issues in the system is critical for the long-term value of the tool.
This category includes renaming values, adding/removing values that do not affect constraints, and changing the script.
We will 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 changes, you have to either delete relevant constraints 1-by-1 or, if the updates are drastic, bulk delete them and start from scratch.
When the parameter set changes and affects the constraint logic, the warnings will appear as you adjust the content on the first TCD tab. Please read through the impacted constraints and ensure the change you are making is the correct & efficient one. If you see a banner about “No possible values,” refer to another article in this category.
Example 2: When you need to incorporate ideas from multiple TCD models into one, you need to select the core model which has the highest amount of complexity (constraints, auto-scripts, etc.). You will copy that model as a whole through the “Your Test Models” dialog and then add content from the other models.
| Parameter lookup works at the project level. |
| If you are dealing with 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. |