Business Edition Cloud Customer Testing Environment
The Business Edition Cloud (BEC) Customer Testing Environment is a phrase used to describe a logically partitioned configuration setup within a customer tenant environment in the Genesys Cloud that allows its users to achieve the following:
- Test changes in the logic of customer IVR or routing applications.
- Develop and test new IVR or routing applications.
- Introduce changes in parameters of IVR or routing applications, and test the effects of these changes.
- Create or change configurations for new business groups.
The customer testing environment allows users to validate all the above changes, without affecting in-production interaction traffic. After validating, users can then plan a roll-out of the changes into a live environment.
The Customer Testing Environment runs in the Genesys Cloud, and consists of several interconnected layers within an existing customer tenant environment. Those layers are:
- Backend application layer: responsible for processing routing and IVR logic; handles voice and multimedia interactions and recordings; and aggregates and presents reporting data. This layer is shared by both the production and testing environments. The backend application layer uses Configuration Layer objects as process parameters.
- Configuration layer: comprises sets of Configuration Layer objects, for instance agents, agent groups, skills, and queues, as well as instances of routing and IVR applications and their parameters. This layer is partitioned to segregate that part of the configuration pertaining to serving the logic of the Production call flow separately from the logic of testing call flows.
- Telephony resources layer: allocates certain resources (such as toll-free numbers) to routing and IVR applications. This layer is partitioned to separate call flows for production and testing traffic by assigning the corresponding telephony resources (production or testing) to the appropriate routing and IVR applications.
- User interfaces layer: provides access points to manage objects in the Configuration layer, develop or modify routing or IVR applications, view results of the interactions in reporting and call recording interfaces. This layer is shared by both the Production and Testing environments.
Provisioning the Customer Testing Environment
Since Customer Testing Environment is based on the shared Backend and User Interfaces application layers, no additional system level deployment or provisioning are necessary from Genesys to support its activation. Genesys is responsible for activation of additional telephony resources to be used in the Testing Environment. All provisioning in the Configuration layer necessary to support Testing environment as well as assignment of corresponding activated Telephony resources can be accomplished by authorized customer administrators. Two interfaces accessible through the customer Hub should be used for this purpose:
- Platform Administration - Platform Administration helps you to manage your user accounts and configure settings to maintain your contact center.
- Designer - Genesys Designer helps you to design assisted service or Routing applications, as well as self-service or Interactive Voice Response (IVR) applications.
At a high level, the overall provisioning steps are as follows.
Preparing the Necessary Configuration Objects in Platform Administration
Before creating a set of configuration objects, Genesys recommends that you establish a consistent naming convention for them. This convention will serve two goals:
- It will allow you to visually differentiate configuration objects used for processing Production call flows from those used in testing flows.
- It allows you to take advantage of a Genesys Designer capability: by using parameterized prefixes for objects used in routing logic you can turn this prefix on and off for testing and production purposes. In most cases, the naming convention may consist in applying a certain prefix to configuration objects.
Once you establish the naming conventions, you should create the following types of objects:
- Skills - skills will be used in skills-based routing by routing applications. Genesys recommends that you create the same set of skills for testing purposes as you would for production - differentiated by testing prefix. For instance, in Production you might name the skill "Skill_X," and in testing that same skill would be named "Test_Skill_X."
- Queues - virtual queues will be used by routing applications. It is suggested you create the same set of queues for testing purposes as would be used for production - creating differentiation by testing prefix.
- DN extensions - test agents will use DN Extensions to receive and make test calls. (For testing, these extensions can be configured with call recording disabled.)
- Agents - test agents will log into the Agent Desktop to handle test calls. These agents will also need to be assigned test skills and DN extensions to carry out various tests.
- Agent Groups - test Agent Groups include test Agents, and can be used to monitor test activities through Real-Time and Historical Reporting.
- DN Groups - test DN Groups include test Queues, and can be used to monitor test activities through Real-Time and Historical Reporting.
A special case for creating configuration test objects would be the introduction of a new business group or unit. In this case, instead of artificial test entities, you would use this testing model, but, instead, create a set of objects representing real business groups skills, agents, and groups. Since the agents in new business group will not be taking live production calls until a designated cut-over moment, it is safe to use this configuration in testing activities as well.
Another special case is the introduction of changes to Agent Desktop configuration, for instance, to test before promotion to production status. In such a case, special Agent Group objects can be created for testing purposes, and any desired changes in the Agent Desktop configuration can be applied to them, tested, and then requested for promotion to the rest of the agents.
Preparing Telephony Resources
In order to use test phone numbers in the Customer Testing Environment, you will need to allocate designated numbers on the customer network, and then ask Genesys to provision them in the Genesys Cloud environment. You would accomplish this by means of a standard provisioning request to Genesys Customer Care. These designated numbers should be used exclusively for testing activities.
Preparing Testing Applications in Designer
The next provisioning step is to prepare an instance of one of your routing/IVR applications to be used for testing activities. You can do this in Genesys Designer, which is accessible from the customer Hub. There are two ways to prepare such an instance in Designer: with a new application or as a change to an existing one.
- To prepare an instance of a new application representing a new customer call flow, choose the Add Application option.
- To introduce changes to an existing application, choose the Clone option on an existing application.
Genesys recommends you use a consistent naming convention for naming Designer applications, one that includes an application version identifier. It is also important in Designer to define a prefix parameter that you can use to switch on and off for configuration objects being referenced in the Designer applications logic.
Assigning Test Configuration Objects and Telephony Resources in Designer
Once configuration objects and Designer application instances are ready, you can start developing the IVR/routing logic or making changes in Designer applications. Designer will reference the test configuration objects you created in the blocks responsible for routing decisions (usually, with the help of each object's parameterized prefix). Additionally, a test phone number will be assigned to the application in Designer so that it will be ready for actual testing activities. Schematically, the relationship between Designer, routing application, and test phone number is depicted here:
Test activities in the Customer Test Environment can start as soon as you have made the corresponding changes in routing/IVR applications or in the Desktop configuration. Usually, testing will involve the following:
- Preparing the test plan/cases that cover all the target scenarios implemented by your routing/IVR application.
- Preparing the necessary test data in your customer backend systems (assuming that the routing/IVR application logic includes calls to these backend systems).
- Preparing test agents with the necessary combinations of skills to cover the target test cases.
- Making the test agents ready to take calls at the Agent Desktop and, then, executing test cases by dialing the test phone number to follow and observe the target logic in IVR/routing applications.
- Observing expected test cases results either by direct observation on the IVR or in the Agent Desktop, or by inspecting call results in your reporting interfaces.
Testing activities can be executed in several cycles, and can result in several correction and testing phases until the target success criteria are met. The process of moving application from development to test phase is depicted here:
Promote Your Changes from the Testing to the Production Environment
In most cases you can promote changes to the Production environment yourself, without involving Genesys Customer Care. Below are the typical steps you need to perform in preparation for the production roll-out, and during the roll-out itself:
- Prepare additions/changes in the Configuration layer to support new/changed routing applications logic. This includes additional skills assignments to Production agents if it is called by the routing logic.
- Train agents to understand changes in the routing and their new/changed responsibilities.
- Prepare new production toll-free numbers, if necessary.
During the cut-over:
- Switch off any testing prefix parameters on Designer applications, if they are set.
- Apply the final skills changes to your production agents, if necessary.
- In Designer, switch new/changed routing/IVR applications to the Production-specific phone numbers.
- Perform post-change validation.
Note: In case you need to promote configuration changes to the Agent Desktop that need to be applied globally to all agents, submit a Service Request to Genesys Customer Care. The process of promotion of a test application to production status is depicted here:
Saving and Publishing Changes to Your Test Application
Saving your work: Genesys recommends manually saving your work often, especially after you have made important changes. If you forget to save, Designer periodically creates a temporary backup of your work.
Click Save Flow to save your application. This action saves your work and performs some validation checks on your application. If no problems are found, a green check mark appears beside the Validation Status field. Otherwise, if problems are found, a warning icon appears beside the Validation Status field. You can click the warning icon to display the list of warnings.
When you are ready to test and deploy your application, click Publish. Designer performs another validation test on your application and, if no errors are found, it generates the VoiceXML and SCXML runtime code that can be run on the GVP and ORS platforms, respectively.
NOTE: Designer saves your latest edits if you are logged out due to inactivity. After you log in again and open the application, Designer displays a prompt to indicate it has found a local backup of your application, along with a comparison of timestamps between this local backup version and the version that is saved on the server. In this prompt, you can click one of the following buttons:
- Last Manual Save - Designer discards the local backup and opens the server version of the application. The discarded backup version cannot be recovered.
- Local Backup - Designer recovers the local backup version. You can then click Save Flow to save your changes to the server.
If errors or warnings are found in your application, you can click the exclamation icon beside the Validation Status field to display the Validation Issues list.
The Validation Issues list displays warnings in yellow and errors in red. Code generation can complete if warnings are present, but fails if errors exist. Click a warning or error to return to the block containing the issue and address the problem.