• Automatics Login
• API Explorer
• Device Configuration.
• Build Utility
• Build Test Case
• Manage scripts
• Test Constants

Automatics Login

User can login into Automatics through any one of the two authentication modes - Self-Authentication or LDAP Authentication.

<Automatics Login URL>

API Explorer

Link to the page: <APi Explorer URL>

      For API's Explorer we can verify via Environment Type & API Category & Keywords.

     Select appropriate environment (for E.g. select RDKV for Video devices, RDKB for broadband devices and RDKC for Cameras). For API's Category we can verify the category of the API's.

     Using Keywords, we can search for (Ex: channel tune) it will expose all channel related API's.

API's can be verified via 

• BTC: Test cases created in Build Test Case page.
• TCG: Test cases created in Test Case Generator page.

• Device Model Configuration
  • 1. Configure device model in Device Manager.
  • 2. Configure device model in Automatics Orchestration.
  • 3. Device model in Automatics Properties 
• Device Configuration
  • 1. Configure device details in Device Manager
  • 2. Configure Connected Client device details in Device Manager
  • 3. Configure device group in Automatics Orchestration.
• Device Extra Properties Configuration

To execute tests on devices, partner has to configure device models and the device details in Automatics. 

Device Model Configuration

To execute tests on a new device model in Automatics, partner has to configure device model details in Device Manager, Automatics Orchestration and Automatics Properties.

The detailed steps of configuring device models in each component is given below.

1. Configure device model in Device Manager.

Devices to be used in the Automatics System should be configured in Device Manager. These devices are provided to Automatics Orchestration during test execution. Follow the  below steps to  add device details to the device manager database.

To Invoke API defined for Device Manager application using Swagger UI tool which is integrated with Device Manager application.

Steps to invoke an API on Swagger UI tool is available at Device Manager API Documentation#SwaggerUIUsage.

• Navigate to {protocol}://{host:port}/DeviceManager/swagger-ui.html.
• Navigate to Device Model API and invoke POST /deviceModel/add API to add new device model to the Application by providing "deviceModelName" parameters. Refer Device Manager API Documentation#DeviceModelRequest to get more details on the input parameters.
• POST /deviceModel/add API will return response as "SUCCESS" on successfully adding the device model to the device manager database.
• Refer Device Manager API documentation- Device Model page to get more details on the parameters provided and type of responses received for POST /deviceModel/add API.

2. Configure device model in Automatics Orchestration.

Automatics identifies a device model from its build name. For this, admin user has to configure device model and its corresponding build name. It requires only to map the device model and initial starting sub string of build name. The starting few letters(image prefix) in build name should be unique to a device model and this should be added in 'Image Name Prefix' text.

Steps to configure device model in Automatics Orchestration is available at Automatics Orchestration Configure Device Model.

3. Device model in Automatics Properties 

Partner has to configure model details in device_config.json deployed with Automatics Properties. The file can be found at VM where Automatics Properties is deployed at location {Apache_Tomcat_Home_Directory}/webapps/automatics/device_config.json.  Edit this file and add models details as shown below.

• For Raspberry Pi device with RDKB stack, update device_config.json as

Device Configuration

1. Configure device details in Device Manager

Devices to be used in the Automatics System should be configured in Device Manager. These devices are provided to Automatics Orchestration during test execution. Follow the  below steps to  add device details to the device manager database.

To Invoke API defined for Device Manager application using Swagger UI tool which is integrated with Device Manager application.

Steps to invoke an API on Swagger UI tool is available at Device Manager API Documentation#SwaggerUIUsage.

• Navigate to {protocol}://{host:port}/DeviceManager/swagger-ui.html.
• Navigate to Device API and try to execute POST /device/add  API to adds new device to the Device Manager database by providing valid input parameters for deviceDetailsRequest as defined in Device Manager API Documentation#DeviceDetailsRequest.
• POST /deviceModel/add API will return response as "SUCCESS" on successfully adding the device details to the device manager database.G
• Refer Device Manager API Documentation#Device page to get more details on the parameters provided and type of responses received for POST /device/add API.
• SSH login details can be configured through POST/device/add  API .It is possible to add ssh connection details in extraproperties section of this API.
• The SSH connection details configured of particular ipAddress can be obtained by POST/device/sshDetailsByIpAddress API .
• Refer Device Manager API Documentation#Device page to get more details on the parameters provided and type of responses received for POST /device/sshDetailsByIpAddress API.

