GlossaryTest Executor

Test Executor

A test executor is the runtime component that runs a specific type of test, such as a Postman collection, k6 script, or Cypress suite, and returns its results.

Table of Contents

Table of Contents

How a test executor works

  1. A test definition names the framework and the test files.
  2. The orchestrator picks the matching executor.
  3. The executor starts the tool, often in a container.
  4. The tool runs the tests and writes results and artifacts.
  5. The executor reports status, logs, and artifacts back.

Examples of test executors

  • API: Postman or Newman for collections
  • Load: k6, JMeter, or Artillery for performance tests
  • Browser: Cypress, Playwright, or Selenium for UI tests
  • Custom: scripts or in-house tools packaged as containers

Framework-specific executors vs. container-based workflows

Testing platforms have moved from one executor per framework to running any container.

Framework-specific executor Container-based workflow
Supported tools One tool per executor Any tool with a container image
New tools Build a new executor Point to an image
Customization Limited to executor options Full control of steps
Maintenance Per-executor updates Use upstream images

Why test executors matter

Modern teams run API, UI, performance, and end-to-end tests with different tools. Executors give all of them a common way to run.

  • Standard execution: one model across many frameworks
  • Reuse: existing tests run without rewrites
  • Scale: Kubernetes pods run many tests at once
  • Isolation: each test runs separately for cleaner results

Separating test definitions from execution logic makes orchestration flexible and scalable. Consider a SaaS team adding k6 next to existing Postman tests. With a shared execution model, both report results the same way.

Common challenges with executors

  • Version drift: executor tool versions fall behind the frameworks
  • Custom tools: unsupported tools need extra work
  • Configuration sprawl: each executor has its own settings
  • Debugging: failures can come from the tool or the executor

How test executors relate to Testkube

Testkube introduced executors to run different testing frameworks in Kubernetes. Today, Testkube test workflows run any tool directly from its container image, which removes the need for framework-specific executors.

  • Any framework: Postman, k6, Cypress, Playwright, or custom scripts
  • Pod isolation: each run uses separate pods for clean environments
  • Custom tools: bring your own container image for niche or in-house tools
  • Reusable definitions: the same test runs across workflows and clusters
  • Integrations: CI/CD, APIs, and workflows trigger runs automatically

Frequently Asked Questions (FAQs)

What is a test executor?

It is the runtime component that runs a specific type of test and reports results.

Does Testkube still use executors?

Testkube test workflows now run any tool from its container image, which replaces framework-specific executors.

Can I run a custom testing tool?

Yes. Package it as a container image and run it in a Testkube workflow.

Why do executors run in separate pods?

Separate pods keep each run isolated, so tests do not interfere with each other.

Which tools can Testkube run?

Postman, k6, JMeter, Cypress, Playwright, Selenium, and any tool that runs in a container.

What is the difference between an executor and a test runner?

The terms overlap. Both describe the component that actually runs tests and returns results.

Related Terms and Concepts

No items found.