Keysight PathWave Alternatives in 2026 (Free & Open Source Options)

Keysight PathWave Test Automation is a commercial test sequencing platform built on OpenTAP, the open-source automation engine Keysight released and now maintains as an OSI-licensed project. PathWave adds a supported editor, commercial plugins, results management, and a support contract on top of an engine that is free.

That relationship is the single most useful thing to understand before evaluating alternatives, because the strongest alternative to PathWave is the free software inside it. This post covers what the commercial layer buys, when it is worth paying for, and the four other options.

What you are actually paying for

OpenTAP gives you the test plan engine, step execution, result listeners, the plugin architecture, and a CLI. Free, open source, production-grade.

PathWave adds:

• •A supported, polished editor. The OpenTAP community editor exists, but the PathWave editor is more complete and is the thing most engineers interact with all day.
• •Commercial instrument plugins, particularly for Keysight's own hardware, maintained and versioned.
• •Results and database integration beyond the basic listeners.
• •A support contract. Someone to call. In regulated or high-volume production this is not a small thing.
• •Certified compatibility with Keysight's wider PathWave portfolio.

The honest summary: you are buying the editor, the plugins, and the phone number. Whether that is worth it depends almost entirely on whether your bench is Keysight and whether you have plugin-writing capacity in-house.

When PathWave is the right call

• •Your bench is predominantly Keysight, so the commercial plugins cover it out of the box
• •You are in regulated production and need a support contract and traceable versioning
• •You have no C# capacity to write and maintain plugins
• •You are already inside the PathWave ecosystem for design or measurement software

When it is not

• •Mixed-vendor bench where you will write plugins regardless
• •Python-first team, since OpenTAP plugin development is C#-centric
• •Small lab where the support contract is a cost without a use
• •The workload is bench characterisation rather than production sequencing

The alternatives

1. OpenTAP alone

Free, and the same engine. Install it, use the community editor or drive it from the CLI, write plugins in C#.

tap run MyTestPlan.TapPlan --settings Production

Good for: anyone willing to trade the polished editor for zero licence cost. The engine is identical, so nothing about your test plans is lower quality.

Gives up: the commercial plugins and support. You write and maintain your own instrument plugins, which for a standard SCPI instrument is a few hundred lines of C#.

Verdict: the obvious place to start. Prototype here before paying for anything.

2. TestFlow

Changes the assumption rather than the tool. Instead of authoring steps, you describe the measurement in plain English, and an agent generates the sequence and the instrument automation, then runs it and produces the report.

Good for: bench characterisation and validation, mixed-vendor hardware, and teams whose bottleneck is the time to write the sequence rather than the time to run it.

Gives up: the production-floor operator model and the plugin ecosystem. It is not a drop-in replacement for a certified production sequencer.

Verdict: the right answer when writing the test is the slow part.

3. NI TestStand

The direct commercial competitor, and the incumbent in a great many production test departments.

Good for: NI-heavy benches, and teams who already have TestStand expertise. Its step types, execution model, and operator interfaces are mature.

Gives up: cost parity, and it pulls you into the NI stack including deployment licences per station.

Verdict: a lateral move unless your hardware pushes you one way. See NI TestStand alternatives for the full comparison.

4. pytest with pyVISA

Free, and a genuinely underrated option. pytest is a mature test runner with fixtures, parameterisation, reporting plugins, and CI integration, and none of it was designed for hardware but all of it works.

import pytest

@pytest.mark.parametrize("vin,expected", [(3.0, 1.8), (3.3, 1.8), (3.6, 1.8)])
def test_ldo_regulation(psu, dmm, vin, expected):
    psu.set_voltage(vin)
    psu.output(True)
    vout = float(dmm.query("READ?"))
    assert expected * 0.98 <= vout <= expected * 1.02, f"VOUT {vout} at VIN {vin}"

Good for: Python teams, CI integration, and anyone who wants test results in a format their software colleagues already understand.

Gives up: the operator interface and the configuration-driven model. pytest is code, and production operators do not run pytest.

Verdict: excellent for engineering validation, wrong for a production floor.

5. Robot Framework

Free, keyword-driven, with a readable tabular syntax that non-programmers can edit. Libraries exist for instrument control and it is widely used in telecom and hardware integration test.

Good for: teams that want the sequence readable by test engineers who are not developers, with reporting built in.

Gives up: performance on tight loops, and the instrument plugin ecosystem is thinner than OpenTAP's.

Verdict: a good middle ground between code and configuration.

Comparison table

How to decide in a week

1. 1

   Install OpenTAP and rebuild one existing sequence. Free, and it tells you whether the engine fits. If OpenTAP works, the only remaining question is whether the commercial layer is worth its price to you specifically.

2. 2

   Count your non-Keysight instruments. Each one is plugin work under PathWave or OpenTAP. If that number is large, the commercial plugin advantage mostly evaporates.

3. 3

   Ask who runs the tests. Engineers, or production operators? Operators need a supported UI. Engineers do not.

