17 Automating Without Code

This chapter provides an overview of how you can create automation scenarios in Oracle Communications Solution Test Automation Platform.

Topics in this chapter:

Overview

STAP enables users to automate workflows without writing complex lines of code. By leveraging the Behavior-Driven Development (BDD) language, STAP allows users to define automation scenarios in a clear, concise, and human-readable format. This approach simplifies the automation process, making it accessible to technical and non-technical users.

Automation Components

A well-organized project structure is essential for managing automation assets effectively within STAP.

Figure 17-1 shows a breakdown of the key project directories in STAP and their purposes.

Figure 17-1 Automation Workspace Hierarchy


Description of Figure 17-1 follows
Description of "Figure 17-1 Automation Workspace Hierarchy"

  • Action Folder
    • Contains action files required for running automation scenarios. For more information, see "Action".

    Tip:

    Maintain a clear hierarchy by creating subfolders for each product, with all related actions grouped within their respective product folders.
  • Config Folder
    • Contains the config.properties file, which stores various configuration settings for your automation project. For more information, see "Configuration Folder".
      • Environment: Contains environment-specific configurations for your automation tests. For more information, see "Environment".
      • Simulation: Contains configurations related to test data simulation.
      • Execution: Contains execution configurations that define how automation scenarios are run.
  • Scenarios Folder: Organizes your automation scenarios into a logical folder structure for improved maintainance and navigation.
  • Results Folder: STAP automatically publishes all test execution results to this folder.
  • Context Folder: Stores automation context data used to avoid redundant execution of steps during scenario automation. Refer to Context Folder for a deeper understanding.

Action

The Action component provides all necessary input to the respective plug-in. This input specifies how and with what data the plug-in should run the action.

Action files contain common information, such as Name, BDD, Type, and Product. For more information on creating an action for a specific plug-in, see "Action Execution".

The structure of the Action folder is in the following hierarchy:
  • Product Folder
  • Plug-In Folder
  • Path Folder
  • Action Folder

Figure 17-2 displays a sample action file structure.

Figure 17-2 Sample Action File Structure


Description of Figure 17-2 follows
Description of "Figure 17-2 Sample Action File Structure"

Guidelines and Best Practices

Follow these guidelines when creating the Action folder:
  • Use lowercase letters with hyphens to separate words in action file names. For example, create-new-subscription.action.json. File names should be self-descriptive and end with the .action.json extension.
  • Organize actions into sub directories based on logical groupings for better clarity.
  • Optionally, share actions across automation projects as libraries by storing and publishing them as JAR files. For instructions on using action library JARs instead of folders, see "Configuration Folder".
  • Structure your actions for easy searching and discovery by users.
  • Provide descriptive names and descriptions for your actions.
  • Use predefined tags to categorize actions and facilitate searching. Avoid duplicate tags.
  • Write a concise BDD statement to describe the action's purpose.
  • Always provide a default request/data for the action.
  • Include a sample response in the documentation to inform users about the expected output. For example, for request create-new-subscription.request.json, the response file may be titled create-new-subscription.response.json.
The following example shows how to create an action using the REST plug-in:
{
"path":"subscription/create-new-subscription",
"name":"Create a new subscription",
"bdd":"create a new subscription",
"description":"Create a new subscription in the billing system",
"product":"billing",
"actionType":"REST",
"tags":["billing","subscription","create","new"],
"resource":"subscription",
"method":"POST",
"requestType":"FILE",
"request":"create-new-subscription.request.json",
 "expectedStatusCode":201
}

Scenario

A scenario outlines the conditions and expected outcomes of a test, focusing on the overall flow and user interactions. The file extension for a scenario in Solution Test Automation Platform is .scenario.

You must create a README.md file in each scenario folder. This file should include the following details:
  • Author
  • Supported product versions
  • Revision history
  • Exceptions (cases where the scenario may fail)
  • FAQ for troubleshooting failures
  • Other relevant notes

For more information about scenarios in STAP and how to create them, see "Creating Scenarios".

Guidelines and Best Practices

Follow these guidelines when creating Scenarios:
  • Organize scenarios in a logical folder structure for improved design, execution, and maintainability.
  • Create a hierarchical folder structure to group related scenarios together, making it easier to navigate, manage, and understand the overall test suite.
  • Ensure unique scenario names. Consider adding the use case ID for clarity.
  • Write detailed scenario descriptions. Describe the use case or end-to-end scenario comprehensively.
  • Use tags to categorize scenarios for easy identification. For more information, see "Using Tags to Filter Components".

Case

A case represents a logical grouping of steps within a scenario. Cases allow you to modularize your automation scripts, improving readability, maintainability, and re-usability. Ideally, each case should focus on a single product or functionality within a broader scenario.

The file extension for a case is .case. You can break down your scenario into multiple case files under the scenario folder, ensuring easy distinction between functionalities and their test results.

Guidelines and Best Practices:

  • Break down complex scenarios into smaller, more manageable cases based on the product or functionality they interact with. You can create single-step cases to enhance organization.
  • Provide a detailed explanation of the case's functionality, including the steps it performs and the expected outcome.
  • Utilize tags to categorize cases for easy identification and filtering based on various contexts like use case, feature, or functionality. Plan your tagging strategy before starting automation. For more information, see "Using Tags to Filter Components".

Using Default Cases

You can create a dedicated setup case to define the initial data and global variables required for the scenario. This improves clarity by centralizing data setup and highlighting the scenario's dependencies. You use multiple steps within the setup case to logically group variable assignments.

