Test automation is often treated as something added after hardware and firmware are largely complete. At that point, the validation team receives a product designed for human use and must invent ways to control, observe, reset, identify, and recover it.

The result may involve fragile probing, camera-only observation, undocumented commands, repeated disassembly, or a fixture that depends on one engineer’s knowledge.

Testability is a product architecture concern. Small design decisions made early can reduce validation effort throughout development, manufacturing, service, and field diagnosis.

Begin with the behaviours that must be observed

For each important requirement, ask:

  • What stimulus causes the behaviour?
  • Which state must the product start in?
  • What observable evidence proves the result?
  • Which internal information would make a failure diagnosable?
  • How can the product return to a known state?

This does not mean exposing every internal variable. It means designing enough controlled visibility to prove important behaviour without guessing.

Map critical requirements to control and observation paths during architecture work. If the only way to prove a safety-relevant state is to infer it from an ambiguous indicator, that is an architecture risk.

Make power behaviour observable

Provide practical access to the rails and signals needed to understand startup, shutdown, reset, and low-power transitions.

Depending on the product, that may include:

  • accessible measurement points;
  • current-sense capability;
  • reset-state visibility;
  • power-good and fault signals;
  • separation or controlled isolation of power domains;
  • a documented power sequence;
  • non-invasive connection points for a fixture.

Test points should be electrically appropriate and physically accessible in the intended fixture. A point hidden under an enclosure feature may exist on the schematic while being unusable in validation or production.

Consider how debug and communication interfaces can back-power the product during power-cycle testing.

Provide a controlled diagnostic interface

A diagnostic API can offer:

  • product identity and hardware revision;
  • software and configuration versions;
  • current operating state;
  • health and fault information;
  • selected sensor and actuator values;
  • controlled test modes;
  • reset or recovery commands;
  • event counters and timestamps.

The interface should have defined permissions and lifecycle rules. Development-only capabilities should not accidentally remain unrestricted in production. Security and testability need to be designed together.

Use stable schemas and explicit versioning. Test systems live longer than one firmware sprint, and an undocumented response change can break a large validation estate.

Design deterministic state transitions

Automation depends on knowing when the product is ready and how to recover it.

Define observable states such as:

  • bootloader;
  • application starting;
  • operational;
  • degraded;
  • updating;
  • shutting down;
  • fault;
  • recovery.

Expose a reliable way to identify them. A fixed delay after power-on is a poor substitute for an explicit readiness state.

For each state, define accepted commands and transitions. Reject invalid operations clearly rather than ignoring them or returning a generic error.

Deterministic state does not only help testing. It improves service tooling, remote operations, and product support.

Preserve trace without drowning the system

Internal trace can reveal event order, timing, scheduling, and state transitions that external observation cannot.

Plan:

  • which events are important;
  • timestamp source and resolution;
  • event identifiers and payload limits;
  • buffering and overflow behaviour;
  • runtime cost;
  • trigger conditions;
  • extraction after a failure;
  • security and privacy restrictions.

Hardware and software trace architectures such as Arm CoreSight demonstrate why debug access, sources, links, sinks, timestamps, and triggers are system-level elements rather than ad hoc print statements.

Trace should complement external evidence. A product log claiming that an output changed is not the same as measuring the output, but the two together are powerful.

Give the fixture reliable mechanical references

Robotic and end-of-line testing benefit from:

  • repeatable datum surfaces;
  • locating features;
  • connector access;
  • robust contact areas;
  • tolerance information;
  • safe actuator approach paths;
  • replaceable wear interfaces.

Aesthetic enclosure changes can invalidate a fixture if these features are accidental. Make them part of the mechanical definition.

Where pogo pins, optical targets, microphones, or cameras are used, design for alignment and service replacement.

Separate test modes from test shortcuts

A controlled test mode can provide direct access to a subsystem, inject a known input, or speed a long transition. That can be valuable, but it changes what is being validated.

Document:

  • which production logic is bypassed;
  • what additional authority the mode provides;
  • how it is enabled and disabled;
  • whether it exists in production builds;
  • which requirements may be validated through it;
  • which tests must still use the normal user path.

The test plan should not claim end-to-end coverage from a shortcut that bypasses the behaviour under test.

Make identity and configuration machine-readable

Every unit should expose enough identity for evidence to include:

  • product and hardware revision;
  • serial or unit identifier;
  • bootloader and application versions;
  • calibration or configuration version;
  • enabled feature set.

The automation should collect this before execution. This prevents results from being attached to an assumed configuration.

For replaceable modules, capture their identities as well.

Design fault injection safely

Some behaviours can be validated only when inputs fail or become implausible. Provide controlled methods where appropriate:

  • simulated sensor values;
  • communication loss;
  • diagnostic fault flags;
  • supply disturbance through the external rig;
  • resource or dependency unavailability.

Fault injection should be bounded, authenticated where necessary, and clearly visible in logs and evidence. The product must return to a known state afterward.

Keep testability in the change process

Add testability review to hardware, firmware, and mechanical design changes:

  • Does this remove an observation point?
  • Does the new power path alter reset or back-power behaviour?
  • Has the diagnostic schema changed?
  • Does enclosure geometry affect the fixture?
  • Can the new state be identified and recovered?
  • Are trace and identifiers still available?

Treat test hooks as maintained interfaces, not prototype leftovers.

Testability creates options

A testable product is easier to automate, but the benefit is broader. Manufacturing can identify configuration and diagnose failures. Service teams can inspect state. Field systems can collect bounded health information. Engineers can reproduce timing and state problems with better evidence.

The goal is not to cover the product in test points or expose unrestricted debug access. It is to make visibility, control, safety, and security deliberate while the architecture is still flexible.

The cheapest time to add a reliable observation path is before the first prototype proves that it is missing.

Source notes for review

  • Arm CoreSight SoC-600 — debug access, trace routing, cross-triggering, and timestamps across the product lifecycle.
  • Arm CoreSight STM-500 — high-bandwidth software instrumentation, hardware event observation, triggers, and timestamped trace.
  • Arm CoreSight ELA-500 — embedded signal observation and trigger-based capture for design-for-debug.
  • ST AN5489 — an example hardware-design guide covering power, reset, boot, interfaces, and debug management.