When many users begin test modeling, a common mistake is to only think of models as the chronological sequence of filling out a form, like a login page. While forms are a valid use case for modeling in Agile Requirements Designer (ARD) from Broadcom, simply modeling valid or invalid ways to fill out a form aren’t the only conditions that need to be considered when implementing model-based testing.
In this guide, we will cover several questions you should ask yourself to make sure the test cases you create in ARD give you a high level of functional application coverage.
Figure 1: An example of model-based testing with “valid” and “invalid” paths, pictured in Agile Requirements Designer from Broadcom
1. What’s possible at each step?
When determining the permutations at each decision block, sometimes you may need to consider more options beyond just “valid” or “invalid”.
Perhaps, you are modeling a bank transfer of money between accounts. The invalid options could be a negative number or a non-numeric entry. In that case, both scenarios may need to be entered as separate decision outputs to ensure each one is accounted for when you begin to create test cases.
Next, the valid output could be a numeric amount greater than zero. There is most likely an upper limit to that number or a number that would require an approval process before the transfer can be made.
If the application needs to be tested at this thorough level (especially for something critical like a banking process), boundary conditions like these must be represented in your model.
2. What’s happening in the background?
Similar to the question above, it is important not to forget any processes that might be happening in the background based on the actions you are taking. The user may not be able to see these automatic changes, but the subject matter expert who is building the model should be aware of them.
3. How do various user permissions change things?
Another common oversight is not modeling different user permissions. If you are an administrator for an account, there are most likely actions you can see and do that a regular account member cannot.
An important part of model-based testing is verifying that those roles are properly performing, and therefore they should be represented within your model. To prevent repetitive work, sub-flows or clones are helpful tools that allow you to create the same processes only once.
What can change is the expected results of going through that process. If an administrator can add a user and a regular user can’t, both users will try to do the exact same action but the results will be different.
If you are just checking whether or not you can add a user, you may not need to run every single test case for the process of adding a user for both an administrator and a regular user. You may just need a test to validate that you can generically submit access action. For more information on optimization, please review our official documentation on Optimization Techniques.
4. How else can you leverage models?
Thus far, we’ve only discussed examples of modeling in UI applications. However, other types of use cases can also be modeled with ARD. Another common use case is test modeling for an API.
For example, we may only have one automation script created from ARD, and the data sets we created simultaneously will drive different permutations. To learn more about model-based API testing, watch this webinar replay.
Regardless of the use case, keep in mind the results you are trying to create from the paths or test cases that a model optimizes. Your testing may be driven by varying automation scripts, different data sets, or different combinations of manual actions. And, every decision or permutation point you engrain in the model should create a unique and meaningful path.
5. How extensive should you make your model?
Model-based testing requires a mind shift in the way testing is approached, and models may not necessarily conform to typical test categories in traditional testing.
For instance, a single model might cross one or more user stories or requirements. A model can also cross more than one application or service if different actions require the tests to do so.
To ensure the models created are a manageable size and scalable, sub-flows should be used to break up logical starting and stopping points. When testing outside of ARD, not every test case will be an end-to-end scenario—likewise, test cases that are created in ARD shouldn’t be either.
Model-based testing is powerful, and it relies on thoughtful considerations and intentional modeling practices to achieve optimal application coverage. If you’d like to learn more, visit our ARD documentation website for modeling best practices.