Following are the new pages added for scriptless execution support in Orchestration

API Explorer

Link to API Explorer : <<API Explorer>>

User can get to know the API's information such as API category, Class name, API name, Applicable for, description and parameter details.

User can explore the APIs present in the Automatics by 2 ways:

• •  Using Environment Type & API Category.
  •  Using Keywords.

 Using Environment Type & API Category

       Environment Type: Select appropriate environment (for Eg. select RDKV for Video devices, RDKB for broadband devices)

       API Category: Category of the API user want to explore.

Using Keywords

       Keywords: Name of the API.

(For eg: keyword='CHANNEL_TUNE' it will list out the API names which contains the word CHANNEL_TUNE)

Other than that user can find out the Test cases(with Step Information) that is using the specific API.

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 four steps into a build utility and then user can insert that utility into any other test cases.
               The advantage of build utility is reusability since 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 utility by clicking Build Utility tab under Test Manager icon as shown below,
              Test Manager --> 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:

The build test case tab consists of the following fields,

1. Test Case ID: 

User must enter the test case specific test case name.

2. Test Case Description:

User must enter the detailed description about the test case.

3. Author:

The author will be non editable text box with the logged in user id.

4. Environment Type:

Select appropriate environment (for Eg. select RDKV for Video devices, RDKB for broadband devices).The drop-down consists of RDK-V, RDK-B and Select All. If test case is applicable for all of them then user can select the Select all. User can select multiple platforms if the test case is applicable for all of them.

5. Test type :

Select the appropriate test type.

6. Test Priority :

Select the test priority.

7.  Execution Mode :

Select the execution mode according to the way in which the test case should be executed.

8. Run On Models :

Select applicable device models.

9. RDK Component:

Select the applicable RDK Components.

10. End Point:

Select the End Point(s).        

11. User Groups:

Select the User Groups.

12. Test Suite Names:

Select the Test Suite Names if needed to group the test cases.   

To create new test suite name: Select ADD NEW TEST SUITE option. 

User can verify once whether all the details are valid and then click on the Next button. 

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

To build our own test case,

we can add three steps ;

• Add Pre-Step
• Step
• 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

Step option will create a plain step as shown below.

The fields are explained below,

1. Step No.: 

Step number will be a non-editable text box.

2. Description:

The user should enter a detailed description of the test step.

3. Command Type:

Users should select the command type according to the way in which the command should be executed. The drop-down contains all the commands including SSH, WEBPA, SNMP, and all the PRE-DEFINED commands.

4. Avail. Method:

User should select the available method. The drop down contains all the methods which the selected command type will be applicable.

5. Input:

By clicking the settings icon in the Input filed, User will be navigated to Input Configuration page as shown below.

* Command: Command that should be executed must be added in the command field.

* Validation Type: User can select how the output of the command executed should be validated. All the available validation types are explained above (in Test Step Generator) 

* Applicable Models: User can select all the device models to which the command will be applicable.

* Expected Output: The expected output of the command should be given in this field.

* Execute On Connected Client: 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, need to click on the Add button. User can verify once whether all the details are valid and then click on the Submit button. Now the command/test step detail is added. If user wants to edit, user can click on edit button. If user want to change the declaration part, click on delete button. Once all the details are added click on the submit button.

6. Step Output:

The step output of the step should be given in this field.

7. Action:

* Additional Values: 

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

is Primary Step?  if selected as false, the step will not be considered as primary and step status will not be updated.

Force Update Parent Status: By setting this value to 'Yes' user can update the status of the current step to the parent step without considering the previous step's status.

Disable Step: will be used for test case developer to disable the step. So, that specific step will not get executed during the execution.

Add Polling: if option yes selected then we have two options for polling 1. duration, 2. Iteration

Custom Error Message: By using this option, user can add a custom failure message for a step failure which will be displayed in result page after test execution.

After entering all the additional values, need to click on Save button.

* Child Steps: By clicking the plus icon, User can create child steps.

* Delete Step: By clicking the delete icon, User can delete the particular test step

• Iterational

Iterational option will create a iteration step as shown below.

The fields are explained below,

1. Step No.: 

Step number will be non editable text box.

2. Description:

User should enter the detailed description about the test step.

3. Test Type:

User should select the test type. The drop down contains LOOP and EXIT-LOOP.

4. Input:

By clicking the settings icon in the Action filed, User will be navigated to 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.

• Conditional

Conditional option will create a condition step as shown below.

The fields are explained below,

1. Step No.: 

Step number will be non editable text box.

2. Description:

User should enter the detailed description about the test step.

3. Test Type:

User should select the test type. The drop down contains IF, ELSE-IF and ELSE.

4. Input:

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

* Operator: User should select the Operator type. The drop down contains AND and OR options.

* Invert Result: User should select the NOT check box to invert condition.

* Actual Value: Actual Value of the condition should be given in this field.

* Validation Type: User can select how the output of the command executed should be validated. 

* Expected Value: Expected value of the condition should be given in this filed.

After entering all the details of the input condition, need to click on the plus icon. User can verify once whether all the details are valid and then click on the Save button. Now the command/test step detail is added.  

• Check Point

Check point option will create a check point step as shown below.

The fields are explained below,

1. Step No: 

Step number will be a non-editable text box.

2. Description:

The user should enter a detailed description of the test step

  3. Expected Result:

           User should enter expected result of the step

  4. Impact:

            User should enter the impact of the step

  5. Action:

             This field is explained above under Step.

• Import Steps

User 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

For Editing the 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 Scripts

Link to Manage Script page: <<Manage Script page>>

For enabling, disabling, cloning and updating the testcase. We are using manage script page.     User needs to create a testcase by click on this button . 

Automation ID should be specific based on the feature. Build Type needs to be mentioned based on the builds that is applicable for the testcase. Test script type should be either java or python.

Test type based on timing run of the testcases.  Summary should be on the testcase overview. Whether if face any impact while execution we need to mention inside the impact summary. 

Environment type will be based on the device. User needs to select either RDKV or RDKB. End points will be whether Rack device or Desk device, User needs to select the applicable models of the 

feature. Head End should be either HE1 or HE2. Once all fields added successfully. 

Testcase added successfully.

 We can enable, edit, clone, update details of the testcase using these butttons.  

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.

Job Manager

Link to Job manager page : <<Job manager page>>.

User once trigger the testcase can able to find the execution results by clicking this button Once testcase triggered successfully. Following image will be available.

We can find the full execution logs by clicking this button. . User can get the full execution logs and find out the pass and failure steps in detail. 

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

Device Category Mapping Page

This page is used to view the existing mapping information of device models with the appropriate category name and map the device models with categories.

When we click on Add Device Category Mapping option, we can see the below option to add a new device category mapping by selecting the device name and device category.

When we click on Device Categorization option, we can see the device categories that are available and can add new device category,

When we click on Add New Category option, we can add new device category by providing the category name.