Stop burning engineering hours on tests a machine can run overnight
Engineering test automation replaces manual, engineer-attended testing — firmware regression checks, parameter sweeps, environmental soak tests, instrument-and-clipboard characterization — with systems that run unattended and report results. It removes a quiet tax on development speed: senior engineers spending afternoons twiddling knobs and transcribing readings, and regressions slipping through because the full manual test is too tedious to run every release.
Willowark automates the test as engineers actually run it, then improves on it. We sit with your team, capture the procedure including the unwritten judgment calls, and encode it: instrument control, stimulus generation, measurement, and pass/fail criteria made explicit. The goal is a suite your team trusts enough to gate releases on.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The building blocks depend on what is under test. For embedded products we build hardware-in-the-loop rigs: real firmware on real boards, surrounded by simulated sensors and loads, relay or SMU-switched fault injection, and power cycling under script control, so every firmware commit can face the full torture suite. For instrument-based testing we script the bench itself — SCPI over VISA to supplies, scopes, DMMs, and environmental chambers — turning a week of manual characterization into an overnight queue. Results land in a database with full configuration capture, and the suite runs from CI where that fits, so a failing test blocks a merge instead of surprising a customer.
Success is measured in cadence and confidence: regression coverage that runs on every build instead of every release, characterization matrices that grow because they are cheap now, and engineers reallocated from executing tests to designing better ones. The first time the overnight run catches a regression that manual spot-checking would have missed, the rig has typically justified itself.
Not every test deserves automation, and the first job is deciding which ones do. We rank candidates by how often they run, how long they take, how error-prone the manual version is, and how expensive the escapes have been, then start with the small set that pays back fastest — often a single regression suite or one characterization sweep. That first rig is deliberately modest, built on a pattern that can grow: instrument abstractions, a test definition format, and a results schema that will still make sense when the suite is ten times larger. Coverage expands from there, one procedure at a time.
An automated suite that never fails is a suite that is not testing anything; part of commissioning is proving the rig catches known-bad firmware and deliberately broken hardware. We also expect it to surface things nobody was looking for — an intermittent that only shows on the four-hundredth power cycle, a timing margin that was always thin — and those findings are treated as a first return on the investment rather than a distraction. Everything delivered — rig drawings, wiring, fixture CAD, test source, and results schema — is yours in editable form, structured so your engineers, not ours, are the ones extending it.
Scope it in writing
What we agree before work starts
- Test automation rig: HIL hardware, instrument control, or both
- Automated test suites encoding your procedures with explicit pass/fail criteria
Build with checkpoints
Working results, not slide decks
- Fault-injection and environmental sequencing where the product requires it
- Results database with configuration capture and trend reporting
Hand over something you own
Documentation, source, and training
- CI integration and documentation for extending the suite in-house
- Rig documentation: drawings, wiring, fixture files, and setup procedure for replicating the station
Sound familiar?
Where engineering test automation earns its keep.
A firmware team whose full regression test takes two engineer-days, so it runs only before releases
A power electronics product needing characterization across line voltage, load, and temperature
A recurring field failure that only appears after thousands of power cycles no human will sit through
A certification retest cycle where every lab visit costs weeks, making pre-scan automation valuable
Ask about Engineering Test Automation
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
X-ray thickness gauge
Components:
- X-ray source (+ detector): Source and detector pair measuring attenuation through the material.
- Acquisition (signal chain): Signal conditioning and acquisition.
- Gauge software (thickness model): Calibrated model converting attenuation to thickness.
- Line control (feedback): The line's controller, closing the loop on thickness.
Connections:
- X-ray source to Acquisition
- Acquisition to Gauge software (calibrated)
- Gauge software to Line control (thickness)
An industrial measurement company · Industrial measurement
X-ray thickness gauge
A complete X-ray based thickness gauge: equipment assessment, hardware selection, electrical and hardware engineering, API integration, all software, and commissioning — delivered as a working instrument.
Read the case study →Common questions
Asked before every engineering test automation project.
Our test procedures live in engineers' heads. Can you still automate them?
Yes — extracting them is the first phase of the work. We observe the test being run, ask about the judgment calls, and write the procedure down before automating it. Teams usually find this step valuable by itself, because the unwritten version often differs between the two engineers who run it.
What is a HIL rig, and do we need one?
Hardware-in-the-loop means your real firmware runs on real boards while the rig simulates the world around it — sensors, loads, faults, power events — under script control. You need one when the behaviors worth testing are hard, slow, or destructive to produce naturally: fault responses, edge-case sensor values, thousands of power cycles. If bench-instrument scripting covers your needs, we build the simpler thing.
Who maintains the automation after you leave?
Your team, by design. We build on maintainable foundations — typically Python with standard instrument libraries — structure tests so adding one follows an existing pattern, and include working sessions so your engineers extend the suite before the engagement ends. Ongoing support is available, but dependence on it is not the architecture.
How much does the automation change as our product changes?
Less than the product does, if it is structured well. Tests are written against interfaces — a command, a measurement, a pass/fail rule — so a new board revision typically means updating a fixture or a configuration file, not rewriting suites. The rig itself is designed with spare channels and generic instruments where practical. Some rework at major product changes is normal and should be budgeted; a suite that needs a rewrite every revision was built wrong.
Can automated tests replace our lab visits for certification?
They do not replace accredited testing, but they can reduce how many times you pay for it. An automated pre-scan or pre-compliance sequence run in-house catches most problems before the formal test, so the lab visit becomes a confirmation rather than a discovery. We build those sequences to mirror the relevant test methods as closely as the available equipment allows, and we are clear about where in-house results are indicative rather than equivalent.
Where this sits
Engineering Test Automation, inside a r&d & prototyping system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Requirements become a bench prototype with real sensors and firmware; a test rig produces data; a pilot unit runs in the field; and the design is handed to production with everything documented.
Components:
- Requirements: What it must measure, survive and cost.
- Bench prototype (MCU + sensors): Dev board, real sensors, real signal chain.
- Firmware: Acquisition, processing, comms, update path.
- Test rig (data): Instrumented tests against known references.
- Pilot unit (in the field): A handful of units where the product will live.
- Production (handoff): Drawings, BOM, test procedure, firmware — yours.
Connections:
- Requirements to Bench prototype over handoff
- Bench prototype to Firmware
- Firmware to Test rig over serial
- Test rig to Pilot unit over handoff
- Pilot unit to Production over handoff
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.

