It is important to remember that when you're entering variables into the "Define Inputs" screen, you should include test INPUTS only. You should not include outcomes or expected results in the variables you include on the "Define Inputs" screen.
Let’s try with an example of an online order for pizza. At this restaurant you are charged specific amounts of money based on the size of the pizza, ranging from $ to $$$.
This plan includes expected results (prices) as inputs, and the price is varied by the size.
Once the inputs are defined, we create the tests...
Let's examine the first three test cases to help understand why you should not include outcomes or expected results in the "Define Inputs" screen.
The large or medium sized pizzas should not cost the same $ that the small size pizza costs. Because we included "Price" as an Input we are receiving invalid and incorrect test cases. This could have been avoided simply by including "Price" as an expected result in either the Auto-Scripts or Requirements screens.
It is possible to create multiple constraints to ensure that the correct "Price" appears with each size of pizza, but even if you perfectly modeled these complicated constraints (which is easier said than done, and can be very tough on more complex systems than this example), what do you gain by including "Price" as an input? Nothing that can't be accomplished by including Price as an expected result in Auto-Scripts or Requirements.
So the rule of thumb when defining your inputs is summed up in the below image:
You'll thank me later when your Hexawise plans are organized, clear, and not overflowing with constraints.
To learn more about including expected results, check our articles below:
- How can I best identify variation in the system I'm testing?
- How do I save test documentation time by automatically generating Expected Results in test steps?
- How do I "force" Hexawise to include required scenarios and manage requirements traceability?