Note:

If any required global variable is missing, the setup case will fail.

Step

A step is the fundamental building block of a case within the STAP automation framework. Each step represents a single action or verification within the overall case flow.

Guidelines and Best Practices

  • BDD Syntax: Utilize the Given-When-Then structure to clearly define the step's behavior within the context of the use case.
    • Given: Defines the initial state or preconditions.
    • When: Describes the action being performed.
    • Then: Specifies the expected outcome or verification.
    Complete the sentence after each keyword (Given, When, Then) with appropriate text following the comma, period, or semicolon.
  • Description: Provide a concise and informative description of the step's purpose and functionality.
  • Tags:
    • Inherit tags from the associated action.
    • Add additional step-specific tags to further categorize and filter steps. For example, product, feature, variation.
  • Data Usage:
    • Avoid hard-coding data within step definitions.
    • Utilize variables defined in the setup case to ensure data consistency and re-usability across the scenario.
  • Validation:
    • Implement robust validation checks within the step to verify the expected outcome.
    • Use clear and concise validation logic to easily identify and debug issues.
  • Data Saving:
    • Save relevant data from a step's response or result for use in subsequent steps.
    • Employ a consistent naming convention for saved variables to prevent conflicts.

Environment

In STAP, environment configuration involves defining and managing the settings and parameters needed to run automation tests across different environments, such as development, testing, and production. This ensures that tests run correctly and produce accurate results across various target systems.

Each environment has it's own environment.properties file. You can have a single test environment, thereby having just one environment.properties file, or multiple environments, with multiple environment.properties files.

Guidelines and Best Practices

  • Organize environment configurations into distinct folders within the environment_configurations sub directory. Use descriptive folder names that clearly identify the environment. For example, dev, qa, prod.
  • Name environment files using a standardized format, for example, <product>-<plugin>-environment.properties. This enhances clarity and helps prevent naming conflicts.
  • Designate a single individual as the owner of environment file updates for collaborative projects. This promotes consistency and reduces the risk of errors.
  • The environment file owner should actively communicate any changes made to other team members.
  • Utilize version control systems to track changes to environment files and facilitate collaboration.
  • Conduct periodic reviews of environment configurations to ensure accuracy, completeness, and alignment with current system settings.

Project

The project structure plays a crucial role in organizing and managing automation assets within the STAP framework. A well-defined structure enhances code readability, maintainability, and collaboration among team members.

Guidelines and Best Practices

  • Adhere to a Consistent Folder Structure:
  • Utilize a standardized folder structure within your project to organize automation components effectively.
  • Utilize the STAP reference project as a starting point for your own projects. Analyze the project structure and coding patterns to gain valuable insights into best practices.
  • Regularly review and clean up the project structure to remove unused files and folders. Keep the project well-organized to facilitate easy navigation and maintainability.
  • Employ a version control system to track changes, collaborate effectively, and revert to previous versions if necessary.

Naming Automation Components

This section outlines the best practices for naming automation components in STAP.

Files

  • Use lowercase letters with hyphens to separate words. For example, create-new-subscription.request.json.
  • Avoid special characters except hyphens.

Scenarios

There are two ways we can create Scenario:
  • Single File: Simple scenario with less cases/steps. Created in a single .scenario file. For more information, see Single File Scenario
  • Multi-Case Files Scenario (For Big/Complex scenarios): Complex multi product or end-to-end scenarios. Split the big scenario into multiple .case files and configure them in scenario.config. For more information, see Multi-Case Files Scenario

Include the use case ID for clarity. Optionally, add the product name. For example, DBE1001-New-Subscription.

Setup Cases

  • Add .setup.case to the filename. For example, 1.set-default-data.setup.case.
  • Only create one .setup.case file per scenario, and run it first. This case can be skipped when using external data configurations.

Cases

  • Use a concise and descriptive name that reflects the case's purpose.
  • Include a unique identifier derived from the end-to-end use case or product functionality. This ensures uniqueness within the case library.
  • Follow the format <case-name>.product.case to specify the product the case interacts with. For example, 2.create-new-subscription.billing.case.

Variables

  • Use lowercase letters with periods to separate words. For example, subscription.id.
  • Add Array or List to identify array variables. For example, orderItemArray, subscriberList.
  • Keep variable names concise and descriptive.
  • Use periods (.) and hyphens (-) as separators.
  • Avoid underscores ( _ ) at the beginning, as these denote global variables.

Using Tags to Filter Components

Tags provide a mechanism for organizing, categorizing, and managing all automation components within STAP, including Scenarios, Cases, Steps, and Actions. You can plan and define a consistent set of tags before starting automation development.

You can filter Scenarios for execution based on specific tags. You can also select and run Cases within a Scenario using tags as criteria. Furthermore, you can generate automation execution configurations by filtering components based on tag criteria.

The following are some common examples that you can use when setting up Tags:

  • Product Name
  • Feature Name
  • Use Case ID/Name
  • Release
  • Type (for example, Functional, Regression, Performance)
  • Priority (for example, High, Medium, Low)
  • Customer
  • Topology/Setup/Environment
  • Group/Category

Guidelines and Best Practices

  • Scenarios: Use high-level tags like release, use case, type, and priority.
  • Cases: Utilize product, feature, and priority tags.
  • Steps: Apply product, feature, and variation tags.
  • Actions: Tag with product, feature, and interface details.