hello@dothex.net

+44 (0) 20 3290 3080

London, UK

FREE CONSULTATION

Embedded Systems & Product Development Consultancy · London, UK

Testing and verification

Bugs that reach customers before testers

Embedded teams often test by hand, on one bench, just before a release. That finds some bugs, late and expensively.

  • No unit tests, so every change risks breaking something nobody checks.
  • Manual test runs that take days and get skipped under deadline pressure.
  • Problems that only appear at low temperature, on a low battery or after days of running.
  • Production units tested differently on every line, or not tested at all.
  • Test results kept in spreadsheets, with no link to the firmware version.
  • Field returns that can’t be reproduced in the lab.

We automate the checks that matter and run them on every build and every unit.

Test systems we build

  1. Unit testing. Unit tests for firmware modules on the host and on the target, with coverage reports, including LDRA for safety projects. →
  2. Hardware-in-the-loop rigs. Test rigs that drive inputs, simulate sensors and networks and check outputs on real hardware.
  3. Production test jigs. Fixtures with Python or C# software that program, test and calibrate each unit on the line. →
  4. Continuous integration. Builds, static analysis and tests on every commit, with release artefacts that can be traced.
  5. Environmental and long-run tests. Temperature, power and soak tests that find faults which only appear at the extremes or over time.
  6. Field and acceptance tests. Factory and site acceptance tests planned and supported with the customer.

Building a test strategy that lasts

  1. Decide what must never break. Safety functions, connectivity, power and the features customers notice first.
  2. Test at the right level. Unit tests for logic, hardware-in-the-loop tests for timing and interfaces, system tests for the whole product.
  3. Automate early. Scripts and rigs built alongside the firmware, so tests grow with the code.
  4. Connect tests to releases. Every test run tied to a firmware version and a board revision.
  5. Carry tests into production. The same checks, trimmed for speed, running on the production line.

Frameworks, rigs and pipelines

Unit test frameworks: Unity and CMock, GoogleTest, Ztest for Zephyr, LDRA tool suite

Automation: Python with pytest, C# and .NET test applications, YAML test definitions

CI and tooling: Git, GitHub Actions, GitLab CI, Jenkins, static analysis, code coverage

Test hardware: J-Link and ST-Link probes, logic analysers, programmable supplies, environmental chambers

Proof from the production line

Client names stay private. The engineering doesn’t.

Automated production testing that cut production time by 60% for an ATM security device

View case studies

Unit tests and automatic production calibration for a wearable medical device

Read the case study

More test work

Ask about this work

Frequently asked testing questions

Can you unit test firmware that talks to hardware?

Yes. We put hardware access behind thin interfaces, then test the logic on a PC with mocks and run the hardware-dependent parts on the target.

Can you add tests to an existing codebase?

Yes. We start with the riskiest modules and the bugs you’ve already had, add tests around them, and grow coverage as the code changes.

Do you build production test jigs?

Yes: the fixture, the test software and the operator interface, with results logged for every serial number. See production test jigs.

Which CI system do you use?

Whichever your team uses, such as GitHub Actions, GitLab CI or Jenkins. Pipelines build the firmware, run static analysis and tests, and keep the artefacts for each release.

What is hardware-in-the-loop testing?

Running the real firmware on the real board while a test rig plays the outside world: sensors, buttons, networks and power supplies. It catches timing and interface faults that unit tests can’t.

Do you test to safety standards?

Yes. For IEC 61508 projects we use the LDRA tool suite for unit testing, coverage and code review, and keep the records an assessor needs.

Want releases you can trust?

Talk to an engineer

Latest from the blog