Test automation

We have been building and running test automation for over a decade — from unit tests in CI to hardware-in-the-loop validation across shared device labs. We do not sell test frameworks. We solve the problem of getting reliable signal from systems that are expensive, scarce, or hard to reproduce.

Where we focus

Hardware-in-the-loop testing

When your product is firmware, an embedded board, or a custom peripheral, "works in simulation" is not enough. We build pipelines that:

  • Flash firmware to real devices automatically
  • Collect serial logs, sensor readings, and timing traces
  • Handle power cycling and device reset for flaky hardware
  • Allocate scarce hardware across competing jobs without collisions

This is where Schedy comes in — our firmware flashing and hardware test automation platform. It has run over 46 million test runs across shared device labs since 2016, with full timeline visibility and artifact collection for every execution.

Schedy in depth

Schedy automates the entire pipeline from code commit to validated hardware result:

  1. Trigger — Git commit, nightly schedule, manual run, or external hook
  2. Build — Firmware is compiled and packaged
  3. Schedule — Schedy allocates available hardware from the shared pool
  4. Flash — Firmware is written to the target devices
  5. Test — Hardware tests execute on the actual devices
  6. Collect — Logs, artifacts, and results are gathered and stored

It handles resource locking, conflict prevention between tests, and multi-site scheduling — so a team in one location can queue jobs against hardware in another lab without stepping on each other.

Production track record: Our oldest Schedy deployment has been running since 2016, with over 46 million test runs and more than 845 million artifacts (277 TB) collected. It has outlived multiple CI trends because it solves a problem that off-the-shelf tools do not: reliable, reproducible testing on physical hardware at scale.

Supported resource types: test stations, embedded devices, sensors, hubs, dongles, flashing tools, and custom fixtures.

Triggers: Git commits, nightly schedules, manual runs, and external hooks.

Execution observability and artifact debugging

When a hardware test fails, you need more than a red X. Schedy provides:

  • Timeline view — see task progression across time and workers at a glance
  • Per-task results — each step reports success, failure, or timeout independently
  • Log and artifact collection — serial output, memory dumps, sensor readings, and captured traces are stored with the execution record
  • Filtering and drill-down — search by tag, device, commit, status, or date range
  • Re-execution — queue the same configuration again for confirmation or bisection

This is the visibility you need when a failure only reproduces on one specific board revision, or when a thermal issue appears after the 500th cycle.

Test infrastructure, not just test scripts

A test is only as reliable as the environment running it. We design and maintain:

  • Bare-metal build and test farms with reproducible environments
  • Resource scheduling across hardware generations, sites, and teams
  • Artifact and log pipelines that make failures debuggable without re-running
  • Emulation boundaries — knowing when QEMU is sufficient and when you need the real silicon

Integration with your CI

We embed into existing CI systems — Jenkins, GitLab CI, GitHub Actions — adding the specialized stages that standard runners cannot handle. The goal is a single pipeline that covers host builds, cross-compilation, and hardware validation without forcing a monolithic tool choice.

What we do not do

  • We do not write your application unit tests for you
  • We do not sell one-size-fits-all test frameworks
  • We do not pretend emulation is equivalent to real hardware when it matters

What we do is make your existing test effort more reliable, faster, and actually representative of production behavior.

How we work

Assessment — We review your current test setup, hardware constraints, and CI integration. We identify which failures are costing you time and which could be caught earlier.

Implementation — We build or extend the pipeline: Schedy workers, hardware test rigs, artifact collection, or CI integration layers.

Knowledge transfer — We train your team to add devices, interpret results, and extend the system. Test infrastructure should not depend on one person's memory.

Deliverables

  • Version-controlled test pipeline definitions
  • Hardware test runbooks and failure-mode documentation
  • Schedy deployment with configured workers and device pools (where applicable)
  • Integration with your existing CI, artifact stores, and notification systems
  • Documentation and training for your engineering team