---
title: Keysight PathWave Test Automation Alternatives
description: "Keysight PathWave Test Automation alternatives for mixed benches: plain OpenTAP, OpenHTF, pytest with PyVISA, TestStand, Galois, and when to stay on PathWave."
url: https://galoislabs.ai/blog/pathwave-test-automation-alternatives
author: Alex Hernandez
author_url: https://galoislabs.ai/blog/authors/alex-hernandez
published: "2026-09-19"
topic: Comparisons
publisher: Galois Labs
---

# Keysight PathWave Test Automation alternatives for multi-vendor benches

![A PXI-style modular chassis drawn as a dithered plate, one module pulled halfway out of its slot.](https://galoislabs.ai/blog/figures/ni-1.light.webp)

*FIG. 1 — MODULAR CHASSIS, ONE SLOT OPEN*

The main alternatives to Keysight PathWave Test Automation are plain OpenTAP, the open-source engine PathWave is built on; OpenHTF and pytest with PyVISA for Python teams; NI TestStand; and agent-driven platforms such as Galois. Pick by how much of your bench is Keysight, which language your team writes, and what every run has to record.

PathWave Test Automation is OpenTAP plus Keysight's tools, so first decide which layer you want to leave: the Keysight tools, the .NET plugin model, or the sequencer. On a Keysight-heavy bench the answer is often none; the last section says when.

> **Disclosure**
>
> We build Galois, one of the options compared here. Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record. Claims about other tools link to their own documentation.

## What is Keysight PathWave Test Automation?

Keysight describes PathWave Test Automation as software that "leverages OpenTAP open source test automation sequencing engine," with a "scalable, modular plug-in architecture," graphical tools for test plan development, and application development tools for OpenTAP developers ([Keysight, PathWave Test Automation](https://www.keysight.com/us/en/products/software/pathwave-test-software/pathwave-test-automation-software.html)). The KS8400B product page is more direct: "Built on the OpenTAP, an open-source test sequencer" ([Keysight, KS8400B](https://www.keysight.com/us/en/product/KS8400B/pathwave-test-automation.html)). The OpenTAP project's own FAQ calls it "the Keysight commercial version of OpenTAP" ([OpenTAP FAQ](https://github.com/opentap/opentap/blob/main/doc/FAQ/Readme.md)).

Keysight sells it as three products:

| Product                                                                                                                     | Keysight's description                                                                           | Notable pieces                                                                                                      |
| --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| [KS8400B Developer's System](https://www.keysight.com/us/en/product/KS8400B/pathwave-test-automation.html)                  | "Powerful test plan creation and execution"                                                      | Graphical test plan editor, Run Explorer, Results Viewer, Timing Analyzer, Python and .NET SDKs, package management |
| [KS8000B Deployment System](https://www.keysight.com/us/en/product/KS8000B/pathwave-test-automation-deployment-system.html) | "Subset of KS8400B PathWave Test Automation Developers System"                                   | A lower-cost, scaled-down version of KS8400B for running tests                                                      |
| [KS8500B Cloud](https://www.keysight.com/us/en/product/KS8500B/pathwave-test-automation-cloud.html)                         | "A suite of test automation tools that let you create, collaborate, deploy and monitor at scale" | Remote runners, web UI, role-based access to instruments, plans, and results                                        |

Its native C#, Python, and RESTful APIs let it run standalone or under a higher-level test executive ([KS8400B technical overview](https://www.keysight.com/us/en/assets/7018-05485/technical-overviews/5992-1909.pdf)).

**What does it cost?** Keysight's product pages publish no price; the KS8400B page routes buyers to a quote. Since version 9.29.2, the Developer's System can also run under a Community License, "fully featured and at no-cost (but without support or warranty from Keysight)." Activating it requires an OpenTAP Community account, an active internet connection, and opting in to telemetry, which Keysight says covers basic system details, community account information, plugins used, test execution statistics, and the configured DUTs and instruments ([Keysight download page](https://www.keysight.com/us/en/lib/software-detail/computer-software/pathwave-test-automation-2796935.html)). The same release moved from .NET Framework to .NET 9 and brought the Editor, Package Manager, Results Viewer, and Timing Analyzer to Linux, with experimental macOS support.

So license cost alone is a weak reason to leave. Better reasons: most of the bench is not Keysight, the team wants tests as plain Python, or the run record has to answer different questions.

## Is PathWave Test Automation the same as OpenTAP?

The engine is the same; the tools around it differ. OpenTAP is "an Open Source project for fast and easy development and execution of automated tests," based on "an extendable architecture that leverages .NET" ([opentap/opentap](https://github.com/opentap/opentap)). The repository holds the sequencer, the package manager, the `tap` CLI, and a set of basic test steps, under MPL-2.0, with a "© Keysight Technologies 2012-2026" notice in the license file. The engine's latest version is [9.35](https://opentap.io/downloads), published on September 15, 2026, while Keysight's download page lists 9.34 as the current Developer's System.

In OpenTAP's model, "a test plan is a sequence of test steps and their associated data," stored as XML with the `.TapPlan` extension. Instruments and DUTs are resources, and "result listeners are notified whenever a test step generates log output, or publishes results," which is where databases and reports attach ([OpenTAP user guide](https://doc.opentap.io/User%20Guide/Introduction/Readme.html)). A parent step decides whether its children run in sequence or in parallel. Plans run in an editor or headless with `tap run`.

What the open-source repository leaves to Keysight is the graphical editor. OpenTAP's docs list two editors: the Developer System, a "mature, feature-rich GUI available with a commercial or community license," and TUI, an "open source cross-platform text-based user interface for usage in terminals" ([OpenTAP editors](https://github.com/opentap/opentap/blob/main/doc/User%20Guide/Editors/Readme.md)).

Two governance facts matter for a long-term dependency. OpenTAP "is developed and maintained by a group of developers at Keysight and other organizations," and engine contributors assign copyright to Keysight under a contributor license agreement. Plugin authors set their own license terms ([OpenTAP FAQ](https://github.com/opentap/opentap/blob/main/doc/FAQ/Readme.md)).

## PathWave Test Automation alternatives compared

| Option                   | License                                         | Test logic written in                          | Plan format                   | Non-Keysight instruments                                  | Best for                                                  |
| ------------------------ | ----------------------------------------------- | ---------------------------------------------- | ----------------------------- | --------------------------------------------------------- | --------------------------------------------------------- |
| PathWave Test Automation | Commercial, by quote; no-cost Community License | C# or Python plugins                           | `.TapPlan` XML                | SCPI plugin, ecosystem plugins, or your own               | Keysight-heavy benches that want vendor tools and support |
| OpenTAP                  | MPL-2.0                                         | C#; Python through a plugin                    | `.TapPlan` XML                | Same as PathWave                                          | Teams keeping their plans and plugins, headless or in CI  |
| OpenHTF                  | Apache-2.0                                      | Python                                         | Python test scripts           | Plugs you write                                           | Python teams that want code-first tests                   |
| pytest + PyVISA          | MIT (both)                                      | Python                                         | Python test files             | Any VISA instrument; drivers you write                    | Small teams and CI-style bench tests                      |
| NI TestStand             | Commercial, per developer and per station       | LabVIEW, C/C++, .NET, Python code modules      | `.seq` sequence files         | Code modules calling your drivers                         | Windows lines standardized on NI                          |
| Galois                   | Apache-2.0 daemon; commercial platform          | Agent-drafted sequences; Python SDK and PyVISA | Versioned, approved sequences | 573 profiles across 135 manufacturers; raw SCPI otherwise | Mixed-vendor benches where an agent writes and runs tests |

## Plain OpenTAP: the same engine without Keysight's tools

If PathWave already runs your bench, plain OpenTAP is the alternative with the lowest switching cost, because nothing has to be translated. A `.TapPlan` built in the PathWave editor is an OpenTAP test plan, and it runs under `tap run` on any installation that has the packages it references. OpenTAP "has been ported to and installs on both Windows and Linux hosts, as well as into Docker containers" ([OpenTAP FAQ](https://github.com/opentap/opentap/blob/main/doc/FAQ/Readme.md)).

The multi-vendor story is the same as PathWave's. OpenTAP includes "support for hundreds of test instruments from Keysight," and its FAQ lists three routes for everything else: the SCPI plugin and the `IScpiInstrument` API, plugins from the OpenTAP ecosystem, or a plugin you write. With the Python plugin installed (`tap package install Python`; the [OpenTap.Python](https://github.com/opentap/OpenTap.Python) repository is Apache-2.0), a generic SCPI multimeter and a limit-checked step follow the patterns in the plugin's own examples:

```python title="bench_steps.py"
from opentap import *
from System import Double
import OpenTap


@attribute(OpenTap.Display("Bench DMM", "Any SCPI multimeter.", "Bench"))
class BenchDmm(OpenTap.ScpiInstrument):  # VISA address lives in bench settings
    def __init__(self):
        super().__init__()

    def measure_vdc(self):
        return self.ScpiQuery[Double]("MEAS:VOLT:DC?")


@attribute(OpenTap.Display("Measure VOUT", "Check a rail against limits.", "Bench"))
class MeasureVout(TestStep):
    Dmm = property(BenchDmm, None).add_attribute(OpenTap.Display("DMM", "", "Resources"))
    Low = property(Double, 4.9).add_attribute(OpenTap.Unit("V"))
    High = property(Double, 5.1).add_attribute(OpenTap.Unit("V"))

    def __init__(self):
        super().__init__()

    def Run(self):
        vout = self.Dmm.measure_vdc()
        self.PublishResult("VOUT", ["Voltage", "Low", "High"], [vout, self.Low, self.High])
        passed = self.Low <= vout <= self.High
        self.UpgradeVerdict(OpenTap.Verdict.Pass if passed else OpenTap.Verdict.Fail)
```

`PublishResult` hands the row to every configured result listener, and `UpgradeVerdict` sets the step's verdict. The same step appears in the PathWave editor and in a headless run:

```sh title="run.sh"
tap package list --installed      # packages installed on this station
tap run --settings Bench2 --non-interactive Vout.TapPlan
```

`--settings` selects a bench settings profile (instruments, DUTs, and connections under `Settings/Bench/Bench2`), so one plan runs on several benches, and `--non-interactive` never prompts, which suits CI ([OpenTAP CLI usage](https://github.com/opentap/opentap/blob/main/doc/User%20Guide/CLI%20Usage/Readme.md)).

**What you give up.** The graphical editor, Run Explorer, Results Viewer, and Timing Analyzer are Keysight's; on plain OpenTAP you edit plans in TUI or as XML. Support moves to best-effort help on the issue tracker and forum. Check the license of every package a plan uses before moving it.

## OpenHTF: Python tests without a .NET engine

OpenHTF is Apache-2.0 and written in Python ([google/openhtf](https://github.com/google/openhtf)). A test is a Python program built from phases. Measurements carry their limits, and any out-of-spec measurement fails the run. Plugs wrap the DUT and the instruments, and output callbacks write the record. [OpenHTF vs OpenTAP vs pytest vs TestStand](https://galoislabs.ai/blog/test-executive-comparison) has a complete OpenHTF test with PyVISA plugs.

Against PathWave, the trade is a sequencer for a library: no plan file, editor, or package manager, and the test is code that diffs and reviews like any other Python. Instrument plugs and database logging are yours to write, and the test executive comparison covers OpenHTF's bundled plugs, callbacks and release status.

## pytest and PyVISA: a harness you own

Both are MIT-licensed. PyVISA controls "test equipment via GPIB, RS232, Ethernet or USB" through an installed VISA library such as NI-VISA or Keysight VISA, or the pure-Python PyVISA-py backend ([pyvisa/pyvisa](https://github.com/pyvisa/pyvisa)). pytest supplies fixtures for instrument sessions, parametrization for sweeps, and `--junit-xml` output that CI servers read ([pytest docs](https://docs.pytest.org/en/stable/how-to/output.html)). The [SCPI automation guide](https://galoislabs.ai/blog/scpi-automation-python) builds the session, error-queue, and driver layers this harness needs.

The trade is the reverse of PathWave's. You get plain Python that runs wherever your firmware CI runs, in the language hiring managers ask for: 54.8% of 1,021 hardware-test job postings in our [hiring study](https://galoislabs.ai/blog/hardware-test-hiring-study) named Python. You give up what a sequencer provides: a plan editor, a results viewer, timing analysis, and a deployment model. Units, limits, serial numbers, and instrument identity are fields you add yourself.

## NI TestStand: a different commercial sequencer

Swapping one commercial sequencer for another makes sense mainly when the line already runs on NI. TestStand calls code modules written in LabVIEW, C/C++, .NET, and Python, and writes HTML, XML, ATML, and text reports ([NI, What is TestStand](https://www.ni.com/en/shop/electronic-test-instrumentation/application-software-for-electronic-test-and-instrumentation-category/what-is-teststand.html)). It ships Sequential, Parallel, and Batch process models for testing one or many units at once ([NI docs](https://www.ni.com/docs/en-US/bundle/teststand/page/teststand-process-models.html)). NI's download page lists Windows as its supported operating system ([NI download](https://www.ni.com/en/support/downloads/software-products/download.teststand.html)). NI's agent, Nigel, generates sequences from a specification document in the TestStand 2026 Q3 release ([NI, Nigel](https://www.ni.com/en/shop/software-portfolio/nigel.html)).

Unlike PathWave, TestStand's prices are published; [TestStand alternatives](https://galoislabs.ai/blog/teststand-alternatives#how-much-does-teststand-cost-and-does-it-run-on-linux) lists them.

The [TestStand comparison](https://galoislabs.ai/compare/teststand) covers it in depth.

## Galois: agent-driven tests across vendors

Apart from Nigel's sequence generation in TestStand, the options above expect engineers to write the tests and, for instruments outside a plugin set, the drivers. Galois hands both jobs to Évariste, the agent in the Galois platform, and keeps the engineer as reviewer.

On the bench, the Apache-2.0 galois-edge daemon discovers instruments on GPIB, USB, LAN, serial, Modbus, and CAN, matches each one against the profiles it has loaded, and still accepts raw SCPI for anything without a profile. Galois ships 573 instrument profiles across 135 manufacturers in its [instrument library](https://galoislabs.ai/instruments); for an instrument the library lacks, Évariste turns its programming manual into a profile. Frozen daemon builds are available for Linux (x86_64 and arm64) and Windows, and existing PyVISA scripts move with one line, `ResourceManager("@galois")`.

For agents, the daemon exposes each connected instrument as typed MCP tools, such as `keysight_34461a__measure_voltage_dc` or `siemens_s71200__read_holding_register`, and updates the tool list when an instrument is plugged in ([agents docs](https://docs.galoislabs.ai/agents/)). Sweeps and streams run on the daemon, so a dropped agent session does not strand hardware mid-ramp. The [MCP for lab instruments post](https://galoislabs.ai/blog/mcp-lab-instruments) covers the protocol.

Évariste drafts sequences; engineers approve them. Sequences use typed steps with limit checks, version history, diffs, and production locking. A draft cannot run until it is approved, and an edited sequence must be approved again. Each run records, step by step, the measured value, limits, raw command and response, and instrument ID, along with the operator, DUT serial, and timestamp, and reports are drafted from that record ([product](https://galoislabs.ai/product)). The platform runs as Galois Cloud, a dedicated single-tenant cloud, or fully on-prem and air-gapped, with Évariste routed to the LLM endpoint you choose in every case ([deployment](https://galoislabs.ai/deployment)).

**The OpenTAP VOUT check, with Évariste.** Open Évariste from the app sidebar beside a project and ask it to "List connected instruments" to confirm the DMM is on an edge. If the DMM has no profile, upload its programming manual as a PDF; Évariste generates a profile, which you review before it is deployed to the edge and bound to the instrument. Then state the objective with the limits from the datasheet: measure VOUT on the DMM, pass from 4.9 to 5.1 V. Évariste drafts a sequence with that limit check, and it runs on the bench through galois-edge only after you approve it. The run records the measured value, limits, pass/fail, and the raw command and response, and "Generate a test report from the last run" turns that record into a report. You write no instrument class, step class, or result listener; the limits, the review and approval, the wiring, and bench safety stay yours.

**Migration cost.** Moving from PathWave means rebuilding test plans as Galois sequences and C# instrument plugins as profiles. Évariste drafts each sequence from the objective and limits you carry over from the plan, and each profile from the instrument's programming manual; an engineer reviews every draft. Galois is also a younger product than OpenTAP, without its years of field use.

## How to migrate off PathWave Test Automation

1. **Inventory the packages.** Run `tap package list --installed` on every station and sort the result into open-source packages, Keysight packages, and your own plugins.
2. **Decide whether to keep the engine.** If most of the list is open source or your own, plain OpenTAP keeps those plans and plugins; check the license terms of each Keysight package. Leaving the engine is a rewrite, so have a concrete reason.
3. **Map instruments to the new layer.** For each instrument, note the plugin that drives it and the SCPI it sends. Those commands become OpenHTF plugs, PyVISA driver classes, or Galois profiles.
4. **Map result listeners to the new record.** Each listener in your bench settings feeds something downstream: a database, a CSV for a yield dashboard, a customer report. The new system has to produce the same fields.
5. **Replace the tools engineers use.** If the team lives in Results Viewer and Timing Analyzer, pick replacements before cutover.
6. **Run old and new on the same units.** Put a known-good and a known-bad unit through both, compare measurement by measurement, then retire stations one at a time.

## When to stay on PathWave Test Automation

Stay when the bench is Keysight-heavy and the system works:

- **Most instruments are Keysight, and their plugins do the job.** OpenTAP already supports hundreds of Keysight instruments. Rebuilding on a vendor-neutral layer buys little if a non-Keysight instrument arrives once a year.
- **You want vendor support on the sequencer.** The open-source project offers best-effort community help; commercial support comes with PathWave ([OpenTAP FAQ](https://github.com/opentap/opentap/blob/main/doc/FAQ/Readme.md)).
- **You run a fleet through KS8500B.** Remote runners, role-based security, and an architecture Keysight says supports "thousands of test stations" are already in place ([Keysight, KS8500B](https://www.keysight.com/us/en/product/KS8500B/pathwave-test-automation-cloud.html)).
- **Your team writes C# and owns its plugins.** They carry over to plain OpenTAP unchanged; every other option on this list means porting them.
- **Test time is the number you manage.** Keysight's [technical overview](https://www.keysight.com/us/en/assets/7018-05485/technical-overviews/5992-1909.pdf) positions Timing Analyzer as the tool for optimizing test plan execution and analysis.
- **Cost is the only complaint.** The Community License is no-cost if a connected bench, opted-in telemetry, and no Keysight support or warranty are acceptable.
- **You want an agent, and your instruments are on Keysight's list.** Keysight's MCP Server for Instrument Control, labeled beta, connects a third-party AI client such as Claude Code or GitHub Copilot to supported Keysight instruments under a no-cost perpetual floating license ([Keysight software page](https://www.keysight.com/us/en/lib/software-detail/computer-software/keysight-mcp-server-for-instrument-control.html)). The engineer approves each command sequence before it runs ([overview](https://helpfiles.keysight.com/kmsic/English/keysight_mcp_for_instrument_control/Content/overview.html)). It runs on Windows 10 or 11, and session state is held in memory and cleared on restart ([release notes](https://helpfiles.keysight.com/kmsic/English/keysight_mcp_for_instrument_control/Content/release-notes.html)).

If none of those hold, start from your team's language and your bench's vendor mix: plain OpenTAP to keep your plans, OpenHTF or pytest for Python, Galois when you want Évariste to write and run tests on a mixed bench. The [Keysight comparison](https://galoislabs.ai/compare/keysight) goes line by line, and [test sequencer vs test agent](https://galoislabs.ai/blog/test-sequencer-vs-test-agent) covers what changes when an agent writes the plan.

## Frequently asked questions

### Is PathWave Test Automation built on OpenTAP?

Yes. Keysight says PathWave Test Automation leverages the OpenTAP open-source sequencing engine, and its KS8400B page describes the product as built on OpenTAP. The OpenTAP project's FAQ calls it the Keysight commercial version of OpenTAP. Test plans are the same .TapPlan XML files, and plugins are OpenTAP plugins written in C# or Python.

### Is there a no-cost version of PathWave Test Automation?

Since version 9.29.2, the KS8400B Developer's System can run under a Community License that Keysight describes as fully featured and at no cost, without support or warranty from Keysight. It requires an OpenTAP Community account, an internet connection, and opting in to telemetry. Commercial licenses are sold by quote, and the OpenTAP engine underneath is open source under MPL-2.0.

### Does PathWave Test Automation run on Linux?

Yes. Keysight's download page says KS8400B now runs on Linux, with experimental macOS support, for the Editor, Package Manager, Results Viewer, and Timing Analyzer. The OpenTAP engine installs on Windows and Linux hosts and in Docker containers.

### Can PathWave Test Automation control non-Keysight instruments?

Yes, through OpenTAP. The OpenTAP FAQ lists three routes for non-Keysight instruments: the SCPI plugin and IScpiInstrument API for SCPI instruments, plugins from the OpenTAP ecosystem, or a plugin you write yourself. Check the OpenTAP package repository for an existing plugin before planning to write one.

### What is the best open-source alternative to PathWave Test Automation?

Plain OpenTAP, if you want to keep your test plans and plugins: it is the MPL-2.0 engine PathWave is built on, and it runs plans headless with tap run or edits them in the open-source TUI. If your team prefers Python tests to a .NET sequencer, OpenHTF (Apache-2.0) or pytest with PyVISA (both MIT) are the usual choices.
