Medical devices save lives and software is vital part of their functionality. Properly coded software ensures the critical functions of these devices are working flawlessly. The Food and Drug Administration (FDA) wants to confirm that those involved in the development of medical devices understand this. So, full confidence in the device is essential before product launch.
The safety of the product’s software should be known. It is important to use sound industry-standard practices and a robust development process to produce reliable software. Rigorous testing and verification of all parts of a system gives the confidence and peace of mind that the system and software is safe.
Though this makes sense, how does one ensure safe software? For starters, the FDA provides guidelines for medical device software. Per IEC 62304, two of the main medical device software development core steps are the “software unit implementation and verification” and “Software integration and integration testing” (B.5.5, and B.5.6). In simpler terms, the software is tested at unit level, and later at integration level with the focus being on “verification” and “testing”.
Testing is not only recommended by the FDA, but also one of the only ways to ensure proper system functioning and peace of mind.
Unfortunately, only a few developers enjoy testing their code. In many development groups, writing automated tests is seen as boring and not “real” work compared to adding features. When work is uninspiring, most people do not do well. That’s where Test Driven Development comes to the rescue.
“Test Driven Development: Write the tests for your code before writing the code itself.”
Test-Driven Development (TDD) turns this situation on its head. We write our tests before we write the code. Instead of just using testing to verify the work after it’s done, TDD turns testing into a design activity. We use the tests to clarify our ideas about what we want the code to do.
TDD transforms the role testing plays in the development process and challenges the industry’s assumptions about the purpose of testing. Testing is no longer just about keeping defects from the users; instead, it’s about helping the team to understand the features and to deliver those features reliably and predictably.
What is TDD?
TDD is based on two basic principles:
Don’t write a line of new code unless you first have a failing automated test for it
Eliminate duplication
Although very simple, these two principles’ implications are a sophisticated rhythm of software development. They lead to the Orange, Green, Refactor cycle known as TDD-cycle and they allow the engineers to focus on a small scope of the feature at hand.
TDD is an iterative approach. Just like a living organism evolves and adapts itself to its environment, so does the software – evolving and adapting itself to its tests. TDD’s iterative approach supports software to evolve into a working, elegant solution in much less time than you might think! Each Orange, Green, Refactor cycle known as TDD-cycle (pictured above) gets us closer to what we need.
You might ask, where in the software development lifecycle (SDLC) does TDD fit in. The answer is that there are two types of TDD:
Acceptance TDD (ATDD): With ATDD you write a single acceptance test, or behavioral specification depending on your preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for your solution . ATDD is also called Behavior Driven Development (BDD).
Developer TDD: With developer TDD you write a single developer test, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for your solution. Developer TDD is often simply called TDD.
The image above shows the Developer TDD scheme and how it can be integrated into the software development lifecycle.
Why TDD is important?
Test-Driven Development enforces good architecture. It also encourages the development team to test their code. As a result, it promotes establishing an automated test system. Easy to use automated test system results in more testing. More testing means better quality software.
Test-driven development also boosts your team's confidence when making changes. As product owners, managers, and architects, it is important to understand that your medical product could change over time. The change ripples into your software team needing to modify existing features and/or add new ones without breaking existing code. It is natural for your development team to make mistakes during design and development; they are only human. The important takeaway is, how your team catches the error and fixes prior to releasing to the market. The FDA only really recommends testing the software and correcting those mistakes before you deliver your product to the market and use it on patients. TDD is a software development process that demands writing tests prior to writing the production code, making it one of the most effective techniques to weave testing into the fabric of software development.
Test-driven development is enabled by good architecture, which allows your team to break down the software into smaller units and make the testing easy and accessible to the developers. At Fusion-Biotec, we have adapted an architecture to test all of the software from the lowest level firmware to top level application and user interfaces.
Our software engineers utilize test-driven development in our agile development process. The TDD approach takes a great deal of discipline, especially at the start. The developers are usually keen to get on with interesting bits of new science or improved algorithms, rather than writing seemingly non-essential code first. But in order for the TDD to work its magic, the team has to believe in it.
In our next software blog, we will discuss unit testing and how proper software architecture leads to more testable code.
Stay tuned!