2. Configure Connected Client device details in Device Manager

The steps for configuring connected clients is same as configuring standalone device as mentioned in section 1. Configure device details in Device Manager, except that it requires additional data like device login details etc to be included while adding the device.

1. While adding connected client devices, ensure that all devices under the same setup are mapped with same account id. During connected client test execution, devices are fetched based on account id and this can be used to identify each connected client setup.
2. For connected clients, the additional data should be configured in extraProperties section while adding the client device.

For eg: For wifi clients, the extra properties should have following fields.

Wifi Clients

3. Configure device group in Automatics Orchestration.

For Automatics to use devices from partner's inventory, device groups have to be configured. The device group name in inventory should be added here so that user can execute tests on devices within these groups only. Admin user can map device groups to users so that only those users mapped to device group can execute tests on device.

• Steps to Configure device group in Automatics Orchestration is available at Automatics Orchestration Configure DeviceGroup.
• Steps to map device groups to user Automatics Orchestration User Manual#ManageUserGroupAccess

Device Extra Properties Configuration

The steps for configuring connected clients is same as configuring standalone device except that it requires additional data like device login details etc.. to be included while adding the device.

• For connected clients, the additional data should be configured in extraProperties section while adding the client device.

 Extra properties can be configured in 2 ways as shown below.

• Using Swagger UI
  • The additional data related to device like serial port, login credentials  etc... can be configured in extra properties section of the device.
  • Please use the swagger API /device/update  to update extra properties.

• • Update extraProperties filed with device extra properties as shown below.

Eg: “username”:”root”

• Using Device Manager UI
  • Following page will provide the steps to add or edit  extra properties  for a device using Device Manager UI tool.

Device Manager UI User Manual#EditDeviceExtraProperties

Build Test Utility

Link to Build Test Utility : <Build Test Utility>

               Build utility in automatics is creating the frequently used steps as utility. The same utility can be injected in to any other testcases. 
               For example, if 4 steps are used in common for multiple testcases then user can club those steps into a build utility and then user can insert that utility into any other test cases.
               The advantages of build utility are reuse and it decreases the effort for user to create the same steps again and again

Create Test Utility

              Build utility can be created in the same way as build test case.
              User can create build utility by clicking Build Utility tab under settings a shown below,
              Settings --> Build Utility

Steps to include Build Utility in Test cases

             First user should create the repeated steps as utility as shown above.

             Then user can add that utility as a step while creating the test case as shown below,

 If user want to include the utility in test case below steps should be followed,

• • Select command type as USER_DEFINED_UTILITY and then automatically all the build utilities created will be loaded.
  • Then user can select the utility that must be included in the testcase as shown above

Build Test Case

Link to Build Test case : <Build Test case>

The build test case tab will be as shown below:

For Build test case the Test case Id should be unique and different, and Test Description should be correct way based on the Testcase ID. In Environment Type Field Select appropriate environment (for Eg. select RDKV for Video devices, RDKB for broadband devices and RDKC for Cameras and EXTENDER for Extender devices). Test type and Test Priority should be in the Unique way. Run on models needs to be mentioned like what are all the devices that are applicable for the Test case ID. For each test case id, we need to mention the models that needs to execute. User can verify once whether all the details are valid and then click on the Next button.

 Then user will be navigated to Build your own Test case... page as shown below.

For Build our Own Test case 

we need to add three steps ;

1. Add Pre-Step
2. Step
3. Add Post-Step

By clicking Add Step button, the User will get a drop-down as shown below.

All the options that are present in the drop-down are explained below,

Step name 

Step No will be in non-editable one. Description should be clear based on the test step. User can select the Command Type based on each step. Based on the API's the methods will be applicable for each step.By clicking the settings icon in the Input filed, User will be navigated → Input Configuration page.

For Command User needs to add the command inside the command field. User can select how the output of the command executed should be validated. Select all the device models to which the command will be applicable. The expected output of the command should be given in this field. If the selected execution mode of the test case is Connected Client, then user can select Device-Config and Clients. After entering all the details of the input command, we need to click → Add button. User can verify once whether all the details are valid and then click on the Submit  button.Now command and Test step added successfully. If user wants to edit can click on edit button. If user want to change the declaration part, click delete button. Once all the details are added click on the submit button.

By clicking external-link icon, User will get Additional Values window as shown below.

Iterational option will create a iteration step as shown below.

