This explains an approach for designing Hexawise tests that many new Hexawise users find useful.
Begin with the "Goldilocks Rule" to identify how much detail is appropriate
If you have a long end-to-end process, don't include much detail in your Values yet. If you have a small scope, include more specific detail. More information about the Goldilocks Rule is here.
Imagine explaining your System Under Test to someone's mother. Start with the 5 things that may change in each test
Suggestion: do NOT start this process with detailed Requirements or technical specifications. Instead, start with your basic, common sense description of some things that would change from test to test.
If you were explaining the application to someone's mother, how would you explain what it does in 2 minutes?
What kinds of things would be important to vary from test to test?
- Hardware and software configurations?
- User types?
- Different actions that a user might take?
Identify 5 things that change between tests, and turn those 5 things into your first Parameters
- How might those things change? Add one or more Values for each Parameter.
- At this point, general descriptions might be fine; (e.g., SUVs or Economy cars vs. Toyota Corolla).
Remember that, wherever possible, you should avoid creating long lists of Values.
Create a draft set tests, assess obvious big gaps in the tests, and start filling them
What obvious types of scenarios are missing? Add Parameters and Values as necessary to fill the obvious holes.
Create tests again, assess whether you're covering necessary business rules and requirements
If your tests are not yet testing a business rule or Requirement that you want to test:
Consider adding a Parameter or Value
Consider adding a specific combination of Values to be tested together in the Requirements tab
Reminder: if you have a "one-off" requirement, it is often better not to include those in your Hexawise model. Instead, manually document test cases for such requirements outside of Hexawise
If adding additional details into your model is "starting to make [your] head hurt..."
Consider changing the scope of the model (e.g., create two different models with largely similar Parameters - one for Regular users and one for special users - instead of one big model which tries to "do it all")
Consider changing the way you are describing "hard coded" Values. Instead, of "iPhone 4S with International roaming" (which might not be a valid option after the first part of the draft test case suggests a transaction for a phone for Corporate Customers from a Northern location responding to the Special Holiday Offer...) consider using descriptive Parameters and Values along the lines of "from the phone options available at this point in the test case, select an option that meets as many of these conditions as you can...
- Popularity = Popular (vs. Medium Popularity or Rarely Purchased),
- Cost = High (vs. Medium or Low), and
- Plan Options = All Available Options (vs. Some Options, No Options)
Consider exporting the tests from Hexawise while they are still general and add details after exporting from Hexawise.
Consider adding additional details into your model from other sources
Other sources for test ideas could be from the following PDF files: