Before the Firmware Is Written: Shift-Left Techniques for Embedded Testers

More true in embedded system development than anywhere else: defects discovered late in firmware or system integration are costly. They often impact hardware, device communication, and cloud services simultaneously. Misaligned expectations between stakeholders, system engineers, and developers lead to ambiguity, delayed validation, and expensive rework. As I introduced shift-left practices at an IIoT development company, we helped tackle these challenges head-on and creates the foundation for first-time-right development.

Embedded engineering brings unique challenges. Requirements are defined at the system level but realized across hardware, firmware, and cloud layers. Integration points are numerous, testing windows are limited, and rollback options are often costly impracticalities. Defining good requirements early is difficult, and misunderstandings compound quickly. Especially when dealing with hardware–software interactions, timing-sensitive behavior, and device communication flows. Achieving first-time-right in this context requires more than solid engineering; it requires a shared understanding of system behavior before any code or tests are written.

In coaching teams at IXON, an Industrial IoT platform connecting edge gateways to cloud services, we applied shift-left practices using BDD, Value Stream Mapping, and Example Mapping. This was not a textbook implementation as BDD techniques are typically aimed towards software-only development projects. We had to find the right “flight level” for BDD in a technical domain: moving from business flows to system flows, while avoiding getting lost in API schemas or protocol-level details. This balance proved essential.

The results were immediate and practical. During Value Stream Mapping, the team uncovered a timing issue between device and cloud database interactions before it required a prototype. Example Mapping revealed edge cases in device communication, including differences in behavior across specific device groups that would otherwise have surfaced during integration testing. These practices helped define hardware–software interactions upfront and made system behavior testable early. Three Amigos sessions, extended with a system architect, further strengthened refinements and reduced ambiguity during development.

In this talk, I will share these concrete examples and lessons learned, including where these techniques break down and how to adapt them to embedded environments. Attendees will learn how to define testable system behavior early, identify integration risks sooner, and apply BDD and Example Mapping at the right level of detail. The techniques are simple, practical, and directly applicable and will help embedded teams reduce costly rework and move closer to first-time-right development.