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!
Here’s how it looks:
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.
