The V-Model is a product development lifecycle that maps design phases on one side and testing phases on the other. It’s simple, easy to follow, and works well for small and medium projects like smart appliances or wearables.

In this post, I’ll walk you through the tools I use to apply this model in real projects.

• Tools
  • Requirements and Traceability
  • Unit Testing
  • Integration and System Tests
  • Acceptance Testing
• Conclusions

Tools

You don’t need a massive toolchain to build a product your customers will enjoy. For small projects, I keep it simple and focus on tools that give me traceability, repeatability, and automation.

Requirements and Traceability

You can manage requirements in a spreadsheet or even a notepad if the project is small. But there are two things you absolutely need:

• Traceability: link requirements to acceptance tests (both ways). That means you should always see which requirements are untested and which tests don’t map to a requirement.
• Unique IDs: every requirement should have its own identifier.

I’ve tried many tools, but most are either overkill or don’t cover these basics. So I built my own: Raiz. It stores requirements in YAML files and works directly from the console. Since everything is version-controlled in Git, requirements can be reviewed during merge requests just like code.

Unit Testing

I’ve already written about unit testing in other posts ( here, here, here here and here). For my current projects on Zephyr RTOS, I use ZTest as the testing framework.

Unit tests run:

• Locally, every time I build.
• Automatically in CI/CD, triggered by every git push.

These tests are lightweight, so I run them as often as possible.

Integration and System Tests

For this, I use a mix of PyTest and ZTest. Tests run in two stages:

1. On Linux (PC or CI/CD VM) – fast feedback without hardware.
2. On real hardware (HIL: Hardware-in-the-Loop) – the device under test connects to a programmable power supply, Raspberry pi and automation software. Test logs are collected via UART, parsed, and analyzed.

Because HIL testing consumes more resources, I only run it before merging a branch and before releases.

Acceptance Testing

Acceptance testing is the most intensive step. I use a combination of Raiz and Robot Framework:

1. Traceability check (CI/CD): Raiz ensures requirements and acceptance tests match.
2. Automated tests (CI/CD): Robot Framework coordinates and executes acceptance tests on the system.
3. Customer testing: the product goes to the customer for real-world use. This phase requires close observation and is the most time-consuming, but also the most valuable.

Conclusions

Building embedded devices requires a well-defined process if you want quality results. It doesn’t have to be the V-Model, but it must ensure your final product works and delivers value to customers.

Testing is not always fun, but it’s essential. Setting up frameworks, scripts, devices, and CI/CD takes effort, but once everything is in place, the process runs smoothly and saves a lot of headaches.