Defining Test Data Using Decision Tables

There also seems to be no reason why we couldn't use the decision table format for defining test data. This would be a lot more user friendly than expecting them to handcraft complex json structures (even I can't get those right half the time!).

In fact, most likely business users are already defining test data in spreadsheet format - which we could probably import into our tables.

Then in the tester you could just refer to the table that contains your test data (under the covers BizVR would convert it to json for execution, run the rules and then convert the resulting json back to tables so the user can look at it.

For simple data its very easy:

This would result in the creation of the following json:

{"TOYS":[
{"testid":"T1","color":"red","size":"small","shape":"square","expected price":5},
{"testid":"T2","color":"green","size":"small","shape":"square","expected price":20},
{"testid":"T3","color":"blue","size":"large","shape":"round","expected price":15},
{"testid":"T4","color":"blue","size":"large","shape":"square","expected price":20}
]
}

After execution (see below for a possible DT)the results might look like this with any discrepancies highlighted in red:

Note: the testing person who is creating this data should only have access to the specification not the decision model. If fact the test data and the decision model can be in completely different workspaces and access controls can prevent cheating.

The decision table that processes this data might look like this

What about more complex data structures? Defining Complex Data Using Decision Tables

Defining Test Data For The Transportation Scheduling Example