4. 4

   Ask what is actually slow. If running tests is slow, you need a better sequencer. If writing tests is slow, a better sequencer will not help.

That last question is the one that decides most of these evaluations and the one least often asked.

What writing an OpenTAP plugin actually involves

The decisive practical question when choosing between PathWave and free OpenTAP is how much plugin work your bench implies. It is less than people fear for a standard SCPI instrument.

[Display("Measure DC Voltage", Group: "DMM")]
public class MeasureDcVoltage : TestStep
{
    [Display("Instrument")]
    public ScpiInstrument Dmm { get; set; }

    [Display("Range (V)")]
    public double Range { get; set; } = 10;

    [Display("Lower limit (V)")]
    public double LowerLimit { get; set; }

    [Display("Upper limit (V)")]
    public double UpperLimit { get; set; }

    public override void Run()
    {
        Dmm.ScpiCommand($"CONF:VOLT:DC {Range}");
        double reading = Dmm.ScpiQuery<double>("READ?");
        Results.Publish("DcVoltage", new List<string> { "Volts" }, reading);
        UpgradeVerdict(reading >= LowerLimit && reading <= UpperLimit
            ? Verdict.Pass : Verdict.Fail);
    }
}

That is a complete, usable step type. A typical instrument needs three to six of these. Budget a day per instrument for a competent C# developer, plus testing.

So the arithmetic is: if you have four non-Keysight instruments, that is roughly a week of work once, against a recurring licence cost. If you have twenty, and they change often, the commercial plugins start to look reasonable.

The results question nobody asks early enough

Sequencers differ far more in what they do with results than in how they run steps. Decide this before choosing.

• •Where do results go? File, database, or a results service. OpenTAP result listeners are pluggable; PathWave adds managed options.
• •What is the schema? If you want to trend a parameter across ten thousand units, the result format decides whether that is a query or a scripting project.
• •Who reads them? Engineers with SQL access, or a quality team who need a document.
• •How long are they kept, and where? Regulated environments make this a requirement rather than a preference.

Teams that pick a sequencer on step authoring and discover the results model afterwards usually end up writing a custom listener, which erases the difference between the free and commercial options.

What PathWave costs to run for a year

PathWave is a family, not a product, and the bill depends on which parts you have. For one test-development seat plus a handful of stations:

Two things to check on your own quote. Whether station entitlements are counted per physical bench or per concurrent execution, because the two numbers can differ by a lot in a lab where stations idle most of the day. And whether the instrument apps you were sold are ones anyone still opens, which is the same tier-audit problem described in NI software licensing costs on the other vendor's stack.

The comparison that matters is not PathWave against zero. It is PathWave against OpenTAP plus the plugin work, since PathWave Test Automation is built on OpenTAP and the open core is genuinely the same engine.

The vendor-neutrality question

The reason to think carefully here, and it is not a pricing argument.

PathWave is excellent on Keysight hardware and progressively less convenient as the bench diversifies. That is not a criticism, it is what a vendor toolchain is for. The question is what your bench looks like in three years.

If you are in the third or fourth row, you are paying for a Keysight-optimised toolchain and then not using the part that makes it worth the price. See Keysight vs Tektronix oscilloscopes for how quickly a bench becomes mixed, and GPIB vs USB vs LAN for the transport layer that stays the same regardless.

Common mistakes

• •Buying PathWave to solve a sequencing problem you have not defined. Write down the actual sequence, the limits, and what the report has to contain first. Half the time the answer is much smaller than a platform.
• •Ignoring that PathWave Test Automation is OpenTAP. The engine is open source. What you are paying for is the instrument apps, the support, and the enterprise back end. Price those specifically.
• •Underestimating plugin work for third-party instruments. A generic SCPI plugin is a day. Ten instruments with different quirks is not ten days, it is closer to a month with the edge cases.
• •Deferring the results question. Where do results go, in what schema, and who queries them? This decides more about long-run value than the sequencer does. It is the same point made in automated test report generation.
• •Counting station entitlements wrong at renewal. Per-bench and per-concurrent-execution are different numbers. Ask which one you are on.
• •Comparing against "free" without counting build time. pytest with pyVISA is free and it is also several weeks of scaffolding before it does what a sequencer does out of the box.

Related reading

• •Test sequencer software compared, the full field
• •NI TestStand alternatives, the main commercial rival
• •Keysight BenchVue alternatives, the no-code Keysight tool
• •Keysight IO Libraries, the free driver layer underneath
• •Instrument control with VISA and SCPI
• •OpenTAP vs TestStand, the open engine underneath PathWave
• •Keysight Command Expert alternatives, the discovery tool
• •pyVISA tutorial, the free code route
• •NI software licensing costs, the same audit on the other vendor
• •Automated test report generation, the results question
• •Keysight vs Tektronix oscilloscopes, how benches become mixed
• •GPIB vs USB vs LAN, the transport layer underneath
• •Free instrument control software, the zero-cost options
• •Best test automation software, the wider field
• •SCPI command cheat sheet, the commands under every plugin