Automated test software is the code that runs an automated test system. It has two main parts: a test executive that sequences the test steps, applies pass/fail limits and manages operators, product variants, results and reports; and code modules that control the instruments and talk to the unit under test. Tools such as NI TestStand, LabVIEW, Python and C# are commonly combined to build it.
This article expands the software section of our complete guide to automated test equipment (ATE). It covers the layers of test software, commercial vs custom test executives, language choices, instrument control, data and traceability, and how parallel testing raises throughput.
The layers of automated test software
The single most valuable design decision is keeping these layers separate. When limits live in data rather than code, quality engineers can review and change them under revision control. When instruments sit behind a hardware abstraction layer, an obsolete DMM can be replaced without touching the test sequence.
What a test executive does
- Runs test sequences step by step, with setup, cleanup and conditional branching.
- Applies numeric, string and pass/fail limits, and handles retries and failure actions.
- Manages product variants, so one sequence covers a product family with different limits.
- Controls user roles: operators run tests, technicians debug, engineers change sequences and limits.
- Reads serial numbers, writes results to a database, and generates reports and labels.
- Runs several units in parallel and coordinates shared instruments.
- Provides start-up self-test, calibration checks and fixture verification.
Commercial vs custom test executives
| Option | Strengths | Watch out for |
|---|---|---|
| NI TestStand | Mature, widely used; parallel execution, reporting and database logging built in; calls LabVIEW, C, C#, Python modules | License per station; needs TestStand skills to architect well |
| Other commercial test executives | Tight integration with one vendor’s instruments | Ecosystem dependence |
| Open-source Python test frameworks | No license cost; Python ecosystem; full control | You build operator UI, reporting and user management yourself |
| Custom-built sequencer | Exactly fits the product, operator workflow and data model; no runtime licenses | Needs disciplined design and documentation to stay maintainable |
For a single product with a stable sequence, a lean custom application can be simpler and cheaper to run. For a test department supporting many products and stations, a commercial executive pays off through shared infrastructure and skills.
Choosing a programming language for test code
| Language | Strengths for test | Typical use |
|---|---|---|
| LabVIEW | Graphical, fast instrument and DAQ integration, huge driver library, strong for real-time and FPGA | Instrument control, measurement-heavy test, NI hardware |
| Python | Readable, quick to write, rich libraries (PyVISA, NumPy, pandas), easy to integrate | Test scripts, analysis, automation frameworks |
| C# / .NET | Strong tooling, good for large maintainable applications and rich operator interfaces | Custom executives and enterprise integration |
| C / C++ | Performance, low-level hardware access, vendor SDKs | Drivers, real-time and high-speed processing |
Mixing languages is normal: a TestStand sequence calling LabVIEW code modules, with Python for data analysis, is a common and effective combination. Sciotex is an NI and LabVIEW integrator with Certified LabVIEW Developers and Architects on staff; see our LabVIEW development services.
Instrument control: VISA, SCPI and IVI
Most test instruments are controlled through a few standard layers:
- VISA (Virtual Instrument Software Architecture) is a common API for talking to instruments over GPIB, USB, Ethernet (LXI) or serial, so code does not change with the bus.
- SCPI (Standard Commands for Programmable Instruments) is the text command set most instruments understand. For example,
MEAS:VOLT:DC?asks a DMM for a DC voltage reading. - IVI drivers wrap instruments of the same class (DMMs, scopes, supplies) behind a common interface, which makes swapping models easier.
- Bus and protocol interfaces such as CAN, LIN, I2C, SPI, Modbus and Ethernet handle communication with the unit under test.
Instrument configuration is often where test time hides. Setting a DMM’s range and integration time once, rather than auto-ranging every reading, can cut seconds from each unit. Our article on measurements to automate covers the speed and accuracy trade-offs.
Parallel testing: getting more from one station
Many test steps spend most of their time waiting: for power-up, firmware boot, thermal soak or a communication response. Running several units at once overlaps that waiting time, while shared instruments are switched between units.
Worked example: four-up parallel test
A unit takes 30 s to test. Of that, 12 s uses a shared DMM and 18 s is independent (power-up, boot, communication).
Testing four units one after another takes 4 × 30 = 120 s.
Testing four in parallel takes about 18 s of overlapped independent work plus 4 × 12 s of DMM time in turn = 66 s, or 16.5 s per unit: about 1.8× the throughput, without a second station.
Adding a second DMM would cut the shared time further, so the model also shows which instrument is worth duplicating.
Data, traceability and validation
Test software should store every measurement with its limits, result, serial number, product variant, software and sequence version, station, fixture, operator and time. A relational database or MES connection makes that data useful: first-pass yield by station, failure Pareto charts, measurement trends and Cpk. Semiconductor test commonly uses the STDF format; aerospace and defense programs may use IEEE 1671 (ATML) for test descriptions and results.
In regulated industries, the software itself must be controlled and validated. Medical device makers apply FDA 21 CFR Part 820 and Part 11 to test software and electronic records, and many follow a GAMP 5-style risk-based validation approach. Keep sequences, limits and code under version control, and record which version tested every unit.
Common mistakes in test software
- Hard-coding limits and instrument addresses in the code, so every change is a software release.
- One monolithic program, so a new product variant means copying and editing the whole test.
- Logging only pass or fail, which throws away the data needed to improve yield.
- No simulation mode, so software cannot be developed or debugged without the full station.
- No start-up self-test, so a failed instrument or worn fixture shows up as failed units.
Need test software that production can live with?
Sciotex develops custom ATE systems and test software in LabVIEW, TestStand, Python and C#, with traceable data and MES integration, built and supported in the US since 1997.
Frequently asked questions
Automated test software runs an automated test system. It includes a test executive that sequences steps and manages limits, results and operators, and code modules that control instruments and communicate with the unit under test.
A test executive, or test sequencer, is software that runs test sequences, applies pass/fail limits, handles retries and product variants, manages user access and records results and reports. NI TestStand is a widely used example.
NI TestStand is a commercial test executive used to build and run automated test sequences in production and validation. It calls code modules written in LabVIEW, C, C#, Python and other languages, and provides parallel testing, reporting and database logging.
Yes. Python is widely used for test scripts, instrument control through PyVISA, data analysis and open-source test frameworks. For production stations it needs the same attention to operator interfaces, user management and data logging as any other language.
SCPI (Standard Commands for Programmable Instruments) is a standard text command set for controlling test instruments, such as MEAS:VOLT:DC? to read a DC voltage. Commands are usually sent through VISA over GPIB, USB, Ethernet or serial.
Related articles
- What Is Automated Test Equipment (ATE)? The Complete Guide
- End-of-Line Testing: How EOL Test Systems Work and How to Specify One
- Hardware-in-the-Loop (HIL) Testing: How It Works and When to Use It
- 7 Measurements to Automate with an ATE System (and How to Get Them Right)
- In-Circuit Test vs Functional Test: ICT, Flying Probe, Boundary Scan and FCT Compared
- Test Fixtures for Automated Testing: Bed of Nails, Pogo Pin and Functional Fixtures
