After you've documented some of your Software Requirements in Formwork, you now probably want to document some Software Tests. Why? Because the IEC 62304, the standard for software development for medical devices, requires you to show that every requirement is covered by at least one test.
Documenting tests is fun, right? Right? So let's get started!
Navigate to "Products" in the top menu, and then "Software Tests" on the left side. You'll be greeted with your list of Software Tests, which is probably more empty than this one:
This is pretty much the same deal as the list of Software Requirements - every entry has a unique ID, you can drag and drop stuff, etc. Click "+ New" in the top right corner to create a new Software Test!
This is where things get interesting. Let's go through the fields in detail:
Internal ID: A unique ID for this test, pre-filled by Formwork
Title: The title of this test. Briefly describe what it's testing.
Description: Longer form description of this test. You likely want to enter specific setup or configuration instructions here so that people actually know how to perform this test.
Steps & Expected: The actual test steps which need to (manually) be performed when running the test. On the left side, document the steps which should be taken, and on the right side, document the expected result at each step.
Software Requirements: Link this Software Test to one or many Software Requirements. This link is bi-directional, i.e. if you add some links here, those will also be reflected in the Software Requirements (awesome)!
Risk Controls: Whether this Software Test is used as a Risk Control measure. In that case, you'd need to create a Risk Control and then link it here.
Okay, a quick aside. You've by now noticed that this is geared towards manual testing. Why not do fancy automated testing of your software? Because manual testing is the most efficient approach, and you're likely working at a company which doesn't want to spend 1 - 3 months developing their own testing library. Read this post to understand our detailed thoughts.
Okay, now which of those fields are mandatory and which are optional? Here's a handy table:
Field
Mandatory / Optional
Reason
Internal ID
Mandatory
As per the IEC 62304 (and for your own sanity), each test should have a unique ID.
Title
Mandatory
How the hell do you manage tests without titles?
Description
Optional
Not every test might need detailed setup and configuration instructions.
Steps
Mandatory
You need to define steps to document a test.
Expected Results
Mandatory
Same goes for results.
Software Requirements
Optional
While this field is technically optional, every test should be linked to at least one requirement (and vice versa). Feel free to leave it empty for now, but definitely come back once you've defined at least one requirement which is covered by this test.
Risk Controls
Optional
Most Software Tests are not Risk Controls, so this will only be filled out for a few Software Tests. In most cases, it'll be empty.
Cool, and that's it for Software Tests! Finally, a quick word about versioning & reviewing Software Tests.
Versioning & Reviewing
The logic for versioning and reviewing tests is the same like for all other Techdoc items. We've explained it in more detail here for Software Requirements, so check that out.
On a different note: Do you need any help with your EU MDR efforts?
We've worked with 100+ companies and helped them certify their devices in weeks, not months. Talk to us now – first calls are free! Check out our services and prices here.
Or, if you don't like talking to humans, check out our Wizard. It's a foolproof, step-by-step video course for getting your compliance done yourself.
And if you're looking for the best QMS software for lean, founder-led companies, check out Formwork. It automates your compliance, and there's even a free version for you to try out!
Get notified when we post something new. Sign up for our free newsletter.
No spam, only regulatory rants. Unsubscribe anytime.
0 comments
No comments yet. Be the first one to share your thoughts!
Dr. Oliver Eidel
I’m a medical doctor, software engineer and regulatory dude. I’m also the founder of OpenRegulatory.
Through OpenRegulatory, I’ve helped 100+ companies with their medical device compliance. While it’s also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)
If you’re still lost and have further questions, reach out any time!
