What we deliver
Unit test suites
Requirements-based unit tests in VectorCAST, Tessy, GoogleTest or Unity/Ceedling, with stubs, boundary and robustness cases, run on host and on target.
Integration and system tests
Tests across drivers, middleware, RTOS tasks and communication stacks, through to black-box system tests on the real board or a HIL bench.
Static analysis and MISRA compliance
MISRA C:2012 or MISRA C:2023 checks with Helix QAC, Polyspace or Parasoft, triage of findings, deviation records and a compliance report.
Structural coverage
Statement, branch and MC/DC coverage measured on host or target, gap analysis and justification of unreachable or defensive code.
CI testing on target
Jenkins, GitLab CI or GitHub Actions pipelines that flash boards, run tests through TRACE32 or J-Link probes and publish results per commit.
Security testing and CRA readiness
Fuzzing of parsers and protocol stacks, SBOM generation, vulnerability scanning and secure-update tests for IEC 62443-4-2 and the EU Cyber Resilience Act.
Standards and what they ask of testing
| Standard | Scope | What testing must show |
|---|---|---|
| IEC 61508 | Electrical, electronic and programmable safety-related systems | Module and integration testing with rigour rising by SIL, structural coverage per IEC 61508-3 Annex B, traceability to safety requirements |
| IEC 62304 | Medical device software | Unit verification for software safety classes B and C, integration and system testing, regression testing and resolved anomalies |
| IEC 62443-4-1 / 4-2 | Industrial automation and control system components | Security functional tests, vulnerability testing, fuzzing and penetration testing against the target security level |
| EU Cyber Resilience Act | Products with digital elements sold in the EU | No known exploitable vulnerabilities at release, secure defaults, security updates and an SBOM; reporting from 11 Sep 2026, most obligations from 11 Dec 2027 |
| MISRA C | C coding guidelines for critical systems | Compliance with mandatory and required rules, with recorded deviations, normally shown by static analysis |
How we work
01
Assess the current state
Review requirements, existing tests, coverage, toolchain and CI, and list gaps against the target standard.
02
Agree the strategy
Define test levels, host versus target execution, coverage targets, tool qualification needs and exit criteria.
03
Build tests and pipelines
Write and review tests, set up static analysis and coverage measurement, and connect boards to CI.
04
Run and triage
Execute per build or nightly, analyse failures with developers and track defects and MISRA deviations.
05
Hand over evidence
Deliver test reports, coverage and traceability for the safety or security file, and keep the suite maintained.
Where this fits
Embedded testing often runs alongside development from our embedded & industrial practice, such as firmware and BSP or device driver work. For frameworks and pipelines see test automation, for security testing in depth see cybersecurity testing, and for certification preparation see compliance & certification.
Standards
- EU Cyber Resilience Act
- IEC 61508
- IEC 62304
- IEC 62443
- IEC 62443-4-2
- ISO/IEC 29119
- ISTQB
- MISRA C
Toolchains our engineers work with
- Ceedling
- GitLab CI
- GoogleTest
- Helix QAC
- Jenkins
- Lauterbach TRACE32
- LDRA
- Parasoft C/C++test
- Polyspace
- SEGGER J-Link
- Tessy
- Unity
- VectorCAST
Related work
Case studies →Fuzz and penetration testing an industrial gateway for the Cyber Resilience Act and IEC 62443-4-2
A recurring security test cycle for an industrial gateway: fuzzing, penetration tests and SBOMs mapped to IEC 62443-4-2 and the CRA.
Planning MIL-STD-810H and MIL-STD-461 pre-compliance for an indigenised rugged subsystem
Tailoring MIL-STD-810H and 461 requirements, writing procedures, running pre-scans and preparing a rugged LRU for its accredited lab campaign.
Closing DO-178C structural coverage with independent verification for a DAL B component
Independent verification closes statement and decision coverage, coupling analysis and tool qualification for a DAL B software component.
Further reading
All insights →Building an engineering or test team for a mid-market GCC in India
Ramp waves, dedicated team vs Build-Operate-Transfer, governance and the measures that matter for a mid-market GCC's engineering or test team.
Euro NCAP 2026 ADAS Testing: What Changes for SIL/HIL Test Plans and Test Capacity
Euro NCAP 2026 multiplies ADAS test variations. How to restructure SIL/HIL plans around ISO 34502 and OpenSCENARIO, and plan the capacity.
Automotive Cybersecurity Penetration Testing for R155: Fuzzing, OTA and ISO/SAE 21434 Evidence
What R155, R156 and ISO/SAE 21434 test evidence suppliers need, and where fuzzing, penetration testing and OTA tests fit.
Frequently asked questions
Should unit tests run on the host or on the target?
Both, for different reasons. Host execution is fast and fits every commit; target execution catches compiler, word-size, endianness and timing effects that host builds hide. A common pattern is host tests on every merge request and the same tests rerun on target nightly, with coverage taken from whichever run your standard and tool qualification accept.
What is MC/DC coverage, and when do we need it?
MC/DC shows that every condition in a decision independently affects the outcome. It is required for DO-178C Level A, highly recommended for ISO 26262 ASIL D at unit level and for SIL 4 under IEC 61508-3. Lower integrity levels usually need statement or branch coverage. Coverage is measured on requirements-based tests, not on tests written only to raise the figure.
What does the EU Cyber Resilience Act require us to test, and by when?
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, including for products already on the market. Most other obligations, including conformity assessment, apply from 11 December 2027. The testing work follows from the essential requirements: vulnerability scanning against an SBOM, fuzzing of exposed interfaces, secure-default and secure-update tests, with evidence kept in the technical documentation.
Is IEC 62304 software testing different from other embedded testing?
The techniques are the same; the rigour and records depend on the software safety class. Classes B and C need unit verification against acceptance criteria and integration testing, all classes need system testing, and every anomaly must be evaluated and resolved or justified. The 2006 edition with Amendment 1:2015 remains the reference version.
Do our test tools need to be qualified?
If a tool could introduce an error or fail to detect one in safety evidence, yes. ISO 26262-8 uses tool confidence levels, DO-178C uses DO-330 tool qualification levels, and IEC 61508-3 classifies offline tools as T1, T2 or T3. Vendors such as VectorCAST, LDRA and Polyspace offer qualification kits, which are applied to your configuration and documented use cases.
Can you take over testing of an existing product?
Yes. We start by assessing current requirements, tests, rigs and pipelines, then take over execution and maintenance in stages so regression protection is not lost. Gaps in automation, coverage and traceability are closed in an order agreed with your team. For a longer-running arrangement, see managed testing services.
Can we hire embedded test engineers instead?
Yes. We recruit embedded test, automation and verification engineers on contract, contract-to-hire or permanent terms. See hire test engineers or hire embedded engineers for role profiles and how candidates are screened.
Tell us your domain, standard and team size — get a scoped brief in 2 minutes.