How do I save test documentation time by automatically generating Expected Results in test scripts?
Problem to solve: we'd like to automatically include Expected Results into our test scripts.
In the tests shown above, for example, we might want to include this Expected Result every time the necessary Values appear together in a test case.
- When a customer attempts to use frequent flier miles to pay for a flight and that customer has enough miles to do so, confirm that the transaction is successfully processed and that the customer's frequent flier balance is debited.
In the Auto-Script screen, find the specific test step you want to add your Expected Result to and highlight it.
Ask yourself these 3 questions and formulate precise answers:
It is important to have answers to these 3 questions:
1. What Expected Result(s) will be triggered?
- In this case the Expected Result is "the transaction is successfully processed and that the customer's frequent flier balance is debited."
- Note: Some new users of Hexawise accidentally enter Expected Results into the Define Inputs screen; we recommend against doing that. Instead, keep Values (necessary to trigger Expected Results) separate from the Expected Results themselves.
2. What is the smallest number of Values that will result in that Expected Result being triggered?
- Exactly two Values are necessary to trigger the Expected Result here. One is insufficient and we don't need three.
3. Which specific Values will need to appear in the same test case for that Expected Result to occur?
- First, The Parameter "Type of Payment" must be = "frequent flier points"
- Second, the awkwardly named Parameter "Customer Has Enough Frequent Flier Miles to Pay for Flight" must be = "has enough frequent flier milse to purchase this flight with them."
Next, with the answers to those 3 questions fresh in your mind, enter ONLY the specific Values that are needed to trigger the Expected Result.
You're setting up a simple "when" / "then" rule here.
Note that you're not restricted to rules like when Type of Payment IS frequent flier points:
- In this example, you could also create a rule that says "IS NOT" "frequent flier points."
- Alternatively, you could create a rule that says when Type of payment is "ANY," then...
After entering the Values, finish creating your simple "When / Then" rule and save it.
That's it! All your tests will now include the Expected Results you defined.
Important Usage Tips and things to know about the Expected Results feature in the Auto-Scripts screen
- This is a feature that is a partial solution for straightforward Expected Results. This feature primarily exists so that you won't have to manually type in a lot of SIMPLE expected results. It is not designed to handle especially complex Expected Results you might have.
- There are two posssible places in the Hexawise tool that you can enter Expected Results (on the Auto-Scripts screen and on the Requirements screen). Be sure you understand the similarities and differences between Hexawise's Expected Results feature described here and the "Requirements" feature. There's a BIG difference:
- If you want to define an Expected Result that requires 3 or more specific Values to appear in a single test script, (and you're creating 2-way / pairwise sets of tests), you should use the Requirements feature to enter it instead of the Expected Results feature (because you won't know whether those more complex Expected Results would appear in your tests).
- Using the Expected Result feature (described here) is like telling the test generation engine "if you happen to see a test that should include this Expected Result, make sure it appears."
- Using the Requirements feature, in contrast, is like telling the test generation engine "make sure that the specific combination of Values I'm specifying here definitely appear together in the set of tests at least one time (and, if I tell you that there's an Expected Result associated with that scenario, please be sure to include it)."
- Accordingly, if you're generating 2-way tests with Hexawise, you should primarily use the Expected Results feature to define simple Expected Results rules that are decided by using only one or two Values.