Step number will be non-editable text box. User should enter the detailed description about the test step. For Test Type should mention  LOOP (or)
 EXIT-LOOP. After click the settings icon in the Action filed, It will be automatically navigate to the Add Iteration or Duration page as shown below.

We need to provide either Iteration Count or Duration in Seconds and click -> Save button. Now the Command / Test step added successfully.

Same as tterational . In Test Type it contains IF, ELSE-IF and ELSE.

By clicking the settings icon in the Action filed, User will be navigated to Add Condition page as shown below.

User should select the Operator type. The drop-down list consists of AND & OR options. For Invert Result don't select the NOT check box to invert condition. Actual Value of the condition should be given in this field. User can select how the output of the command executed should be validated. Expected value of the condition should be given in this filed. After entering all the details of the input condition,  click on the plus icon. Verify once whether all the details are valid and added successfully click on the Save button. Command/test step details added successfully.

• User defined option will be navigated to Add User Defined Steps as shown below.

user can see all the available steps created in Test Step Generator page. By using Filter., We can find the added test step (Saved in a test step generator page).In  all the available steps, we can select the required test step. After selecting the test steps, click '>'. Then user can see the required steps in Selected Steps Column. After click on the Add Steps button. Now the steps will be added in our Build your own Test case... page. After creating/adding all the test steps, click Save button to save the changes and it will be added in Available test cases table.

•   From Import steps we can import a test step from the same testcase by clicking the Import Steps Button in Action.  By providing the Step Number(case-sensitive) in the given textbox and click Import, given step will be cloned/imported.

EDIT,CLONE& DELETE Test case

For Editing the Testcase test case details, then click the pencil icon in Action column in Available test cases table. Then user can edit the entered details then click on Save button to save the changes or by clicking the Next button user can add/remove/edit test steps details and click Save button to save the changes.

For Cloning the Testcase

 To clone or get a copy of a test case, then click the copy/clone icon in Action column in Available test cases table. Then user should provide a unique test case id, and user can edit the existing details and can add/remove/edit the test step details. By clicking the Save button the cloned test case will be added in Available test cases table, and it will not change the existing test case.

For Delete Test Case

By clicking the delete icon in Action column in Available test cases table, user can delete the test case. 

Test Constants

Link For Test Constants :<Test Constants>

               Test constant here in automatics means the command or log file or any string that gets used more frequently is called as a test constant
               We can declare the test constant once and can use the same in multiple places.

              The main advantage of the test constant is it avoids the stabilization effort or test case developer can change the value at one place rather than spending effort on searching all the testcases that uses the string.
              Also, whenever user changes any value of the test constant, it impacts all the testcases that are using that test constant.
              So, while editing test constant one should be very careful as its impact might be huge

Create Test Constant

              Test constant can be created through test constants page under settings tab. Settings →  Test Constants
              User should click on Add Constant button and add the constant name and constant value as shown below.
              Constants name must be unique.

Steps to include Test Constants in Test cases

             To add test constant in test case we need to use {{as the trigger. When user enters {{then all the test constants are listed under as shown below.
             Test constants always starts with TC$ and user can select the test constant as per the requirement

Manage Test Trigger

Link for Manage Test Trigger :

<Manage Test Trigger>

For Both RDKV & RDKB same job trigger page

For Select Service name default it will be Functional Verification if user wants he can select CI verification based on the requirement.Build name should be the same one that is available inside the box details. Endpoint should be either Desk box or Rack device. Partner Test is not the mandatory one.If we want we can select the box and add COMCAST. Test types needs to be selected based on the hours and days execution time. Environment type should be either RDKV,RDKB,RDKC.Is Quick Test required it will selected as a default one . We can disable that if we are not using QT .

Once all the details added successfully User will be navigate to the Following page.

In Automation ID user needs to select the Automation ID . Once the ID selected it will available inside Short-listed Automation Ids. Click on Next button. It will be navigated to the Trigger Execution manually.

For Mac address select check box E.g 00-xx-xx-xx-xx-xx and for good devices click on -> . . It will list the good devices. We can have Schedule trigger option also available, and the time needs to be mentioned. Device Group we can select based on the Automation ID. Build Appender and Notification mail will be mandatory. Source Repo needs to be mentioned based on the repo's available in the repository.Once all the details mentioned user Should click on the Trigger Job button. Once done Trigger will start successfully and via Job manager Tab.

By Clciking this we can see the child Jobs  name . After that click on  Then Jenkins Execution logs will be available . We can verify pass and Failures of all the steps.