Admin troubleshooting
Locked test cases
When end users perform the Request Approval action, the test case Owning Group is changed to one with elevated permissions. If a test case is checked in with this Owning Group, that user will no longer be able to check it out to make changes. This is notable, especially if the step to Link or Update in qTest was not performed. End users will need a resource with elevated privileges to correct this, and other issues when they no longer have access to edit a test case. Some common mismatches and the resolutions are listed below.
Situation | Action | Resolution |
---|---|---|
End user has Requested Approval but has not checked in their changes | Instruct user to “undo” the Request Approval action | The test case owning group is restored to All Users and the end user can edit the test case |
End user has Requested Approval and checked in changes without performing the Link to qTest or Update in qTest action | As an Admin or user with elevated privileges, check out the test case and perform the Withdraw Approval action, then check in. Ask the end user to perform an Update All. | The test case owning group is changed to All Users and the end user can now edit the test case |
Lock Group errors
Lock Groups (owning groups) control which users have the ability to check out, and therefore edit, test cases. Either a single lock group can be created, or multiple groups may be used. Several guidelines should be followed when creating lock groups.
The service account should be a member of the lock group.
Users with elevated privileges may be placed in a lock group, depending on an organization’s needs, but membership should be strictly limited. Users that will creating tests, or performing the request Approval action should NOT be placed in a lock group.
If using HTTPs, users and groups (including lock groups) must be created with Tricentis Server Based User Administration. Groups created locally will not work properly with the integration.
Users will need to manually enter the lock group when they perform the Request Approval action. The groups All Users and Admin are not eligible lock groups. Errors will occur if the group All Users is chosen, but notification will not be provided until the record is routed in qTest. Selection of Admin will lock the test and only a user with Admin rights will be able to unlock and change the owning group of the test case.
Tosca Stand-Alone Approval Features
The Tosca Pre-execution Approval feature was designed specifically to be used in conjunction with qTest, but also has components that are not used as part of this integration. When using the integration as part of compliance with 21 CFR 11, these features should not be utilized. The only options that are fully integrated and may be used as part of a compliant process are Request Approval and Withdraw Approval.
qTest Linkage
Generally, users cannot perform an Update in qTest action unless a Tosca test case is in a PLANNED state. However, users with elevated privileges are able to perform this action while the test case is other work states. In the rare instances where users with elevated privileges must perform an Update in qTest on behalf of an end user, they should take care to first return the test case to a PLANNED work state. Failure to do so will cause the test case to lose its linkage to qTest which cannot be restored.