Testing Process Governance for test case logs

Testing Process Governance for test case logs in Test Manager: how governance is inherited, its states, and how it differs from governance on test cases.

Testing Process Governance also extends to test case logs, the records created each time a governed test case is executed. This topic explains how governance behaves for test case logs, and how it differs from governance on test cases.

How governance is inherited

A test case log's governed status is set in two ways. At creation, the log inherits only whether the parent test case is governed, not the parent's approval state, along with the parent's approvers at that moment. Refer to the Starting state section of the documentation, to learn how the log's own approval state is determined.

• If the parent test case is governed, the resulting test case log is governed automatically, and inherits all of the parent test case's signatory records (approvers) at that point in time.
• If the parent test case is not governed, the resulting test case log is not governed.

You can also enable or disable governance directly on a test case log afterward, independently of the parent test case. For more information, refer to Enabling governance at test case log level and Disabling governance at test case log level.

Once a test case log is governed, whether by inheritance or directly, it becomes a disjoint entity from its parent test case: subsequently disabling governance on the parent test case, at project level or test-case level, has no effect on logs already created.

Approvers and signing order

You can add or remove a log's approvers independently of the parent test case at any point. For more information, refer to Managing approvers for governed test case logs.

A log also never inherits a signing-order requirement from its parent test case: enforced signing order is a test-case-only setting, so logs always accept signatures in any order regardless of the parent's configuration. For more information, refer to Enforcing signing order for governed test cases.

Starting state

A governed test case log always starts in the In Work state, regardless of the approval state of the parent test case at execution time. For example, executing a test case that is currently Signed still produces a test case log that starts in In Work.

Test Manager does not show a warning on a test case log when its parent test case was executed while not fully Signed. Governance on a test case log is independent of governance on its parent test case, so the parent's approval state at execution time does not affect the log.

Test case log detail view

A governed test case log's detail view includes a Governance section, the same way a governed test case does. Approvers that reference a user or group that no longer exists, for example a deleted user, are flagged as such in this section.

Signing and the declared role field

When signing a test case log, or a test case, the signing dialog requires a mandatory free-text Your role at time of signature field, up to 255 characters. This role is stored immutably alongside the signature and shown in the signature summary, and is independent between a test case log's own signature and its parent test case's signature.

Workflow and terminology

Test case logs use the same three states as test cases, In Work, In Review, Signed, and the same core terminology (Approver, Signatory Record, Approval state). For more information, refer to Testing Process Governance. However, the transitions out of the Signed state work differently for test case logs than for test cases:

• Voiding a single approver's signature on a Signed test case log implicitly reverts the log to In Review. It does not go all the way back to In Work.
• Reverting a Signed test case log all the way to In Work is a separate, explicit action that voids every signature on the log at once, and requires confirming a warning prompt.

Locking behavior during execution and re-execution

Because a test case log can be actively executing at the same time someone tries to change its governance state, Test Manager applies the following rule: you cannot transition a test case log between approval states while it is being executed. Test Manager blocks the action and shows an error. This applies uniformly across manual and automated executions, re-executions, and override-result actions.

Reporting and export

The PDF report for test executions indicates the approval state on all governed test case logs and includes each approver's declared role in the signature block. Bulk export (Excel) is also implemented, and includes the same governance data wherever relevant.

Including governance information in .tmh export and import

When exporting or importing a project as a .tmh file, you can choose to include governance information for test cases and test case logs.

• The Include governance information option is available in the export dialog and is off by default. When turned on, the exported .tmh file includes, for every exported test case and test case log: the governed flag, the approval status (In Work, In Review, or Signed), approvers (signatory records, including each approver's declared role), and signature metadata (signer and timestamp).
• The Include governance information option is available in the import dialog and is off by default. When turned on, governance information present in the .tmh file is applied to the imported test cases and test case logs. When left off, any governance information in the file is ignored.
• Exporting governed objects with the option on, then importing the resulting file with the option on, restores the governance state of those objects.
• If you import a .tmh file that contains governance information into a project where governance is not enabled, the governance information is skipped. The objects are imported normally, without error, but without governance data. In this case, the Include governance information option in the import dialog is disabled.

For more information on the file format itself, refer to TMH file format specification.