December 5th, 2017 by Adam Sandman
At Inflectra we like to make the lives of customers easier and share knowledge. We have lots of customer in the life sciences industries using SpiraTeam to manage and test medical device systems and products. Since such products have to follow the FDA 21 CFR Part 11 requirements, we thought it would be useful to highlight some of the best practices we have for configuring SpiraTeam in such environments. This is the third article in the blog series, and covers the configuration of the test case workflows.
Configuring the Test Case Workflow
In the previous article we described how to setup the workflows for managing your requirements. Now that this is in place, the next step is to configure the test case workflow. To access the test case workflow, log in as a project administrator and go to the Administration > Testing > Test Case Workflows screen:
You can have different workflows for each of your different types of test case, or simply use the same workflow for all of them. We shall illustrate the recommended workflow configuration for a life sciences customer, you can then apply it to the appropriate test case types.
By default, SpiraTeam is configured with a pretty unrestricted testing workflow designed for agile software development projects (vs. validated life science projects), so that means:
- A large selection of roles that can execute most of the transitions
- The owner/detector can execute most of the transitions once the test case has been assigned
- Most fields are listed as:
- Not required
- Visible
- Enabled
- You can edit the test steps regardless of the status of the test case
- You can execute the test case regardless of the status of the test case
- There is no post-execution workflow approval process
So, we recommend that you make the following changes to your test case workflow:
1) Add the Post-Approval Transitions
If you look at the workflow steps and transitions that are included out of the box, you will see the following:
The Tested and Verified statuses are not linked into the default workflow. This is because in a typical software development (non-regulated) project, you would simply leave the test case as Ready for Test until it is no longer needed, after which you move to Obsolete. However for a validated project you will typically need to have multiple levels of approval and sign-off after the test case has been executed and passed. So you would need to add the following transitions:
Now that we have added the new post-execution approval steps, we can now configure the transitions...
2) Restrict the Roles/Permissions in the Transitions
Next you should click on each of the test case workflow transitions and view the list of users that can execute such transitions:
Typically most of the test case workflow transitions will be set to allow:
- The Creator to be able to execute
- The Owner to be able to execute
- The Project Owner and Manager roles to be able to execute.
You should now review your test validation process to see how the different roles in SpiraTeam and the steps in the process will be aligned to ensure that the correct personnel can approve the test cases. For a life sciences customer we would recommend:
| Draft > Ready for Review | Creator, Manager, Project Owner |
| Ready for Review > Approved | Owner |
| Approved > Ready for Test | Manager, Project Owner |
| Ready for Test > Tested | Owner |
| Tested > Verified | Manager |
| Verified > Obsolete | Manager, Project Owner |
We have only listed our suggestions for the forward transitions, make sure you have also determined the correct permissions for the reverse ones. We have also omitted the Reject test case path, you would need to define the roles for the rejection process as well. We have also only utilized the built-in default roles. Depending on how you have configured the roles, you may want to change the roles used in each transition.
3) Add Electronic Signatures to Specific Transitions
Now that you have updated the permissions, you can now set the Electronic Signature options to the appropriate transitions:
We would recommend applying the electronic signature to the following forward transitions (typically the reverse ones do not need to be signed):
- Ready for Review > Approved
- Ready for Test > Tested
- Tested > Verified
4) Restrict Field Editing by Status
Finally you will want to update the fields in the system so that certain fields are required at specific stages and other fields become read-only once they have been approved:
We would recommend the following field configurations for use in validated life sciences projects:
| Draft | Most fields should be visible and enabled. You should make the Name, Owner and Priority required at least. Execution Status should be Disabled |
| Ready for Review | Most fields should be visible and enabled. You should make the Name, Owner and Priority required at least. Execution Status should be Disabled |
| Approved | Most fields should be visible and enabled. You should make the Name, Owner, Comments and Priority required at least. Execution Status should be Disabled |
| Ready for Test | All fields should be read-only (disabled = Yes) at this point except Execution Status. |
| Tested | All fields except comments should be read-only (disabled = Yes) at this point. Comments should be required |
| Verified | All fields except comments should be read-only (disabled = Yes) at this point. Comments should be required |
| Obsolete | All fields should be read-only (disabled = Yes) at this point. |
Note that two test case fields have special meanings:
- Test Steps? - when this field is marked as Disabled = True, you will not be able to edit the test steps
- Execution Status - when this field is marked as Disabled = True, you will not be able to execute the test case in this status.
You have now configured your test case workflow for a validated life sciences project. In our final article in the series, we shall be configuring the release workflows.