Creating Test Scenarios

For All Template Types

To create or modify a test scenario (for which separate create and modify permissions are needed), do the following:

1. Click the Test Scenarios node.
2. On the toolbar, click New Test Scenario.
3. Add the following data:
   • Name—A descriptive name for the test scenario.
   • Description—A test scenario description
   • Phase—The phase that you want the test case to execute on. For templates that do not contain phases, an asterisk (*)  indicates that this phase is not applicable.
   • Business Hierarchy—You can select, from a drop-down list, the level of the Business Hierarchy on which you want to run the test: for example, run at the “general/package level,” or run under a specific department or process. If your business hierarchy is nested, only the nodes below the relevant rule package are shown. 
   • Simulated Date—You can simulate the date that the test scenario is running in order to test time-sensitive rules, such as a rule with a start/end date or business calendar. The default is to run with today's date.
   • Simulated Time—You can simulate the time at which the test scenario runs in order to test time-sensitive rules, such as a rule with a business calendar.  The default is to run with the current time. To clear the simulated time field, enter a dash ("-") in the hour field and press enter.
   • TimeZone—You can set the time zone for the test.  The time zone is applied to the Simulated Time field, and also to any time parameters in the test scenario.  The default is GMT.
   If you have delete permissions, a Delete icon also appears. Click on it to delete the line that it relates to. There is also a Result column indicating either a pass or a fail once the test has run.  
4. Add one or more Given columns by clicking Add Given and selecting from the drop-down list. Each given represents data passed into the rule package for testing. See below for special considerations for Conversation Manager template-based rules.
   Important

   If a fact's field displays in parentheses, this means that it is mapped back to more than one object in the rule template. You must select the relevant object for your test scenario. Consult the template developer if required.
5. Add one or more Expectation columns by clicking Add Expectation and selecting from the drop-down list. An expectation represents the expected results from the rule execution. See below for special considerations for Conversation Manager template-based rules.
   Important

   If a parameter displays in parentheses, this means that it is mapped back to more than one object in the rule template. You must select the relevant object for your test scenario. Consult the rule developer if required.
6. Create one or more rows of test data. Each row represents, and is executed as, one test. Give each row a name which describes the test. Drop-down lists present all the available data options for selection, as in the rule editor, and the same tooltip as in the rule editor is also presented. But no checks are carried out on the ranges of any values, in order to enable users to specify illegal conditions for testing.
7. Click Save.

For Conversation Manager Templates

Release 8.5.1 of GRS supports Test Scenarios for Conversation Manager template-based rules. The data structures for these types of rules are different, so the creation of data in the Given and the Expectation columns are also different.

With Conversation Manager, the data is in a hierarchical JSON format of Customer -> Service -> State -> Task. Any given Customer may have one or more Services. Each Service may be in at most one State at a time. Each State may have one or more Tasks. Tasks may also be associated directly with Services. The current CM Template is only interested in the Type, Start Time, and Completion Time (if any) of Services, States, and Tasks.

So the Customer, Services, States and Tasks Facts have now been added the lists of Facts that can be defined as Given fields, and the RulesResults fact has been added to the list of Facts that can be defined as an Expectation.

For each Customer ID, Service ID, State ID and Task ID you may need to define a series of parameters from the Fact model and add appropriate values to them. This data hierarchy is maintained so you can't add Task parameters where no State is defined, nor State parameters where no Service is defined, and so on.

See the Business Process/User Guide for more information.