Training
What does it mean to train my virtual assistant?
It is the act of placing your assistant to understand how the interactions with the user will be, considering the dialogs constructed. Whenever new interactions are added, the assistant must be retrained so it can react as expected in a conversation.
The only prerequisite for scheduling training from your virtual assistant is to have at least a dialogue already registered.
Before getting started
Make sure that all parametrization and configurations are correct and there is at least one dialog created.
Procedure
Schedule training
- After accessing the platform, go to the menu "Training";
- Click on "Schedule";
- Define the scope of the update you want, with the following options: Dialogues, Complete, Skills (Text - Button - Image) or Custom skills;
- Inform the day and time for the training to be performed.
⚠ Attention!
Remember to choose dates and times that will have less impact on ongoing services, if any.
🖊Note: The duration of each training will vary according to the volume of conversation flows built, but do not worry, once completed your assistant is automatically ready to act, either in the conversation test within the platform or in the production environment.
At any time, you can start a conversation with the assistant to check the effectiveness of its interactions by clicking on the floating icon located in the lower right corner of the screen. Remember that it will reflect the knowledge added from the latest training.
Troubleshoot
When finishing a Training
After you start training, the app does not have an option to end the process, but sometimes this might be necessary. The following instructions will help you complete this task, which consists of cleaning the task queue and terminating the instance related to the process.
1. Access the service Simple Queue Service on AWS dashboard 2. Find a queue named citsmart-anuvaassistant-training-<ambiente> and select it. For example, the name of the environment "homologation" on the queue would be citsmart-anuvaassistant-training-homologation. 3. Click Actions and select "Purge" 4. Type the required term and click the button "Purge" 5. After this, the queue should be empty.
To terminate the instance, follow these instructions:
1. Access the service EC2, on AWS dashboard. 2. Click the link Instances (running) 3. Search for an instance that contains the term "spot" 4. Select the instance 5. Click Actions and request to stop the instance, and confirm your decision by clicking the button "Stop" 6. Click Actions and request to terminate the instance, and confirm your decision by clicking the button "Terminate" 7. After this, a message should appear showing the removed instance.
Training does not start
When trying to start a scheduled training, an error might happen and the training will not start. One of the causes for this is when the schedule of python is broken and fails to put the training on queue.
1. To confirm if the error is due to the schedule of python, look for the queue named "citsmart-anuvaassistant-training-homologation" on AWS Simple Queue Service. 2. Under normal situations, this queue should show no messages. 3. If there is a mistake, the queue will show 1 scheduled in on the message column. 4. If that's the case, it is necessary to stop and restart the EC2 instance "anuvamultitenancyapihom_app". 5. After restarting the instance, remove the scheduled training and schedule it again.
The Intents Ranking is not presented
This problem happens when the instance anuvamultitenancyapihom_app has a change on IP, for some reason, and the new IP is not on the list of authorized access of the Elasticsearch service. If that's the case, an error message will appear on several points when showing the rankings.
To solve this problem, the IP of the instance anuvamultitenancyapihom_app must be added to the authorization list, under Elasticsearch access policy. To do this, it is necessary to obtain the current IP of EC2 anuvamultitenancyapihom_app, access the Elasticsearch service panel, and include the IP on the authorized list. To obtain the IP, follow these steps:
1. Access EC2 instances administration panel. 2. Filter instances that are running/active 3. Select the proper instance and copy the IP address.
To access the Elasticsearch panel and include the IP on the list:
1. Select the menu Analytics > Elasticsearch Service 2. On the dashboard, click My Domains and select the correct service 3. After selecting the service, click the button Actions > Modify Access Policy 4. On this page, add the IP number on the authorization list and click on "Submit" to apply changes.
Automated Tests
Software tests are included in the Application Lifecycle Management (ALM). It is a primordial step to ensure the quality of the product delivered to the clients or to be used by the developers' team to confirm the assertiveness.
We automatize these tests to avoid repetitive manual jobs, obtain quicker feedback, save time running tests in sequence, and make sure we are always testing consistently with the same preconditions and expectations.
Generally, the reasons for testing are:
- Verify if the program is within the client's expectations;
- Verify any bugs before the clients;
- Detect design problems;
- Make sure the system is stable;
- Ensure the quality of the work of the developers' team;
To automatize tests of the referred project, we use the Cypress tool. One of the great advantages of Cypress is that, while most test tools run outside the browser, running remote network commands, Cypress is executed on the same execution loop as the application being tested, which allows for greater interactivity.
The following procedures will instruct you on the installation and basic configurations to start and interact with the testing project. It will also teach you how to document the standard criteria used for the best practices.
Functional Test
This will test all the functioning requirements of the application. It will quickly verify if the app is able to perform the functions it was designed to do, and it can cover all functions within the scope, BackEnd, and FrontEnd.
Installation and Configuration
Beforehand, you must have installed Node.js, and IDE VsCode is also recommended. If these requirements are met, follow these instructions:
- Create the working directory: Create a directory for the project, here we suggestively create the directory: cypress-tests $ mkdir cypress-tests
- Create the project: Access the directory that was created and start the project with the command below. This command will generate all the required initial structures: $ npm init -y
- Install cypress: Remaining in the project directory, install Cypress as indicated: $ npm install cypress
If necessary, complete instructions can be obtained on the official documentation.
🖊 Note: If you wish to install a specific version, 4.6.2 for example, use the following command:
<i>$ npm install [email protected]</i>
Configure the VsCode
As we previously suggested, we will use VsCode as IDE for developing our tests, therefore it should be installed beforehand. We will add to the file package.json the command used to run the project. This will hasten the procedure. Edit the file package.json, and in the topic script, add the following command:
$ npm run cypress:open
Run the Project
After including the previous command, the project can be executed with the command line:
$ npm run cypress:open
or through VsCode, under Outline > NPM Scripts > package.json > cypress:open > button "play"
Structure of directories and files
The following structure of files is recommended to keep the organizational standards of the project. However, there are no technical restrictions to use other standards, and the best practices described are just a convention for the referred project:
- I. Fixtures: Directory intended for files that will contain dictionaries with data to be used by the tests in filling out information. Here are some good practices:
- The use of fixtures is a best practice to hasten the development and maintenance of the project, as it will gather all the variable data of the project in a single place.
- For organizational purposes, there must be a fixture file for each test file.
- Overly extensive blocks should be avoided. When the volume is too big, they should be divided into smaller blocks.
- The commands should not deal with the data directly. The data should be manipulated in the intents.
- II. Integration: Directory intended to contain the tests to be performed in the application. Here are some good practices:
- These files should be restricted to the logic of the tests and data manipulation, leaving the commands to deal with the execution procedures and interactions with screens and api ‘ s.
- For organizational purposes, there should be one command file for each test file.
- The test files should not deal with screen components directly. These components should be managed by the commands files. Therefore, locators files should not be imported.
- The test files import fixture files to manipulate data and pass them over to commands
- III. plugins: Directory intended to contain the record of any plugins used in the project.
- IV. support: Directory intended to contain code support for test files, which should contain the following directories for better grouping:
- commands: These files are used by the tests, located in the directory integration. It must contain the command codes used by the tests. Besides individual command files for each test, there is also a Global use file. Here are some best practices:
- Using commands is a best practice to hasten the development and maintenance of the project, as it avoids using redundant codes.
- For organizational purposes, there must be a command file for each test file.
- Commands should not deal with data directly. Data should come from the parameters, and they should not import fixture files.
- The commands import locators files.
- Keep the files in alphabetical order, as it makes finding and reading easier. Besides, it also leads to intuitively creating a naming pattern for them.
- The global commands file, as the name implies, should contain the commands for global tests. A good example of this is the method of URL verification, which can be the same for the whole app.
-
- llocators: Directory meant to contain files that register the access addresses of widgets, URLs, and other addresses. As determined by the best practices mentioned before, locators files should be imported and used by the commands. Besides individual locator files for each test, there is also a Global use file. Some best practices are:
- The use of locators is a best practice to hasten the development and maintenance of the project, as it groups the access to widgets and URLs in a single place.
- Locators files should be imported by commands.
- There must be a locator file for each test file.
- Overly extensive blocks should be avoided. When the volume is too big, they should be divided into smaller blocks.
- V. node_modules: Directory meant to contain the registry and library files used by the project.
- VI. cypress.json: Central configuration file of Cypress. It basically contains values of system variables of global use. Use this file to register URLs used by the system.
- VII. package.json: Data file containing application registries and scripts that automate initialization processes.
- VIII. package-lock.json: File containing registries of external libraries used by the application.
- IX. .gitignore: File containing relation of files and or directories that should <b>not</b> be versioned by Git.
- X.index.js: File containing initial calls of the test system.
Naming Standards
New files should follow the naming standards bellow:
< contents > < Module > .js Examples:
- Fixture files: datasContext.js / datasTheme.js
- Commands files: commandsContext.js / commandsLogin.js
- Locators files: locatorsLogin.js / locatorsTheme.js
🖊 Note: Notice that plurals should be used only in the contents, as this usually refers to more than one item, and that the identification of the module always starts with capital letters.
Within this structure, there is an exception regarding the actual test files, which are in the integration directory. These files should be named according to the following standard:
< módulo > .spec.js
Examples:
- context.spec.js
- login.spec.js
- theme.spec.js