Step’s unique Software automation as Code approach (short Automation as code) enables developers to define software automation workflows for the whole DevOps lifecycle as code alongside the product code.

This concept is the key enabler for shift-left in not just testing but for all disciplines relating to software automation. This ranges from large scale E2E acceptance tests to load and performance tests, synthetic monitoring, RPA, and much more.

This pages presents the use-cases enabled by the Automation as Code approach. If you’re looking for the technical documentation related to the implementation, refer to Automation packages.

Use-cases

The range of practical applications of the Automation as code approach is wide and covers all relevant stages of the DevOps lifecycle.

This section gives a quick overview of the main applications grouped by DevOps phase.

DevOps Build phase

In principle, Step is flexible enough to automate build-related tasks as well; however, other established tools like traditional build tools and CI/CD pipelines are specifically designed for this purpose, and we recommend using these. In fact, this stage usually includes building the actual automation code, along with the application itself.

DevOps Test phase

Traditionally, this phase includes at least functional tests (i.e. Unit Tests, End-to-end Tests). The coverage can be significantly broadened by leveraging Step and the Automation as Code approach at this stage, enabling a wide range of additional test scenarios, such as large scale end-to-end integration tests or load tests (browser-driven in particular). One of the key difference with classical CI/CD pipelines is the native ability of Step to parallelize executions which makes it particularly suited for those scenarios.

Here is a brief list of various possible use cases:

Automated load and performance tests

• Goal: Fully automated load and performance tests for early detection of performance and scaling issues
• The scripts (VU), load model and SLOs are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • All configurations (Load model, SLOs) defined as YAML using the open Automation Package Syntax (YAML)
  • Load test execution triggered by CI/CD pipeline and then orchestrated by Step controller
  • Scalable Step agent grid for large scale parallel, multi-zone executions

Automated large scale end-to-end tests

• Goal: Fully automated large scale E2E tests for early detection of integration issues
• The scripts and test plans are defined as code by the developer
• Features:
  • Multi application support: design complex E2E tests across multiple applications
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • Test configuration defined as YAML using the open Automation Package Syntax (YAML)
  • Test execution triggered by CI/CD pipeline and then orchestrated by Step controller
  • Scalable Step agent grid for large scale executions

Automated creation of test data

• Goal: Fully automated creation of test data after deployment to the test environment
• The scripts and data are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • Support of CSV, XLS, JSON, YAML or database data sources
  • Test data creation triggered by CI/CD pipeline and then orchestrated by Step controller
  • Scalable agent grid for large scale parallel executions

Automated monitoring of the test environment

• Goal: Permanent monitoring of the deployed application in the test environment for proactive detection of issues (performance or availability)
• The scripts (monitors), schedules, SLOs, and alerting rules are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • All configurations (Schedules, SLOs, alerting rules) defined as YAML using the open Automation Package Syntax (YAML)
  • Monitoring deployed by CI/CD pipeline and then scheduled and periodically executed by Step controller

DevOps Release phase

Whereas Step would be flexible enough to automate the tasks related to the release of an application, this is not its intended primary scope, therefore it is recommended to use pipelines or build tools specifically tailored to such tasks.

DevOps Deploy phase

While the Test phase is the most suitable one for demanding load, performance, or integration tests, one may wish to include somewhat smaller-scale tests during the deployment in production to ensure that the system is functioning correctly.

Automated smoke tests

• Goal: Ensure correct operation of the application by running smoke tests after deployment in production
• The scripts and test plans are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing automation solutions
  • Test configuration as YAML
  • Test execution triggered by CI/CD pipeline and then orchestrated by Step controller

DevOps Operate phase

One of the unique features of the Automation as Code approach of Step is the ability to define automation for post-deployment phases and thus workflows in production. Technically, such logic is deployed to a Step instance by the CI/CD pipeline, where it can then be invoked to perform the respective operations in the application. Examples include:

Self-service RPA tasks

• Goal: Expose self-service RPA tasks
• Example: you’re operating a purchased software for which you want to propose self-service jobs that automate repetitive tasks to your users
• The scripts (RPA definitions), business inputs and access rules (who’s allowed to execute the service) are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • All configurations (SLOs, alerting rules) defined as YAML using the open Automation Package Syntax (YAML)
  • Available RPA services can be triggered from the full-featured Step UI, or via REST

Automate recurrent tasks

• Goal: Regularly automate otherwise manual routine tasks such as maintenance or cleanup jobs etc.
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing tests (Selenium, Cypress, Playwright, K6, etc)
  • All configurations (Schedules, SLOs, alerting rules) defined as YAML using the open Automation Package Syntax (YAML)

DevOps Monitor phase

Similarly to the Operating aspects, where automation packages are used mainly to simplify otherwise manual tasks and interactions, they can also be used in a proactive way to detect issues on running production servers using Synthetic Monitoring. Again, the respective logic is deployed by the CI/CD pipeline to a Step cluster, which then actively monitors the running application after its deployment.

Synthetic monitoring

• Goal: Permanent monitoring of the deployed application in production for proactive detection of issues (performance or availability)
• The scripts (monitors), schedules, SLOs, and alerting rules are defined as code by the developer
• Features:
  • Support for protocol and client (e.g. browser, mobile app) based automation
  • Possible integration of existing automation solutions
  • All configurations (Schedules, SLOs, and alerting rules) defined as YAML
  • Monitoring deployed by CI/CD pipeline and then scheduled and periodically executed by Step controller