Training COMMON CHALLENGES AND TIPS FOR SUCCESS16. Tip: Start by creating 5 parameters for the 5 most obvious things that will be varied

16. Tip: Start by creating 5 parameters for the 5 most obvious things that will be varied

This explains an approach for designing Hexawise tests that many new Hexawise users have found useful.

Begin with the "Goldilocks Rule" in mind to identify how much detail is appropriate.

Begin with the "Goldilocks Rule" in mind 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 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 from test to test 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., SUV's or Economy cars vs. Toyota Corolla).

- Remember that, where 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 those big, 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 "one off" Requirements in your Hexawise plan. Instead, manually document test cases for such requirements outside of Hexawise.

If the process of adding additional details into your plan is "starting to make your head hurt..."

  • Consider cutting the scope of the plan (e.g., create two different plans with largely similar Parameters - one for Regular users and one for special users - instead of one big plan 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 available options of phones 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) and

- 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 plan from other sources.