This section explains how to register and use existing Keywords. To learn how to develop custom keywords, check the Developer guide overview.

What is a Keyword?

Keywords are the fundamental building blocks of Plans. They encapsulate automation logic, often referred to as scripts.

A Keyword can represent a fully automated flow or a more granular action, such as a user interaction or an API call. In general, finer-grained Keywords are preferred because they are easier to reuse across multiple business flows through Plans.

Keywords can receive inputs and produce outputs. These outputs can then be used as inputs for other Keywords, enabling data to flow smoothly between automation steps.

By defining data or objects in input and output fields, Keywords support:

• reusable automation logic
• seamless value transfer between Keywords
• assertions and validations
• clearer Plan structure

Keyword sources

Step supports several Keyword types, but their automation logic always comes from one of three sources:

• Prebuilt library — The logic is already implemented in an officially maintained Step Keyword library. No code is required. See Prebuilt Keyword Libraries below.
• Custom keyword — You write the logic yourself in one of the natively supported languages: Java, C#, JavaScript, or TypeScript. See Custom Keywords below, and the Keyword Development guide for how to write one.
• External asset — The logic already exists outside Step, such as in a JMeter test plan, Cypress project, script, or similar asset. Step orchestrates the asset as-is. See External Assets below.

Step additionally supports Composite Keywords to compose and alias existing keywords, and a set of always-available Local Functions.

Prebuilt Keyword Libraries

Step ships a small set of officially-maintained, ready-to-use keyword libraries — including a system library used to execute external assets through a command line, see External Assets below. Reach for a prebuilt library first when one already covers your need: it requires no development effort and is maintained by Step. See also Local Functions below for single, always-available keywords that don’t need to be referenced as a library.

For the full list of libraries and keywords, where they are published, and how to import or consume them, see Prebuilt Keyword Libraries — the reference page for these libraries.

Custom Keywords

Step supports the implementation of custom Keywords: automation logic that you write yourself using the driver, framework, or library of your choice.

Common examples include Playwright, Selenium, Appium, OkHttp, and gRPC, but you are not limited to this list. Any library available in your chosen language can be used.

Step supports custom Keywords in the following languages:

• Java: Written as annotated Java methods following the Keyword API and executed on the Java agent.
• C#: Written as C# functions following the Keyword API and executed on the .NET agent. For the C# project setup, see the C# Keywords page.
• JavaScript / TypeScript: Written as exported functions following the Keyword API and executed on the Node.js agent. For the TypeScript project setup, see the TypeScript Keywords page.

Step also supports Script Keywords: single-file scripts written directly in the Step UI or in Automation Packages and executed on the Java agent. This covers Groovy (limited to a single script file rather than a full project — you might find some Groovy code samples that can be wrapped into Keywords in our library), and, as a legacy option, JavaScript via Nashorn — superseded by native JavaScript/TypeScript on the Node.js agent above.

For a hands-on guide to writing custom keyword code (lifecycle, hooks, session, error handling, best practices), see Keyword Development.

External Assets

Sometimes the automation logic already lives outside Step — an existing JMeter test plan, a Cypress project, a script — and you just want Step to run and orchestrate it as-is, without rewriting it as a Step keyword. There are two distinct mechanisms behind that idea, and the difference matters.

Native support (via plugin)

Step provides dedicated plugins for several external asset formats. These plugins understand the asset format, parse it, execute it with the appropriate runner, and map the results back into Step’s report structure.

Depending on the Step edition in use, the following Keyword types are supported:

• Cypress: A keyword for running Cypress commands or specs. See the Cypress plugin guide.
• SoapUI: A keyword for executing a SoapUI project. See our SoapUI plugin guide.
• JMeter: A keyword used to execute a JMeter Test Plan. See JMeter plugin guide.
• Grafana K6: Open source tool for Performance testing. See the Grafana K6 guide.
• QF-Test: A keyword representing the execution of a QF-Test test suite.
• Oryon: A keyword representing the execution of an Oryon keyword.
• SikuliX: Open source tool for UI automation. See the SikuliX plugin guide.
• Silk Performer: A Load testing tool by openText. See the Silk Performer guide.
• PDF Test: A keyword designed for comparing PDF documents. See our PDF and Image compare plugin guide.

To access a comprehensive list of all the supported plugins, please refer to the Plugin section.

Generic command execution (no dedicated plugin)

For assets that do not have a dedicated Step plugin, you can use the prebuilt-library system to execute them through a command line.

Use ExecuteBash or ExecuteCmd, depending on the operating system of the target agent, or use the generic, shell-less Execute Keyword. Provide the command to run, such as npx playwright test or mvn clean verify, and Step executes it while reporting the exit code and command output.

This is not a separate integration mechanism. It uses the same prebuilt-library system, applied to an asset that exists outside Step.

Generic command execution is more flexible than a native plugin, but less integrated. Step does not understand the asset’s internal structure or results; it only reports whether the command succeeded and captures its output.

For example, Playwright does not have a dedicated Step plugin. An existing Playwright test project can be run through ExecuteBash, which is different from writing a custom Keyword against the Playwright driver.

Composite Keywords

Composite keywords are essential for creating modular and organized execution suites. They act as logical keywords and contain references to other keywords based on the same functionality as a plan. Some benefits of using composite keywords include:

• Alias for Keyword Groups: Composite keywords provide an alias for groups of keywords that are frequently executed together. This simplifies the execution process and improves code maintainability.
• Encapsulation of Specific Cases: Composite keywords allow wrapping a keyword with a specific set of inputs and output checks, isolating a specific case into its own keyword.

Composite keywords also have their own control, called Return, which enables outputting values similar to other keyword types.

Local functions

Step automation includes a set of default local functions that can be used as keywords out of the box. These local functions include:

• PDF_compare: A generic keyword for comparing PDF documents.
• EBC_Put, EBC_Peek, and EBC_Get**: Basic Keywords for putting and retrieving events from the Event Broker (available for enterprise users with a dedicated license).
• InsertMeasurement: A keyword is used for inserting arbitrary transaction measurements from a Plan instead of from the keyword’s code.

These local functions provide convenient and commonly used functionalities that can be utilized within automation Plans.

By leveraging keywords in Step automation, developers can enhance reusability, maintainability, and modularity in their automation projects.