Sequential vs Parallel vs Batch Testing

Three execution strategies cover almost every production test station: test one unit at a time, test several independently, or test several as a group. The choice is set by your fixture, not by preference, and picking wrong either wastes hardware or produces results you cannot trust.

This guide defines each strategy, gives the decision rule, and shows how to configure them. For the underlying abstraction these strategies belong to, see What Is a Test Process Model.

The Three Strategies

The difference between parallel and batch is coupling, not count. Both test multiple units at once. In parallel, a unit that finishes early is unloaded and replaced immediately. In batch, it waits for its neighbours.

Sequential

One unit is loaded, tested start to finish, and unloaded. The next unit begins after.

Unit 1  [====== 30s ======]Unit 2                     [====== 30s ======]Unit 3                                        [====== 30s ======]

Sequential is the right answer when the fixture holds one unit, when the test needs an instrument that physically cannot be shared, or when an operator must handle each unit anyway. It is also the correct starting point for a new procedure: get one unit passing reliably before adding concurrency.

Its cost is throughput. Test time is dominated by waiting, and with one unit in flight, nothing overlaps with that wait.

Parallel

Several units are tested at the same time, each on its own schedule. Unit 2 failing at 5 seconds does not disturb unit 1, and its position is free for a replacement while the others are still running.

Slot 1  [====== 30s ======][====== 30s ======]Slot 2  [== 5s ==][====== 30s ======]Slot 3  [====== 30s ======][====== 30s ======]

Parallel is the highest-throughput option and the default choice for a multi-position fixture. On a four-position fixture with a 30-second test, throughput moves from roughly 120 units per hour to close to 450, bounded by whatever the slots genuinely share.

Two conditions must hold. Each position needs its own instruments, or a shared instrument fast enough that queuing does not dominate. And the test must not care about its neighbours: no shared thermal chamber ramp, no measurement that assumes all units are in the same state.

Batch

Several units are loaded together, tested together, and unloaded together. The group moves as a unit.

Unit 1  [====== 30s ======]        idleUnit 2  [== 5s ==]  idle           (waits for the group)Unit 3  [========== 45s ==========]        └──────── batch ends at 45s ────────┘

Batch exists because some tests are physically shared. A thermal chamber ramps every unit inside it at once. An EMC pre-compliance sweep illuminates the whole tray. A burn-in rack powers a shelf together. In these cases the shared operation is the test, and the units cannot be decoupled.

Batch is also correct for traceability reasons: when units must be proven to have been tested under identical conditions, testing them together is the evidence.

The cost is visible in the diagram. Every unit pays the slowest unit's time, and the fixture cannot be reloaded until the group finishes.

Choosing

Work down this list and stop at the first match:

1. Does one physical operation cover every unit at once (chamber ramp, shared RF field, common power rail)? Use batch. The units are coupled whether you model them that way or not.
2. Must the units be proven tested under identical conditions? Use batch.
3. Does the fixture hold more than one unit, each with its own connections? Use parallel.
4. Otherwise, use sequential.

A common mistake is reaching for batch because units are loaded as a tray. Loading is not testing. If the tray holds eight units and each has its own probe connection, that is parallel with a tray-shaped fixture, and modelling it as batch throws away throughput for nothing.

Configuring Parallel Execution

In the TofuPilot Framework, each independently tested position is a slot, the test socket that owns one unit. Declaring slots turns a single-unit procedure into a parallel one:

execution:  slots:    - name: USB0    - name: USB1    - name: USB2    - name: USB3

For a fixture with many identical positions, give a count instead and let the keys be generated:

execution:  slots: 80

Each slot identifies its own unit and uploads its own run. Use {slot} in the unit defaults to derive serials per position:

unit:  auto_identify: true  serial_number:    default_value: "BURNIN-{slot}"  part_number:    default_value: "PCB-MAIN-V2"

Slots fail independently. A failing phase stops that slot, runs its teardown, and leaves the others running. Only a failure in a shared setup or teardown phase, or a plug that cannot initialize, stops everything.

Approximating Batch with Shared Phases

The Framework models batch behavior through phase scope rather than a separate model. Phases scoped to the execution run once for all slots; phases scoped to a slot run per unit.

execution:  slots: 8setup:  - name: Ramp Chamber to 85C    python: phases.ramp_chamber    scope: executionmain:  - name: Measure Leakage    python: phases.measure_leakageteardown:  - name: Return Chamber to Ambient    python: phases.cool_chamber    scope: execution

The chamber ramp happens once, every unit measures its own leakage, and the chamber returns to ambient after every slot is done. That is batch semantics for the shared operations and parallel semantics for the per-unit measurements, which is usually what a batch fixture actually needs.

This matters for correctness, not just tidiness. A slot-scoped teardown can run while neighbouring slots are still testing, so anything touching a shared resource — a rack supply, a chamber, a fixture lock — must be scoped to the execution. Cooling the chamber in a slot-scoped teardown would sabotage every unit still under test.

Phase-First and Slot-First

With slots configured, one more setting controls interleaving:

execution:  strategy: phase_first  slots: 4

phase_first, the default, runs the same phase across all slots before advancing. slot_first finishes one slot completely before starting the next.

phase_first suits a shared instrument: all four voltage measurements happen together, so the instrument is configured once for that measurement. slot_first is closer to sequential, useful when you want a complete result for the first unit as early as possible.

Throughput Comparison

Four units, 30-second test, 5-second load and unload:

Parallel and batch look identical here because every unit takes exactly 30 seconds. They diverge with real variation: batch pays the slowest unit every cycle, and pays it again on every retry.

Common Pitfalls

Sharing an instrument without accounting for queuing. Four slots reading one DMM do not measure in parallel; the calls queue. If a shared instrument call takes 2 seconds, four slots spend 8 seconds on that phase, and your parallel speedup silently disappears. See Share Instruments Across Parallel Slots for the arithmetic and the fix.

Slot-scoped teardown on shared hardware. Powering down a rack supply in a slot teardown kills units still under test. Shared resources belong in execution-scoped teardown.

Batch used for loading convenience. If units are independent, batch only adds waiting.

Assuming parallel needs no code change. Per-slot instrument addressing, serial number derivation, and fixture presence detection all have to be genuinely per-slot. Code that hardcodes one instrument address will happily run four slots against the same physical unit.

Key Points

• Sequential, parallel, and batch differ in how many units are in flight and whether they are coupled.
• Coupling is decided by physics: a shared chamber or field means batch, independent connections mean parallel.
• Parallel gives the highest throughput; batch makes every unit pay the slowest unit's time.
• In the TofuPilot Framework, parallel is execution.slots, and batch semantics come from execution-scoped phases.
• Shared resources must be scoped to the execution, or a finishing slot will disturb the ones still running.