I’ve spent plenty of time writing test plans to meticulously check the satisfaction of every software requirement for a medical device. Running through such a single test plan for a reasonably complex medical device can take hours. There will probably be dozens of test plans. Fully running tests, assuming everything goes perfectly, can take a week or more.

If all of your tests are manual, they are time-consuming.

If they are time-consuming, they are also expensive.

If they are expensive, you won’t want to do them often.

If you don’t want to run tests often, either:

• you won’t want to make changes, OR
• you won’t rerun tests when the inevitable changes come.

If you don’t make changes, you won’t adapt to evolving requirements.

If you won’t adapt to evolving requirements, your device will suffer from waterfall syndrome, failing to incorporate any of the lessons you learn during development.

We all know that requirements change constantly during development, so that means we don’t rerun our time-consuming, expensive, manual tests every time there is a change.

If you don’t run your tests when there’s a change, you don’t know whether you’ve introduced new bugs.

Tada! You aren’t really testing.

Automated tests, on the other hand, run constantly, completely, and automatically on every single code commit.

Are there downsides to automated testing? Of course. I’ll explore that next time.

But… I’m certain that automated unit tests need to be a part of your arsenal.

Happy developing!