Your browser is no longer supported. Please upgrade your browser to improve your experience.

Looking for a software estimate? Let’s chat.

Software testing for embedded software: A test-first approach to software development

Software testing is an integral, integrated part of our embedded software service offering. As a quality-driven company, we believe in the undertaking of rigorous testing during development as opposed to at the end of all development. This enables us to catch bugs early so as to minimise the cost of fixing them. It also ensures the long-term health of your product, allowing for continuous improvement, innovation and scalability, all supported by a practice that builds quality into every line of code.

Testing that supports compliance

For clients in sectors that need to meet strict regulatory compliance needs, such as medical, biopharmaceutical, chemical, industrial and aerospace, our approaches to testing are readily able to align with your needs. In fact, the advantage of being a company that is test-first when it comes to development, is that we can clearly track and document development choices and software changes, improving overall traceability. We find that, if implemented properly, a Test-Driven Development and Behaviour-Driven Development approach can help turn compliance from a burden into an opportunity to bring real tangible value to your products, stakeholders and end users.

What does test-first look like at Bluefruit Software?

We manage this test-first approach across both our Software Engineers and our Test Engineers. Testing is an integral part of our sprints (lasting two weeks) and happens through several different processes. These processes are part of how we deliver Lean-Agile software development for embedded systems.

By taking a test-first approach, we capture the intent rather than the solution—improving efficacy from 60% to 85%.

Who does what?

Embedded Software Engineers focus on:

  • Test-Driven Development (TDD): A test is written and made to fail, then code is written to pass that test.
  • Unit Tests: Unit tests are run when software is built. These are often the tests written during TDD, but further Unit Tests are sometimes added, dependent on the project (such as when working with legacy code).
  • Code Reviews: Once a feature is completed, another software developer checks the feature before it is merged into the rest of the software.

Test Engineers focus on:

  • Acceptance Tests: System tests check code is performing correctly and match the specification. Acceptance tests check the software meets the user’s needs (or customer requirements).
  • Regression Tests: Acceptance testing covers only the current sprint. Regression tests are done to ensure that previous features have not been affected by recent work.
  • Exploratory Tests: Though all the features may be working correctly, it may be that other behaviour is incorrect, this is often discovered with Exploratory testing. Here the tester often acts like a “bad user” making the choices that programmers may not have anticipated.

But clients, engineers and testers are all involved with Behaviour-Driven Development.

Use Behaviour-Driven Development to build what is needed

How do we know that what we’re building is what is needed by stakeholders and eventual end users? We use Behaviour-Driven Development (BDD) to help with this.

BDD is like TDD, but instead of a series of tests written from a technical perspective, BDD looks to behaviour and user journeys through the system to build the software requirements. Tests are written to enable this (often in a ubiquitous language called “Gherkin”). Ideally, these tests are automated.

Software Engineers, Test Engineers and stakeholders are all involved with BDD, as the behaviours that it’s built on are discussed and recorded before a sprint starts (in a meeting called Three Amigos).

Enabling test-first through TDD and BDD and supporting verification and validation for compliance

TDD and BDD are both powerful tools for meeting verification and validation for software in medical devices. TDD supports verification, while BDD upholds verification.

Both help to identify interrelationships within the code base and can provide practical evidence of compliance with IEC 62304.

Automated testing

Bluefruit are constantly exploring new ways to add value to projects. Recently, this has included working with clients to apply automated testing to their projects when it fits with their development needs. This is not an off-the-shelf solution, but rather something we build carefully with our client’s team ensuring it adds value.

For one of our medical clients, by investing in building an automated testing solution, we were able to decrease their release time from eight weeks to two weeks with a significant reduction in the amount of manual testing required. This meant that the manual testing we did could focus on the most critical quality elements, with the automated testing picking up the more menial and laborious tasks.

Automated testing isn’t a solution that works for everyone; however it often achieves better ROI when also used to fulfil production line testing.  If you would like to learn more we are happy to have a further conversation about it. Alternatively, we could review your project and provide an assessment of the value it might provide.

TDD and BDD insights

Looking for quality-focused embedded software engineers and testers? You’ve found them.

Bluefruit Software has over 20 years of experience delivering high-quality software development and testing for embedded system software. With clients across medtech, industrial, scientific, agritech and aerospace, we’re well prepared to help your team with your latest project.

Send us an email