Test Design for Testing Benefits on a Claim

  • 1
  • Question
  • Updated 8 years ago
  • Answered
I'm currently assessing Hexawise tool for our testing team. Basically what we need to test is that if the benefits are applying correctly, and how we test it is by logging a claim and verify how the benefits are applied after the claim is finalized. The catch here is that there are only few parameters that I can define such as claim type, provider type, procedure, diagnosis, gender, member code. Out of these parameters, procedure and diagnosis have a lot of values (since there a many procedures in order to test the benefits of the contract) and the rest of parameter have at most 5 values. Using hexawise, it will generate hundred tests which mean 100 claims to log as well. Unlike in setting the tests manually wherein we can create scenarios with multiple procedures so the number of claims to log will be diminished. With this, I think hexawise will not serve it purpose when used for this particular team. I may be wrong so someone may provide comments, suggestions on this topic. Thanks in advance.
Photo of Gina

Gina

  • 3 Posts
  • 0 Reply Likes

Posted 8 years ago

  • 1
Photo of Justin Hunter, Hexawise Founder

Justin Hunter, Hexawise Founder, Founder and CEO

  • 246 Posts
  • 15 Reply Likes
Gina,

Hexawise can be used to automatically generate excellent tests in exactly that situation. Doing so will require that you think a bit differently about how to categorize your test inputs.

You've asked a great question. I wish more people would ask similar kinds of questions here.

As I understand your problem, you have one parameter "Claim Type" with, say, 100 different Values and other Parameters that have, at a maximum, 5 Values each. If you enter those test inputs into Hexawise, you will get a pairwise testing solution (AKA a 2-way solution from Hexawise) that has - at a minimum - 500 tests. This is because each of the 100 Claim Types will be tested in at least one test case with each of the 5 Values from the next longest list of Values in the test inputs. That seems to be "too many tests to execute" in your context. You're asking if there is a solution to that problem.

Fortunately, there is.

Instead of defining the "Claim Type" to have 100 different Values (which is the primary "bottleneck" / determinant of how many tests you will have in your solution), you should take a different approach.

One valid approach would be to create 5 different Parameters for Claim Types. "First Claim", "Second Claim," etc.

You could have 20 Values in each of those 5 newly created Parameters. Each of your tests would have 5 claims in it should you choose to model your tests this way. Now, as compared to your initial model (with 100 Values in one parameter), the "bottleneck" would be more manageable. It is simply changing how you arrange your test inputs. You would have 20 X 20 tests as the absolute minimum number that would be created if you stopped at this point. 20 being the number of Values in your two longest lists of Values in your test inputs.

Based on the context you've described (in which you're trying to execute even fewer tests than that and finding out as much as you can in the tests you run), I would recommend using the Value Expansions feature. That will allow you to "shrink the lists of Values" even further.

How would this work? For the parameter called "First Claim," you could take claim types 1-20 and categorize them into, say, 5 categories: arranging them from "Most Expensive" to "Least Expensive" (or, if you prefer, "Most Common" to "Least Common" or, if it would be more likely to trigger business rules "Most Likely to be Covered" to "Least Likely to be Covered").

Here's what that type of solution would look like:

Parameter Name = First Claim

Values (5) = Most Common Category - 1st Claim, 2nd Most Common Category 1st Claim, 3rd Most Common Category 1st Claim, Fairly Rare Category 1st Claim, Rare Category 1st Claim

Value Expansion for "Most Common Category 1st Claim" = [Specify 4 claim types from the first 20 Claim Types from your original list of 100], Value Expansion for the "2nd Most Common Category 1st Claim" = [Specify 4 different claim types from the first 20 Claim Types from your original list of 100], ... and, using the Value Expansion feature, continue associating the remaining 12 Values from the first 20 of your original list of 100 to the 3 other categories.

For the Parameters, "2nd Claim" through "5th Claim", you would have 5 Values with names nearly identical to the ones above. As in the above example, each of these Parameters would have 5 Values a piece. Each of the Values would be "category" values. The "category" Values would each have 4 "sub-Values" (through the use of the Value Expansion feature).

That way, you would create a test plan using Hexawise that would achieve the goals you're hoping to achieve, namely a relatively small number of very powerful tests that pack as much coverage as possible into as few tests as possible. Hexawise would automatically create a set of tests that would have the maximum amount of variation from test to test, along with the maximum amount of combinatorial coverage, and the minimum amount of repetition.

This is a good test design challenge that illustrates there are multiple "correct" answers. Different test designers may well select different test inputs and might make different choices about how to handle long lists of Values (which you'd like to avoid whenever you can).

I should point out that when you use the Value Expansions feature to expand "Category" Values into sub-values as recommended above, you have a tradeoff to consider. You will generate fewer tests (good, right?), but you will lose some of the thoroughness of the combinatorial coverage that existed before you used the Value Expansion feature. Before you used the Value Expansion feature, "Test Claim Type # 18" would appear together in at least one test case with each other test input in the test plan in any 2-way set of tests you might create. After you used the Value Expansions feature, that would no longer be the case. If Claim Type # 18 was put into the category of "Most Common Category 1st Claim," for example, it is that new category ("Most Common Category 1st Claim") that would be considered the "Value" that Hexawise would now ensure gets paired with every other value in the plan for a 2-way solution - as opposed to the pairing coverage happening at the more discrete sub-Value level.