Quick summary
In regulated and safety-critical contexts, testing has to produce evidence, not just confidence. This guide explains how quality assurance works across embedded, industrial and connected systems, from hardware-in-the-loop rigs to the proof regulators now demand.
Quality assurance changes character the moment a system becomes regulated or safety-critical. The governing question is no longer "does it work" but "can you prove it works, and that you verified it the right way". Under standards such as IEC 61508 and regulations such as the Cyber Resilience Act, the test evidence itself becomes a deliverable that auditors and assessors will examine, which means QA stops being an internal comfort and becomes an external, defensible output.
That shift unifies everything that follows. Whether the subject is an embedded controller, a piece of safety-critical firmware, a connected product or the choice of test method itself, the underlying demand is the same: testing must be defensible. The rigs, the evidence trails, the regulatory proof and the strategic mix of manual, automated and AI-assisted approaches are all ways of meeting that single standard, and the organisations that build QA around evidence rather than around confidence are the ones that pass audits and ship dependable systems.
Embedded control and protection systems cannot be validated by software tests alone, because their correctness depends on how they interact with physical conditions. Hardware-in-the-loop testing addresses this by connecting the real controller to a simulated model of the plant it controls, exposing behaviour, including responses to faults and edge conditions, that pure software testing would never surface before the system reached the field. The method, and why it is indispensable for embedded work, is the subject of the analysis of hardware-in-the-loop testing for embedded systems.
This realism is the whole point. A controller that passes every software test can still fail against the physical dynamics it will actually encounter, and disciplined quality assurance for embedded systems is built around closing exactly that gap.
Takeaway: Embedded systems need testing against realistic physical conditions, not only against code.
When failure can harm people, QA is governed by functional safety standards that demand traceability and independent verification. The trail of evidence, linking each requirement to the tests that verify it and the results those tests produced, matters as much as the testing activity itself, because it is what allows an assessor to trust the outcome. That evidence-centred discipline, under IEC 61508 and its derivatives, is detailed in the treatment of quality assurance for safety-critical embedded software.
The reframing is significant. In ordinary development, documentation supports the software; in safety-critical development, the documented evidence is part of what is being delivered, and a system without it is incomplete regardless of how well the code performs.
Takeaway: In safety-critical QA, the evidence trail is the product as much as the test outcome.
Connected products break the assumptions traditional QA was built on. They combine hardware, firmware, networks and cloud services, so a defect can hide in the interactions between layers rather than in any one of them, which is why conventional testing approaches fall short, as set out in the analysis of QA for IoT and connected products. The difficulty is compounded by pace: ENISA documented over 42,595 new vulnerabilities in its latest reporting period, a 27 percent increase, with critical ones weaponised within days of disclosure (ENISA, 2025).
Regulation has responded by shifting the burden from assertion to proof. The Cyber Resilience Act requires manufacturers to demonstrate security properties rather than claim them, which turns testing into a source of regulatory documentation, the substance of what manufacturers of connected products need to prove under the act. For connected products, in other words, QA increasingly exists to generate evidence an external authority will inspect.
Takeaway: For connected products, QA increasingly has to generate regulatory evidence, not just internal assurance.
How testing is performed is not a neutral implementation detail but a strategic choice with consequences for speed, cost and defensibility. Artificial intelligence can accelerate test generation and triage, but in regulated contexts it cannot supply the determinism, traceability and independent judgement the work requires, which is why its role has to be carefully bounded, as examined in the analysis of AI in software testing for regulated industries. The point is not that AI is unwelcome but that it accelerates processes which must remain human-controlled and reproducible.
Beneath that sits the older, equally strategic question of where to automate and where to keep human testers. There is no universal answer, only a decision framework tied to context, risk and the value of each approach, which is precisely what the comparison of manual versus automated testing provides. Test strategy, properly understood, is a deliberate trade-off rather than a default setting.
Takeaway: Test strategy is a deliberate trade-off between speed, determinism and the evidence regulators expect.
Quality assurance for regulated and safety-critical systems is held together by one principle: testing must be defensible. Hardware-in-the-loop rigs make embedded testing realistic, functional-safety evidence trails make outcomes trustworthy, connected-product testing generates the proof regulators now demand, and a considered mix of manual, automated and AI-assisted methods keeps the whole effort both efficient and reproducible. The organisations that treat QA as the production of evidence, rather than the accumulation of confidence, are the ones whose systems hold up under scrutiny and in service.
It connects a real embedded controller to a simulated model of the system it controls, so the controller can be tested against realistic conditions, including faults and edge cases, before deployment. It reveals behaviour that software-only testing cannot.
No. AI can accelerate test generation and analysis, but regulated work still requires determinism, traceability and independent verification that AI cannot provide on its own. It augments human-controlled processes rather than replacing them.
Because it shifts the burden from asserting security to proving it. Manufacturers must produce evidence of secure design, vulnerability handling and testing, which makes quality assurance a direct source of the regulatory documentation an assessor will examine.
ENISA Threat Landscape 2025 – ENISA – 2025 – https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
Cyber Resilience Act, official text and timeline – European Commission – 2024 – https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act