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.
Before getting started
Make sure that all parametrization and configurations are correct and there is at least one dialog created.
Procedure
How to train Anuva
In the Training screen, it is possible to schedule updates so that your Anuva can interact with the user considering the last added knowledge. This functionality allows scheduling the training according to your need and can even define recurrence.
- 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.
INFORMATION:
The duration of the training will depend on the volume of dialogues registered but do not worry, once the training is completed, Anuva will be updated automatically. At any time, you can start a conversation with Anuva 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
Finalizing a training
After you start the 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 clicking the button "Stop"
6. Click Actions and request to terminate the instance, and confirm your decision clicking the button "Terminate"
7. After this, a message should appear showing the removed instance. The 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's necessary to stop and restart the EC2 instance "anuvamultitenancyapihom_app".
5. After restarting the instance, remove the scheduled training and schedule it again.Intents ranking not showing
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 the Elasticsearch access policy. To do this, it's 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 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.
1. 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.
2. 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 work directory: Make a directory for the project, for example, cypress-tests $ mkdir cypress-tests
- Create the project: Access the new directory and start the project with the following command, which will generate all of the necessary structure: $ npm init -y
- Install cypress: Still on the same 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:
$ npm install [email protected]
3. Configure 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:
$ "scripts": { "cypress:open": "cypress open" 4. Execute 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"
5. Files and directories structure
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: | The Directory is destined to files that will contain dictionaries with data used by the tests when filling information. Some best practices are: |
|---|
- 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: | The Directory is meant to contain tests to be performed by the application. Some best practices are: |
|---|
- 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: | The Directory is meant to contain registers for eventual plugins used in the project. |
|---|---|
IV. Support: | The Directory is meant to contain support codes to the text files, and it must contain the following directories for grouping purposes: |
- 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. Some best practices are:
- 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.
- Locators: 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.
- 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: | The Directory is meant to contain the registry and library files used by the project. |
|---|---|
VI. cypress.json: | The Central configuration file of Cypress. It 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: | The File contains registries of external libraries used by the application. |
IX. .gitignore: | The File contains the relation of files and or directories that should not be versioned by Git. |
X. index.js: | The File contains initial calls of the test system. |
6. Naming standards New files should follow the naming standards below:
< 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:
< module > .spec.js
Examples:
- context.spec.js
- login.spec.js
- theme.spec.js