What Problem This Solves
🚧 Documentation under development
The RidgeRun Embedded Test Orchestrator guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
What Problem This Solves
Embedded software must interact closely with hardware. A change in a driver, kernel configuration, firmware component, or system service can affect cameras, USB devices, networking, storage, GPIOs, or custom peripherals.
As the product grows, so does the number of features and hardware combinations that must be checked before every release. Without a repeatable validation process, maintaining confidence in the platform becomes increasingly difficult.
1. Manual Validation Does Not Scale
Manual testing may work during the early stages of a project, but it becomes harder to maintain as the product evolves.
Common problems include:
- Tests are executed differently by each developer.
- Some features are skipped because validation takes too long.
- Results and logs are stored in different locations.
- Tests are difficult to repeat across devices and software versions.
- Validation depends on the availability and experience of specific team members.
This makes the process slow, inconsistent, and difficult to reproduce.
2. Regressions Become Harder to Isolate
When validation is delayed, multiple software changes may accumulate before a regression is discovered. This increases the number of possible causes and makes the responsible change harder to identify.
Figure 1 compares late detection with frequent validation. A shorter detection window keeps the investigation scope small and closer to the change that introduced the problem.
One failure can also hide another. For example, a broken MIPI interface may prevent camera tests from exposing a separate driver regression. The team must resolve the first failure and repeat validation before the next problem becomes visible.
For the wider economic and organizational impact of late detection, see How Much Does a Bug Cost You?.
3. Embedded Tests Must Run on Real Hardware
Unit tests and software simulations are important, but they normally validate components in isolation. They cannot fully reproduce the interaction between the operating system, drivers, firmware, physical interfaces, peripherals, and real hardware conditions.
Problems related to timing, power, device initialization, kernel configuration, hardware communication, or physical connections may only appear on the target device.
Embedded platforms may also have many combinations of:
- Software versions
- Hardware revisions
- Drivers and firmware
- Connected peripherals
- System configurations
Manually testing every combination takes significant engineering time. Developers should remain focused on building and improving product features instead of repeatedly executing the same validation steps.
The validation process must therefore be repeatable and capable of checking real hardware without requiring constant manual effort from the development team.
4. The Need for Continuous Validation
Embedded development teams need a repeatable way to validate critical functionality throughout the development process, not only before a release.
Tests should run frequently, use the same validation criteria, preserve their results, and provide feedback while recent software changes are still easy to identify.